Re: Reading Serial Port

Your high CPU usage is probably due to your request to ReadFile to
read only one byte and return. That is very inefficient and wasteful if the
characters are arriving every millisecond!

In this test I set up frames of 16 bytes length only for testing
purposes, but in final version each frame will have different lengths
(16 will be the maximum). That's beacuse I grab a byte each time (the
first byte will say me how many bytes).

If your timeouts are too short, then ReadFile will complete successfully in a short period
of time, and return 0 bytes read, so the event will essentially become signalled after
virtually no delay, and your CPU will quickly spike to 100% (in the RS485 case, I had the
timeouts wrong, and the reader thread went into an infinite high-priority loop,
effectively disabling the entire machine; I changed the timeouts and it worked quite fine
after that)
With timeout do you mean the timeout of the WFMO?

DWORD result = WaitForMultipleObjects( 2, hArray, FALSE,
INFINITE ); //<---- This

Will incrementing the bytes per read cause to receive a frame (with
length>bytes_per_read) in two pieces? (Not receive the second part
until a second FRAME arrives) I can't deal with this behaviour.
.

Relevant Pages

  • Re: Reading Serial Port
    ... Use a modified Finite State Machine to parse the input and it works well. ... By timeouts I mean the SettCommTimeout time, in particular, my intercharacter timeout was ... You handle frame parsing as a different part of the protocol (I ... until a second FRAME arrives) I can't deal with this behaviour. ...
    (microsoft.public.vc.mfc)
  • Re: USB interrupt for a realtime bus
    ... I am able to use IN on al devices in the same millisecond. ... application or host controller implementation. ... there's nothing in the USB standard that would prevent ... this all being done in the same 1 ms frame. ...
    (comp.arch.embedded)