GPIO UART /dev/ttyS1 buffer overrun at high baud rates

Avik De

Hi, I am using libmraa with the upboard (running kernel 4.4.0-2-upboard), and using the UART on the GPIO /dev/ttyS1.

mraa advertizes 3.8 Mb/s, and I can get the upboard to receive all the correct characters at 3 Mb/s, but there are occasional buffer overruns even though my reading program takes bytes out in a constantly spinning while loop. I checked this in /proc/tty/driver/serial which counts the number of overruns. I've tried running the process at the highest priority.

Are there any recommendations on how to possibly get this to work? The advertisement of it working on the mraa page makes me think I'm just missing something. Should I attempt to patch the kernel with PREEMPT-RT? Is there any easy way to increase the size of the FIFO buffer?

Kurt

I could be wrong here and hopefully others can give more complete answer. But it is probably not unusual for such high speed communications to overrun. I have played around with it at high speeds like this, but I typically do it with short packets and there is gaps of time between packets...

It has been a long time since I have used MRAA for much of anything (edison) and at that time the uart code more or less did not exist so I used my own, so I may not know all of the MRAA specific stuff.

But things I would look into include:
a) Hardware Uart has built in support to let you know it is about to run out of room, look at the RTS/CTS pins.

b) As you mentioned: try to run the thread at a high priority. Also not sure about this processor, but some processors the different IO devices you can set the priority of their interrupt. If so not sure how to bump this one up.

c) Are you trying to read 1 byte at a time or lots of bytes at a time? There is often a lot of overhead to system for each of these calls, so if you are not already doing so, have you tried: calling mraa_uart_read with a larger buffer (example 64) and see if that helps. You may have to make calls to update to not wait for the data but return with however many bytes it has at the time and then have your code extract the bytes.

Hope that helps

Avik De

Hi Kurt,
Thanks for replying. Your last suggestion helped a little, but there were still errors. I have for now given up on it and an trying to use an FTDI chip (which has a 512 byte buffer) to send this data over USB. Still trying to figure out latency etc. but at least there are no errors due to overrun!
Thanks for your help,
-Avik