CODEWITHSUNDEEP
cserial-portlinux-device-driverembedded-linuxuart
Dan
Dan

Reputation: 199

Reading data from different UART drivers

I have a problem due to different UART driver behaviour porting an application from an old ARM-based system to a new one. These are Linux embedded systems, one an Atmel AT91 with kernel 2.6.14 and the other a Freescale iMX6 with 3.14.38. My application is written in c.

The old one seems to have 10 receive buffers of 50 bytes each (I saw this in the kernel source), while the new one seems to be at least 1 of 4096 (deducted from testing).

This means that when I'm attempting to read form the port, in the old system I would need to wait 50 times a character time before I get some data, while on the new one I may potentially have to wait 4096 characters time before I get any data. This is due to the DMA operation in the UART driver. The driver won't pass any data on until either the buffer is full or the end of the transmission has been detected.

This wouldn't be a problem if I new that I would get a response every single time (i.e. the transmission takes what it takes depending on the amount of data), but when acting as a master and communicating with slaves on a bus you may be making requests to devices that are not there, so you wouldn't get a response. In this scenario my timeout configurations need to be very different, with the old system giving me a much faster response to a timeout.

I'll illustrate this with an example. I have a function reading from the port until there is no more data. "read" blocks until there is any data or a timeout time has passed.

If the transmission is 2048 bytes:

Old system the function reads: 50 bytes 20 times and then 48 bytes. New system the function reads: 2048 bytes.

Because I don't know the length of the reply I'm going to get I have to go for the worse case scenario and assume it can be > 4096 bytes:

In my old system I could have configured the port to timeout at ConfiguredTimeoutTime + 52 milliseconds In the new one I'll have to set it to ConfiguredTimeoutTime + 4260 milliseconds

The ConfiguredTimeoutTime is a grace time I give the slaves to receive my request, process it and create a response. It would depend on the types of devices on the bus.

This is a considerable difference, meaning that each non-responding slave is introducing a nearly 4 seconds delay in my polling time.

The questions are:

Sorry for the length of the post, I couldn't see how to condense it any further! Thanks!

Upvotes: 3

Views: 914

Answers (1)

samuel05051980
samuel05051980

Reputation: 409

Try to set read timeout to 100milli seconds as shown below to achieve freedom from different buffer sizes. When read return it will either have data or not.

currentconfig.c_cc[VTIME] = 1;
currentconfig.c_cc[VMIN] = 0;

Try some easy experiments from this serial port library. The applications folder contains many read method designs for different scenarios.

Upvotes: 1

Related Questions