How do I discern Maidenhead Locator from GPS lat long info.

[HenrikOlsson]

Hi Rob,
I haven't been following this thread in detail so I apolgize if I'm suggesting something that's already been covered or isn't doable for whatever reason.

Looking at the code you posted, and as you mentioned, you spend quite a bit of time in the ISR. I have two questions/suggestions.
A) Why do you need to reload the custom characters each time? Wouldn't it be better to load them once at startup?
B) Can't you simply set a flag in the ISR (ie UpdateDisplay = 1) which you then poll in the main loop? If the flag is set you update the display and reset the flag.

Obviously there must be enough clock cycles between interrupts to do whatever needs to be done - no matter "where" it's being done (inside or out of the ISR).

Doing (B) above you basically can't have the HSERIN statement within the main loop as it will "block" the processor for up to TimeOut ms (2000 in the code as posted). What you'd need to do is either introduce UART interrupt or simply poll the UART RX interrupt flag within the mainloop (provided the mainloop is "tight" enough to not overflow the UART receive buffer (2 bytes).

As I see it at the moment, the code reads the gps string, then parses it,

Yes and no. It doesn't read, then parses it. HSERIN is parsing the string as the bytes comes in, one by one. If it didn't do that you'd have to have a recieve buffer as big as the complete NMEA string. But again, the code in your ISR takes considerable amount of time and it's quite possible that if an interrupt occurs in the middle of the HSERIN statment (quite possible) the ISR is stealing too much time so the the receive buffer (2 bytes) overruns and HSERIN "gets lost".

At 4800 baud each byte is a about 2ms long so if your ISR takes more than 4ms to execute it will most definitely cause issues for the HSERIN. Seeing all those LCDOUT statements within the ISR and the subroutines it calls makes me think your ISR runs way up into the tens of ms.

/Henrik.