Close

Learning, Refining, and Ordering

A project log for Open Source Cell Phone

A completely open hardware and open source software cell phone

hugh-darrowHugh Darrow 08/25/2014 at 05:180 Comments

    So today was pretty much a day of reading, experimenting, failure, more reading, experimenting failure, in fact this last statement could be put into a while statement for when c=0, c==20, c++ to say the least. But with each failure I learned something more that I either knew an immediate solution, knew what to look for, or know I don't know how to solve it yet. So the first problem with with the programming port on the Due. The Due wouldn't upload correctly continuously, so my first solution was to reset the com port in windows, in this case I just went through the driver manager and changed the com port to port 5 and noticed you could change the baud rate....hmmm....that might be nice, faster uploading on the Due perhaps, set to 19200. Well the com port change didn't help, so next, google it. I read through some forums where people were saying that R23 is 10k when it should be either shorted or 1k to be safe. So I went hunting through the schematics and diagrams of the Due to find that indeed R23 is in series to the RESET for the Due, with an high ohm internal pull-up resistor 10k in series would significantly drop the voltage not allowing the RESET to go high, but this doesn't apply to me as my Due has the updated board with 1k ohm R23, damn, but there in lies the solution, the RESET probably isn't getting pulled high or perhaps some off pin needed to through into programing, as I do have more boards and chips being supplied by the ever so finite USB port. So I threw on an external power supply at DV 9v 800ma and sure enough that's all it took, programing and uploading fixed. 

    Next was trying to register touches on the screen, yet for some reason when I did so I couldn't register any touch, well time to dive into the libraries and RA8875 reference. The solution lied in the fact that in order to receive touch input from the registers you need to enable graphics mode with

tft.graphicsMode();

so in the end another simple fix.

    Next was to create a layout that allowed me to draw a matrix of x and y values that when touched would output a specific function or character, while doing once, yet allowing it to be repeated, but only repeated after so long. Yeah. That one took a while. First I needed to specifically map out the pixels I wanted to use as input, next I needed to define the matrix per number on the pad as a specific output, but worst was trying to get the de-bouncing gremlin/demon/asshole to stop inputting two characters, this took a while to find a perfect or near perfect solution. In the end the best was to use a timer that I could use an if statement asking if the timer had passed a certain amount of milliseconds then read the value of tx and ty and perform this function,

//variable definition timelast

long timelast = 0;

//the if statement

if (millis() >= (timelast + uint8_t(250)))

which just says if millis() is greater than or equal to the variable timelast plus 250 is satisfied then perform

if (tx > 605 and tx < 675 and ty > 185 and ty < 305)
{
delay(50);
Serial.print("1");
delay(50);

which uses a second if statement to ask if a touch has been detected in the matrix defined, delay 50millis print to the console 1 then delay another 50 millis, which then repeat for other numbers like so

if (tx > 108 and tx < 180 and ty > 443 and ty < 577)
{
delay(50);
Serial.print("0");
delay(50);

with all the center points and boundaries defined in the note in the sketch, and last the end of the original if statement

timelast = millis();

which just takes the value of millis as of that point and redefines timelast. This solution works pretty well, the input is pretty steady and consistent, while allowing for normal dialing speed, and repeating numbers in the dialing sequence. All the new code and files have been uploaded to use or follow along. My step is to take the input from the number pad, create a value, store the value in a buffer of some kind, then when asked input buffer into an AT command and write to the GPRS shield effectively completing the first call from the phone using nothing but the components.

   I'm also looking for a name for the phone, so far I've only come up with Genesis and LibrePhone, let me know what you think or if you have something better. As always happy hacking

Discussions