Tuesday, May 26, 2015

GPS project Part 6

So the project continues, and really its almost done. I ran into a major snag, and maybe by posting it Ill get a little feed back to fix the problem.

I ordered a TFT screen. Its nice and in earlier posts you see that I had it working. Its was working in a static state. Static state being that I could input the labels I wanted on the screen, and enter in dumby data to see where things lined up on the screen, how colors looked, and placement. What I didnt know was TFT really really sucks for displaying real time data, especially in SPI interface mode. What happens is the data is written to the screen, in order to then display a new piece of data the screen must be erased and rewritten. When using  say a 20x4 LCD this is not an issue you can simply print some blank data " lcd.print( "       "); and you are done. Then all is needed is the new data written back. It works and is pretty fast, especially on I2C bus. What I discovered with the TFT screen is the whole screen needs to be blanked out and then refreshed, or one trick is to write and fill a black rectangle where the old data was, then print the new data. While this is similar to the LCD screen printing blank spaces...its too slow, at least for now. At a later date Im gonna try using the 8 bit mode instead of SPI, but Im under a time constraint, itll have to wait.

SO, yet another change. What I did was use 2 LCD screens...so why two? If driving down the road and you just want to have time and temp displayed, then you can turn off the bigger GPS screen and vice versa...or any combination there of. SO I broke the original sketch up into two parts, rewrote a few line of code for the LCD screen I2C bus displays.....enter my next problem

When I ordered the 16x2 LCD it came with an I2C bus module already soldered on the back. What I found out after tracing down the problem was BOTH displays were using the same address 0x27...great. You can fix this pretty simply by demuxing the clock (SCL) line so that one display sees the SDA line HIGH, and will ignore the data on the bus, allowing the other display to change...and vice versa...again Im under a time constraint, no time for rewiring things and adding boards. I could have done it, I chose not to. I fixed the problem by just adding another MCU. I have several of these Pro-Mini328 MCUs, fully arduino compatible, and there are cheap, at just a few dollars each. I think I paid like $4.50 each. I cant make them that cheap...SO I always keep a few around. In this case, it saved me a lot of time.


This is obviously the 16x2 undergoing testing. You can see the Pro-Min328 on the beardboard. The gray cable is connected to the GPS, and I stripped off the code to display just the time and the cars interior temp. Hard to see but the LM35DZ is on the breadboard in the upper right corner.


This is the final design for the 20x4 LCD, nothing fancy. Im displaying the latitude, longitude, the number of satellites the GPD receiver is seeing, and the current Altitude in feet. The "GPS" in the upper right corner means the receiver is locked on, if the receiver is not locked on, then the "GPS" is simply absent from the display.

Around each display, as you can see in the upper picture I made a Plexiglas bevel to go around each display. Its just .20inch think Plexiglas you can get at any home supply store, then just measure and cut it out. Be prepared to do a lot of filing to make the LCD fit. I now dream of owning a 65W LASER so I can cut my own, in the meantime, I do a lot o filing.....

That's all for this addition. In the next part, we will finish the wiring, and mount all the stuff ready for the final install in the car!

Happy Coding!

No comments:

Post a Comment