Part 5.... the firmware

So having all these parts and assemblies together really means nothing if they dont do something cool, and the firmware is what glues that all together. As I mentioned I was under a bit of a time constraint, so it was easier to look and some examples and libraries to get what I needed, and understand whats being done. Normally I write all my code, but right now, I need stuff to work, Ill make mods later.

Credit where its due. I looked at several libraries, .cpp and header files, and examples from folks like Limor Fried ( LadyAda), Mikal Hart ( TinyGPS++) and others to see what I could find. Mikal Hart has written a great GPS library, and Ladyada some great code on the TFT screen, so why reinvent the wheel...

The firmware:

First we need to set up the libraries, and the initialize things

I need the library SPI to run the TFT screen since its SPI interfacing. The TinyGPS++ library is to interface with the GPS receiver, and gives us the tools to parse out what we need from the NEMA stream. The two ADAFruit libraries are to use the graphic capabilities of the TFT screen. Finally we set up the Software serial, address the pins to use, make our definitions. Last, initialize the analog pin A0 (CARTEMP) , so we can read the temperature from the probe in the car interior. Thats everything we need to make this work.


Next we setup things:

There really isnt any magic going on here. All we are doing is setting up the serial ports. The software serial port connected to the GPS, will send its data to the arduinos serial port. You can then debug the data, which is helpful. The rest of the code here is nothing more than setting up the screen in landscape more  ( tft.screenRotation(1)) clearing the screen, outputting a message to the user thats the system is booting up, waiting a second, and telling them its done. In the final version, the delay put in here ( delay (1000)) will be changed to delay(30000) or 30 seconds to allow the GPS time to do a cold boot and acquire the satellites. I may or may not drop this in the future, and just tell the user its is powering up, but thats later, again time is not on my side. This needs to get done, playing with user interfacing is a later project...

The VOID loop:

This is where everything get done. 

ok.. the fun part. In the first part of this the code is telling the arduino to look at Software serial port (ss). Its going to see if there is data there. If there is data available, then decode the data and jump to the void loop " displayScreen".

If there is no data available after 5 seconds, then it jumps to the routine that throws the warning on the screen stating that the GPS is unlocked, and stays there until there is data available

In the loop for the display screen, I have shown the part ( and all the other parts are the same) for parsing out the data ( in this case latitude) and displaying it on the screen. This is repeated in one form or another for longitude, altitude, speed and the number of satellites the receiver sees. All the " if " loops are, is if the code sees a change, for instance " if (gps,location.isUpdated())" then parse out the new value and display it...its rather simple. Mikal Hart does some great explaining on what the library does, and how to use it, its worth looking at the examples and understanding what its does.

Ima bonehead:

As I have mentioned Im under a time constraint. Cute things and added features will come later I just need functionality. When I wanted to display the clock on the screen, I parsed out the time from the NEMA data, and used some examples to update the hour, minutes, and seconds. There were two small problems though. One of the people using this doesnt know what UTC time is ( the standard time sent in the NEMA stream from the GPS satellites.....and we are under Daylights saving Time. If the satellites are sending UTC time, how to account for all of this.....enter my boneheaded bandaided work around.....dont comment on this part of the code...it works, for now until next November when the time changes locally....

This is the dumbest code I have ever written, and the first thing Ill fix later. Basically this code accounts for GMT time, converts the GMT time to DST for the central time zone in the USA, and then make corrections if the time falls after 00:00 local time. In reality it works, its bad code, but I didnt want to sit there and add the code to figure out what day it was, and the month, and then add in to fall back an hour in November, and spring ahead an hour in March.....yes it can be done, this is a bandaid to make it work ...FOR NOW...I get a chuckle everytime I see this part of the code....

Finally the code for the car temperature code. I just wanted to add this, as a cute feature. Its taking an LM35DZ Celsius temperature probe, and converting the temperature to Fahrenheit, and displaying it on the screen. I may move this down to the APRS radios heat sink and monitor the temperature there...its probably the only real " bell or whistle" I added

This about it....nothing fancy. Ill add the entire code in the future for anyone that might want it to adopt for their needs.


Happy coding!