Re: Reading Serial Port
On Feb 2, 3:07 am, Joseph M. Newcomer <newco...@flounder.com> wrote:
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 <clinis...@gmail.com> 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: newco...@flounder.com
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm
oh, that timeout, ok i see.
About the parsing algorithm I know i have to analize every byte until
I identify my frames, but the problem I mean is that I can't allow to
receive the second half of a frame until a second frame is sended to
me (like happened to me when I was using the MSComm Control). Doesn't
matter if I don't receive a entire frame in a single loop, I know how
to deal this.
By the way, I think I'm not deleting correctly my UI thread. I'm
always getting a "huge" memory leak of about 200bytes every time I
close the app. This is what I do to create my UI thread from GUI:
(MySerial*) pMySerial = (MySerial*)
AfxBeginThread( RUNTIME_CLASS( MySerial), THREAD_PRIORITY_NORMAL, 0,
CREATE_SUSPENDED );
pMyThread->ResumeThread();
And this is what I write to kill my thread in his destructor:
First I stop the reader thread:
MySerial::Stop()
{
SetEvent( ShutdownEvent );
WaitForSingleObject( ShutdownEvent, INFINITE );
}
Then I close the app and this should be executed:
MySerial::~MySerial()
{
CloseHandle(ShutdownEvent);
CloseHandle(ReadEvent);
CloseHandle(WriteEvent);
// Wait for the thread to exit before deleting
WaitForSingleObject( this->m_hThread, INFINITE );
delete this;
}