[Rxtx] noob trouble with rxtx, losing bytes somewhere

[Steffen DETTMER]

* M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100:
> Serial port MUST read incoming data to their BUFFER constantly,
> and YOU go back to read data from BUFFER when "The Time Comes".

Shouldn't this be the job of an Operating System (managing the
hardware and implementing low level buffers in interrupt service
routines - or whatever is appropriate on the architecture)?

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.

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.

Did I do a mistake in thinking or is the problem (causing the
need for single-byte-read-polling) a different one?

oki,

Steffen

 
About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/.
 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
 P Please consider the environment before printing this e-mail