[Rxtx] noob trouble with rxtx, losing bytes somewhere
mariusz.dec at gmail.com
Mon Dec 14 05:25:23 MST 2009
> According to the serial HOWTO a 16550A (or 16550) FIFO chip can
> receive up to 14 bytes before interrupting CPU, at 115200 baud
> this makes around 900 events per second. This means, a response
> time of 1 ms or less would be needed.
Very important notice Steffen!!!!
900 events per second - while JVM works it may be to many - even on the fast
> According to http://support.microsoft.com/kb/259025 tells
> `Currently in Windows, 3 quantums are equal to either 10
> milliseconds ... or 15 ms ...' suggesting that response times
> below 10 ms cannot be guaranteed at all - which AFAIK is quite
> normal for multi-tasking multi-user non-RT OSes.
> So I'm pretty sure no Java application can be able to read
> constantly to an own buffer without support of the OS
> -- not even in theory.
The kind of solution is a big size of the OS buffer, which will not
overflows when Java is busy.
But there is a lot of another things as well - vendors drivers, USB /RS232
hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the
same USB hub etc.
> Did I do a mistake in thinking or is the problem (causing the
> need for single-byte-read-polling) a different one?
You are right.
>From my experience with real time systems (small embedded systems as well),
the best way is to prepare serial (or another incoming) buffer as big as
possible and thinking about tuning rest of the application - to have a time
to empty this buffer in the meantime.
I do it so:
1. I receive data using as high priority as possible HW interrupts and
prepare "Incoming index" (buffer is circullar of course)
2. In main loop of the program I compare "Incoming index" with "Serviced
index" and do data analyse.
If its not enough, I am thinking about faster microcontroller :D
Of course - everything depends on (incoming data amount) and/or (data
structure) and/or (intervals between data packets).
Few months ago I have helped my friend, who had to change their old
soft/hard system on RS232 from UART16550 to USB/RS232 dongle.
Timing in this system is very important.
While it worked on UART, there was no problem, when he started trials on
USB, troubles came.
Generally - USB BUS pooling was the problem and therefore events in external
hardware was comming to the system without any sense - additional STOCHASTIC
delay up to 5-15 ms.
Of course intervals between events visible in PC were stochastic as well...
We will have a lot to do when standards UARTS will gone !!!!! :)
More information about the Rxtx