Boron UART RX unexpected behavior

Hello!

Preface:
I also noted this as an issue here because I see that both of these issues (this and this) have been marked as complete, so it may just be that on 3rd gen devices the expected behavior is different and the library is at fault, however after reading through the boron vs electron docs, and the library itself, I can’t see any reason why the library shouldn’t work (testing with 1.2.1-rc.3). The issue seems to be related to the head-tail calculation of Serial1 noted here. Unfortunately much of our product is set up around this library and I can’t seem to figure out a way to get through this upgrade from electron to boron (the hardware was designed to accept either as a future-proofing measure) with this issue occurring, and also without a change to the firmware of the peripheral ESP8266 which have already been programmed and populated to all of our inventory.

My setup:
ESP8266 communicating at 57600 baud, connected to the boron in the same fashion that it was connected to the electron running almost the exact same code (only minor changes such as removing setADCSampleTime() etc). The electron runs beautifully, however the boron behaves completely erratically (System mode manual, System thread enabled for both). I added some debugging lines as shown below after a fair amount of sniffing around trying to see what could be causing the issue.

Relevant code:

SerialBuffer<2048> serBuf(Serial1);

DBG_SERIAL_CONSOLE.print("serBuf available: ");
DBG_SERIAL_CONSOLE.println(serBuf.available());
DBG_SERIAL_CONSOLE.print("Serial1 available: ");
DBG_SERIAL_CONSOLE.println(Serial1.available());

Output:

serBuf available: 0<CR><LF>
Serial1 available: 50<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 50<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 50<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 50<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 50<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 50<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 50<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 50<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 50<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 70<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 77<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 82<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 88<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 94<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 100<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 106<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 111<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>
serBuf available: 0<CR><LF>
Serial1 available: 128<CR><LF>

Where I think the problem may be occurring (this is in the library):

size_t availableForRead() const {
	return (size + head - tail) % size;
}
1 Like

I released version 0.0.2 of the SerialBufferRK library:

  • Fixed a thread initialization problem that mostly affected Gen 3 devices with newer Device OS versions.

There is an important change you must make to your code. Add a call to serBuf.setup() from within setup().

On Gen 3 devices with newer version of Device OS, the serial reader thread cannot be created at global object construction time, so the reader thread was never created. That availableForRead() calculation is correct, it’s just without the reader thread running, no data is ever read from the serial port and put into the circular buffer.

2 Likes