It is possible to handle the GPS data during the RX character interrupt. This can be required if some part of your system absolutely has to block (e.g., SD write). I'm not sure updating the display really has to block like that, but...
I have modified the standard HardwareSerial class into a new class, NeoHWSerial. The NMEA_isr.ino example program shows how to use it.
Basically, you use NeoSerial
everywhere instead of Serial
(and NeoSerial1
instead of Serial1
, etc.), set the ISR function in setup (to call the GPS parser), and change your GPS_Update routine:
volatile void GPS_Update(void) {
//Reading GPS data
while (__GPS__.available()) { // <-- NOTE! no Serial1 argument!
__GPSDATA__ = __GPS__.read();
}
}
Fixes will be magically parsed in the background, and will become available at the update interval of your GPS device (usually 1Hz).
Coincidentally, this technique is more efficient overall, because the characters are not queued and dequeued. They are consumed immediately. It can also simplify the display update because no state machine is required (i.e., less code).
Like Robin2 said, I would still pace the screen updates to go no faster than 1 or 2 times per second. If that's the GPS update rate, only draw it when a new fix is available. Either take ScreenUpdate out of loop
and call it from GPSUpdate, or set a global flag in GPSUpdate and check it in ScreenUpdate (which clears the flag).
I see you have two screen update routines, but you need to make sure the "static" parts are drawn as infrequently as possible (only once, in setup?), and the dynamic parts are only drawn (1) when something changes, and (2) no faster than 1 or 2 times per second.
Cheers,
/dev