ESP8266 Community Forum

- Fri Jan 19, 2018 5:21 pm #73313

None of what you wrote indicates you would benefit by writing your own ISR for the UART RX interrupt

This would not represent any issue at all if the only heavy job of the ESP8266 were the GPS reception, but there are many other tasks being called in the meantime, particularly the Wi-fi libraries, which are very sensitive.

"part of the world that you live in, you are the part that you're giving" - Renaissance

- Fri Jan 19, 2018 5:29 pm #73314 There is still no indication that you would benefit from writing your own ISR for UART RX.

- Fri Jan 19, 2018 6:38 pm #73317

There is still no indication that you would benefit from writing your own ISR for UART RX.

When we parse a word during each received byte, we have the chance to dilute the decode processing over each received byte, instead of doing so in a single event. This is analogous to a state machine where each received value is allocated in corresponding variables, or received frame indicates the function of the following value. All this processing though is less intelligible, is extremely fast, consuming few machine instructions, besides not requiring a big RAM buffer to store the raw data to be afterwardly checked.

If we consider that most GPS comes with factory 4800 or 9600 baud rate, it would give us a ~10ms or ~20ms window between each interrupt, a quite reasonable interval. Trust me, I've already used this approach in a project based on another core with 3 UARTs running in parallel, each with its own interrupt vector, and it worked like a charm.

"part of the world that you live in, you are the part that you're giving" - Renaissance

- Fri Jan 19, 2018 11:35 pm #73320 TinyGPS and NeoGPS operate on a single byte at a time.

You’ve got an assumption, and you apparently won’t make any effort to test it on this platform.

Good luck.