Serial transfer data loss

From: Jim Peters (jim_at_uazu.net)
Date: 2002-03-14 13:30:48


sleeper75se wrote:
> Testing the serial port can be done by anybody who can program and
> owns two computers, so volunteers are welcome. Start a new thread on
> that topic if you are interested...

I took your challenge, setup a test with a Perl script dumping data at
115200 baud down a cable with flow control disabled. There was no
problem on my text-mode P133 laptop keeping up with this data stream
with the machine unloaded (I was using "cat </dev/ttyS0 | tee log").

However, doing a 'find' or any other large disk operation
(e.g. starting a program up) did cause it to lose bytes, even when I
gave the process a higher priority. (I didn't try changing the
priority of interrupts because I don't know how to do that).

Loading up the processor (e.g. calculating lots of sines) only had an
effect when the process was at normal priority. At higher priority
there was no problem.

This is because we're not using flow-control, isn't it ? I'd
forgotten about this -- when you have a modem it has its own buffer
and it does flow-control over the serial cable. (Sorry Jim-M for
doubting you when you said we'd have problems).

> * Data loss: If data is transmitted at say 56700 bps, data loss will
> happen. A lot.
>
> A solution is to increase the interrupt priority of the serial port
> interrupt to the highest level. This is untested, but should ensure
> that no data at all is lost - i.e. you won't need CRC checking.
> If that doesn't work, we will have to use USB with a large hardware
> fifo (4kb) for PC's running Windows. Linux/embedded systems can be
> fixed by installing a real-time kernel.

Does there not exist anything like an RS232 line buffer module --
something that passes RS232 data through, but has a small memory
buffer in it, and does flow control ? I mean something very cheap.
Probably it's called a microcontroller, and we don't want to have to
have one at both ends of the cable. Oh dear.

> For me, data loss/sync loss is not acceptable at all so I will work
> hard to overcome it.

We have no choice -- we have to get clean data through somehow.

Jim

-- 
Jim Peters (_)/=\~/_(_) jim_at_uazu.net
(_) /=\ ~/_ (_)
Uazú (_) /=\ ~/_ (_) http://
B'ham, UK (_) ____ /=\ ____ ~/_ ____ (_) uazu.net


This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:40 BST