On 8/20/08, Alexander Chernov <che_lex / mail.ru> wrote:
> >> Does anybody has a clue why it works differently? How possible to avoid
> >> that delay or data delivery in portions? Is this Ruby threads issue on
> >> Windows?
>
> But still, there is some
> sort of buffering effect which exists only on Windows. Linux variant
> works absolutely smoothly.
>

It does sound like a buffering configuration problem.  Under Windows,
the driver is responsible for maintaining a buffer for incoming data.
It's possible it won't notify windows that data is ready until it has
reached a certain size.  You can specify the recommended size through
the API.  The ruby/serialport lib hardcodes an incoming buffer size of
1024 - to change that you'd  have to recompile.  But it may make no
difference since according to MSDN: "The device driver receives the
recommended buffer sizes, but is free to use any input and output
(I/O) buffering scheme, as long as it provides reasonable performance
and data is not lost due to overrun".
Another place to check the driver buffer sizes is in the Windows
Device Manager under Ports/Properties/Port Settings/Advanced.

The other thing you might try is changing the read_timeout value.  The
lib is using a blocking read call, so given ruby's thread
implementation on Windows, that will block your whole program.  From
the docs, it seems like a timeout of -1 (return immediately)  is what
you want, but you may try a small positive value too - at least one
newsgroup post suggested that was the best fix.


Hope this helps
-Adam