Re: Reading Serial Port

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance



There's no need to read a byte at a time; you need to decouple packet logic from transport
logic. I just read bytes. I parse them, and when I get a full message, I PostMessage,
and hold onto what is left, and append to that (this is why I call my code a "schema" for
serial programming). I would get a byte of "I'm a header" followed by a byte of length.
Use a modified Finite State Machine to parse the input and it works well. You just don't
send everything just one packet's worth each time.

By timeouts I mean the SettCommTimeout time, in particular, my intercharacter timeout was
set to 20ms, which meant the thread was nearly always running.

Yes, you might receive a half-frame, a frame-and-quarter, two-and-a-third, etc. frames,
but that doesn't matter. You handle frame parsing as a different part of the protocol (I
also handled checksums, sending NAKs, and retries)
joe

On Thu, 31 Jan 2008 23:26:32 -0800 (PST), clinisbut <clinisbut@xxxxxxxxx> wrote:

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.
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.



Relevant Pages

  • Re: Reading Serial Port
    ... characters are arriving every millisecond! ... I changed the timeouts and it worked quite fine ... Will incrementing the bytes per read cause to receive a frame (with ... until a second FRAME arrives) I can't deal with this behaviour. ...
    (microsoft.public.vc.mfc)
  • Re: help with parsing and dcg (swi-prolog in particular)
    ... > A frame is a concept. ... > Now, I'm wondering too, how would I even parse it to a prolog list? ... bother about the possible limitations on memory sizes etc at this ... assert/write out the result, assert the position in the file that you ...
    (comp.lang.prolog)