ESP8266 Community Forum

- Sat Jan 20, 2018 11:15 am #73333

TinyGPS and NeoGPS operate on a single byte at a time.

NeoGPS
At line 67-68 of the file "GPSport.h" it is clearly stated:

Code: Select all//      Use NeoHWSerial if you want to handle GPS characters
//      in an Interrupt Service Routine (see NMEA_isr.INO).

...but we know that NeoHWSerial library provide support only for AVR cores.

TinyGPS
Do not support ESP8266 cores

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

I regret having made that impression despite the whole survey presented so far.

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

- Sat Jan 20, 2018 12:47 pm #73335 You’re still stuck on the insistence that the NMEA handling must be done in the ISR. This is incorrect, and not required by NeoGPS.

I won’t have a GPS for a few days, so I haven’t tried it, but I found this on GitHub:
https://github.com/mkconer/ESP8266_GPS

A simple example using TinyGPS, software serial at 9600 baud, and an OLED. While it probably isn’t exactly what you need, if it works, it strongly suggests you are overstating the need for an ISR.

Have you actually run any GPS code on the 8266?

- Sat Jan 20, 2018 1:50 pm #73340

Have you actually run any GPS code on the 8266?

In fact, I've never used GPS on ESP8266 (specifically, on Arduino) because by analyzing the system as a whole, at first glance, I would have to deal with the issues previously reported (namelly, the lack of serial ISR). Before starting a project, I usually do a mind essay to check if a chosen architecture will work with the available firmware resources.

Regarding the example you presented, think on this: When adopting devices using synchronous communication (in this case, SPI for the Adafruit1306), this has the advantage that this communication can be interrupted at any time without having any impact on the communication itself, unlike a serial communication of the UART among the GPS, on which it is expected a sequence of dozens bytes within a well-defined frame. As mentioned bofore, the sentence of interest occurs at intervals of 557 bytes, and we don't have any indication of When, so the buffer size should be almost twice this size.

Note that at that code on Github, it isn't called any Wi-fi routines, which represents an almost ideal scenario, although the ESP8266 major atribute is this RF capability. In addition, the author makes use of the Soft serial, which would waste the built-in UART peripheral available on the uC, and worse, via polling, which would require to allocate the giant RAM buffer above mentioned.

You’re still stuck on the insistence that the NMEA handling must be done in the ISR. This is incorrect

I agree, but just when nothing else is called, I mean, if it is not expected any heavy task to run in the same program.

Anyway, thanks for the interest on this question.

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

- Sat Jan 20, 2018 3:14 pm #73341 The example I mentioned above uses I2C for the OLED, not that it matters for this discussion.

All the theoretical stuff is almost irrelevant. In less time than you’ve spent defending your assumptions, you could have produced meaningful test results.

You started this by complaining 8266 Arduino doesn’t have built in support for a user-defined ISR for RX on the HW UART. The only thing that would achieve would be slightly reduced latency on handling a received character, which wouldn’t be a meaningful advantage.

Peaceful coexistence with WiFi would still depend on your careful attention to time spent in loops called while in the loop() function, and knowing when to yield().

Buffer requirement is the same whether you get a character from the UART or from the Serial lib FIFO, aside from the size of the FIFO itself.