serial problems

  • Thread starter Thread starter Steven Licciardi
  • Start date Start date
S

Steven Licciardi

I am using various P/Invoking for serial comms to communicate with a custom
built device from a PPC2003 device. Everything works fine normally,
however, on occasion it is required that I output a character to the custom
device, collect the response data, process the data, then repeat the process
any number of times (done in a thread). On occasion the custom device sends
extra undesirable data (variable amount) to the PDA after I have collected
the good data and before I output my new character to the serial port. What
I would like to do is clear the serial buffer before I output the new
character, is there any way of doing this? I notice there is a PurgeComm
function, but can find no implementation of this in .NET CF.

Any advice appreciated,

Steven
 
You should check out the serial assembly at www.opennetcf.org - I've had
similar 'serial noise' in many GPS applications. What you really need is
solid state serial access and a concrete parser. Keep in mind that the
pocket pc is NOT a desktop... and that the CF is NOT the desktop framework.

Cheers,

Rick Winscot
www.zyche.com
 
Simply read the garbage data and throw it away. Reading the buffer clears
it.

-Chris
 
Chris,

Perhaps I should restate my posting in a bulleted list for clarity... There
are four keys to serial applications on handheld devices:

1) A solid state method to read.write serial data - to ensure that the data
that you are getting is what you expect (hint, build on a stable code base)
2) A concrete parser - which will handle any valid message (and throw away
garbage) - this is especially true for threads... try to handle as much as
you can in code and avoid throwing exceptions if possible - exceptions, when
thrown, can generate exponential overhead. While testing, it might be a good
idea to write out anything that is causing exceptions for analysis - so you
can write something that handles it 'inside' the try block.
3) To remember that you are programming for a handheld device and not a
desktop... (so if you don't find something in the CF object model that IS on
a desktop... don't panic) There must be a good reason for it... or not.
4) The CF is a different animal... you'll get used to it. You might want to
read Doug Bolings book on the CF to help you clarify WHY it is different -
the knowledge will help you write better handheld applications.

While reading (as Chris pointed out) from the serial port will essentially
clear the buffer... the above mentioned items have greater meaning and will
ultimately result in a more stable code base.

Rick Winscot
www.zyche.com
 
Thanks for the repies, yes I have already tried using :

<DllImport("coredll.dll")> _
Private Shared Function ReadFile(ByVal hFile As Integer, ByVal Buffer() As
Byte, ByVal nNumberOfBytesToRead As Integer, ByRef lpNumberOfBytesRead As
Integer, ByRef lpOverlapped As Integer) As Integer
End Function

but without knowing the correct lpNumberOfBytesRead, the function just hangs
if I specify a large number for lpNumberOfBytesRead. Is there a way of
determining the number of bytes in the buffer or am I supposed to just set a
low timeout?

Thanks,

Steven
 
Unfortunately that won't save me any time, I already have my own serial
class that works very well ordinarily, I am reluctant to redo all my serial
comms stuff for this one problem. I cannot see anything in the OpenNetCf
serial classes that I am not already doing, my only problem is that the
ReadFile function call hangs if I use it with a nNumberOfBytesToRead value
that is too large (or if there is nothing in the buffer). Has anyone
actually managed to use the ReadFile method with nNumberOfBytesToRead
greater than the number of bytes in the buffer, if this is possible than I
can at least explore why mine hangs?

Thanks,

Steven
 
That's a behavior defined by the driver. If it hangs, then it's trying to
read more data in a blocking call. Set your CommTimeouts and it should
return after a set period.

-Chris
 
Thanks, I'll give it a try, I was hoping there was a way to determine the
number of bytes ready to read and set the nNumberOfBytesToRead accordingly.
If the timeout is the only method then I'll go with that.

Thanks,

Steven
 
You *may* be able to use the result of a call to ClearCommError. Look at
the cbInQue member of the structure. However, I will caution you that the
Microsoft serial driver had a bug in it which caused this value to be
incorrect almost all the time, so your results may vary.

Paul T.
 
I'll have a look at that.

Thanks,

Steven

Paul G. Tobey said:
You *may* be able to use the result of a call to ClearCommError. Look at
the cbInQue member of the structure. However, I will caution you that the
Microsoft serial driver had a bug in it which caused this value to be
incorrect almost all the time, so your results may vary.

Paul T.
Click to expand...
 
Steven,

I agree with Chris on this and also use the timeouts value. On the desktop
you can use overlapped I/O, but that's not an option in Windows CE.
 
Back
Top