HardwareSerial question

[YvesDS]

Hi to everyone!

I have a simple question :

On a other (dutch) forum, someone told me that HardwareSerial uses a buffer and interrupts to do the communication with other hardware.
Is that correct?
If a buffer is used, would that then mean that when a different, external interrupt is triggered, the buffer is used and when the other ISR is done, that the communication will continue where it was at the moment it was interrupted by a other external interrupt or function, or will i lose data in any case when something with a higher priority is done?

Is that buffer adjustable in the code to make it bigger if needed?

Thanks in advance for helping a newbie out on this!

Grtz, Yves

[ESP_Sprite]

Mogge,

The UART uses a hardware FIFO to buffer some characters, and the Arduino code seems to use a fixed-size 256-bytes queue to buffer data as well. You are right that during the time an external interrupt is serviced, the UART data is not read out; the bytes will 'pile up' in the FIFO for reading out later. Besides that, when you're not servicing an interrupt but your program is doing other things, the interrupt will keep the FIFO clear but the incoming bytes will 'pile up' in the queue.

As far as I can see, the Arduino code allows you to resize the queue, but the FIFO size cannot be changed. (Note that you can possibly work around this by poking the hardware directly, as the ESP32 itself does have the capability to resize the FIFO, within limits.)

[rodmcm]

Serial1.setRxBufferSize(1024);

[YvesDS]

Serial1.setRxBufferSize(1024);

Thanks guys, will try that first and see if it helps me !

edit : i was more looking for a method of increasing the TX in one way or another.
My ESP32 has no realy needed data coming back from the other device, i would only need a slightly bigger TX buffer, so i don't lose any data to the other device (Nextion Enhanced HMI display)

[paulvha]

A write() / print() will directly write in to the UART FIFO. No extra buffer. It will check whether there is place the FIFO, otherwise it will hold/wait until there is.

Instead of using a hardwareserial, you could consider softwareserial. That will perform it's own bit-banging and does not wait for space of buffer.

I started with downloading the version from https://github.com/jdollar/espsoftwareseria as a sensor driver (previous on an UNO) was expecting softwareSerial. I did run into a number of issues however before I could get it running stable. As the original github does not allow issues or other communication, I have posted my findings on : https://github.com/paulvha/ESP32/tree/master/softserial. The most critical part is receiving at high speed ( up to ~56K is okish...), but TX is working stable with the changes documented and applied.

Paul