oh no :D you get bytes from the buffer either when the fifo threshold is reached or when there is sufficient pause between bytes on the UART to trigger TOUT. For your code to wait it means that the transmission is still ongoing. I can not accept a PR that will cause Interrupts 112 times more ;) This will be so wrong on many levels if baudrate is high.
I would accept a PR that exposes a function which lets you change the fifo full threshold though (with some explanation on what it does and what it causes).

@me-no-dev have Serial.available() initiate a flush of the fifo if the Buffer is empty? That way if a APP wants to hammer the UART with continuous available() calls no harm is done, ISR driver is still waiting for FifoFull unless available() is called. The available() flushes the fifo into Buffer and available() just feeds from Buffer. Unless the APP is faster than the Serial rate, available() would only trigger the flush intermittently.

If this idea worked, the same code could be added to read(), if Buffer is empty trigger a FifoFlush.

It would just have to interleave with the ISR on fifo Empty calls, perhaps a MUTEX? On second thought, I can see race conditions and deadlocks. I wonder what would happen if APP level, Serial.available() got the MUTEX, but before it started emptying Fifo, the FifoFull interrupt trigger? I don't know the UART ISR code. Does a spinlock() require less overhead then a FreeRTOS MUTEX(semaphore)? Could the interrupt_rxFifoEmpty() be directly called from APP level Code?

I don't have time to work on it, but it seems to be an interesting problem.

Chuck.

@stickbreaker you came and just complicated things :D I might have an idea, caused by your idea

@me-no-dev You're welcome, I'm always happy to cause others more work! 🕺 🎆 🍾

(arn't emojis useless!)

Chuck.

Wow, i'm happy about the responses and thanks to you people with way more insight/knowledge of the sources thinking about solutions!

if there's no better fix, i can change, test and create another pull request with changes to hardwareserial/esp32-hal-uart to either add a new method or extend the parameters of serial.begin.
just let me know, but that might take some time to finish.

the reason for my change is simple: i have uart communication where i have a timeframe of approx. 4-5ms to send data. and with 115200bps and 112 bytes until the app "sees" a new byte that's no good....

shall we create a issue for this or leave communications on here...? i don't care.... but this PR is obsolete in either way ;)

Thanks!