ESP8266 Community Forum

- Fri Jan 19, 2018 8:42 am #73289

The ESP8266 uart can generate an interrupt on both rx and tx of characters and it is then up to the isr to determine what to do.

As I understand it the Arduino implementation does use this mechanism at leaston the receive side to place the characters in a FIFO buffer where they be subsequently checked and extracted by the foreground task. That is a fairly sensible strategy and keeps the isr short which is normally a good thing.

Whenever I used this strategy, I encountered serious problems in synchronizing the received data. It may actually be that you are right, because dealing with a FIFO integrated into the already properly tested reception interruption handler would be recommended, but the speed of reception and the volume of data is large and incessant, so the discomfort in dealing with any parsing strategy other than the decoding "on the fly". Anyway, thank you.

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

- Fri Jan 19, 2018 9:54 am #73291

It should only take an experienced programmer minutes to put together a program to test this.

I'm not so familiar with the development in with the SDK Espressif for Arduino, and I would admit that I'm not willing to go further, the code structure is quite confusing even for a blinking LED project, therefore differently from other C compilers, implementing such functionality ( namelly, serial interrupt handling for individual received byte ) did not seem so trivial to me; In fact, if it were, I believe that such feature would already have been published somewhere. Thanks again for your replies, but I would appreciate if instead of disapprove my search, if you put the focus on finding a link for the solution - if it exists, otherwise, nothing to do.

I think you misunderstood me. I will rephrase.

It should take very little time, using Arduino/ESP8266, Serial library, and one of the NMEA parsers mentioned above, to test whether the serial data can be read correctly, and how much CPU remains available for other processing.

- Fri Jan 19, 2018 10:31 am #73293 It is now unclear to me exactly what problem you are trying to solve. Can you explain what you are trying to support on the uart, and why the standard functions won't do what you want?

Providing you check the receive buffer availability reasonably regularly then you won't lose bytes because of the buffering in place.

Note you do want to use uart0 for the best support. Interrupts are not available on uart1.

- Fri Jan 19, 2018 11:44 am #73297

It should take very little time, using Arduino/ESP8266, Serial library, and one of the NMEA parsers mentioned above, to test whether the serial data can be read correctly, and how much CPU remains available for other processing.

Sorry for insisting on that standpoint, but I had experience with GPS in other uC's, more exactly with the AVR core, which has a nice and stable C compiler and even there I saw how massive is the GPS sentences. Some of them have from 50 up to 75 bytes per second, and the sentence of interest sometimes comes 1 at each 4. This implies on a buffer of at least let's say ~240 bytes, not mentioning that once I would get the raw data assynchronously, I would have to allocate much more ram to seek the information of interest (at least more 75 bytes...). Ok, I gave up, I accept that with Arduino I would not be able to do what I expected (to decode on the fly), at least on the current core revision, but helpfully someone in the development staff put this request in the backlog/wishlist queue.

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