Re: Reading Serial Port

The problem with reading stale data is that if you have filled up the buffer with old
data, then new data might not have space, and information will be discarded. By the time
you call PurgeComm, you might have already had the overflow, so that's why you see no
effect.

One trick I developed years ago was to do "loopback" style testing. If you have two COM
ports, you write an app that opens one for output and simulates your device by writing
data. Just for testing purposes, you might put in a 4-byte counter which you increment on
every packet, which will help identify the packet sequences that are being lost. So while
you think it is the 16th packet, if you could actually distinguish the data, it might be
that you would see it was a gap between the 201st and 235th packets.

If you don't have two serial ports, but have access to another computer, you can do the
same experiment. Ideally, you program your test app to put data out at a rate
approximating the device.

You use a null-modem cable to connect your two COM ports (or two computers). If you don't
have one, they are easy to create, and there's lots of info on how to do this (simplest
one is reverse the connection between TxD and RxD, which I vaguely remember are pins 2 and
3, but go do a google search on null modem cable or something like that to double-check
this)

The advantage of simulation is you get to control things and do things that the device
cannot do, or does rarely (I once found a protocol error in a client's serial port code,
by forcing a checksum error with a simulation. I spent several hours convincing myself
that my simulation was doing the right thing with respect to pretending to be the device,
and then explained that their protocol would go into an infinite loop of mutual NAKs...and
they said "we can't change it, it is being manufactured into ROM chips", meaning (a)
they'd never tested it and (b) if any error DID occur, the device would hang!)
joe


On Thu, 31 Jan 2008 04:24:09 -0800 (PST), clinisbut <clinisbut@xxxxxxxxx> wrote:

On Jan 31, 11:50 am, clinisbut <clinis...@xxxxxxxxx> wrote:
I'm desperate...
Maybe this will help: I've made a simple java serial reader and I got
the same problem...
But we have another app that reads the entire bytes coming from serial
port (we are sure of this) and there is no problem with this device!!!!

Well, I've successed to read correctly the serial port through a new
java application I've writed to test. The differences between this one
that works and the last that does not works is in the driver used. The
one good uses the RXTX library (http://www.rxtx.org/) and the bad one
the official from Sun. I know this is not a java group, just say this
to demonstrate that the device is working ok. There is something that
I'm missing!

Could it be, that the firsts 255 bytes I read are from a internal
buffer and I get that impression that i'm lossing data where the fact
is I start to read from the real serial port at the middle of a
frame¿?

I've noted that the firsts bytes I'm receiving are always bytes from
frames that get cutted in old "sessions" of my app.
I mean:
*Open my app and start receiving data.
*After sometime, I stop the read process at the middle of a frame so I
get only some bytes of it ( 3 for instance ).
*I close the app.
*Open again and start to receive data.
*the firsts bytes I got are the rest of the last frame received the
last time I opened the app.

I'm using PurgeComm to clear the serial, but seems that has no effect.
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Creating a simple windows messaging app
    ... a broker app that receives packets from a canbus and pushes them out to ... each application thread a copy of the packet. ... appThread responds to: ... consists of putting the message into a queue to be sent to the bus (no ...
    (microsoft.public.vc.mfc)
  • Re: Creating a simple windows messaging app
    ... a broker app that receives packets from a canbus and pushes them out to ... each application thread a copy of the packet. ... appThread responds to: ... consists of putting the message into a queue to be sent to the bus (no ...
    (microsoft.public.vc.mfc)
  • Re: Creating a simple windows messaging app
    ... a broker app that receives packets from a canbus and pushes them out to ... each application thread a copy of the packet. ... consists of putting the message into a queue to be sent to the bus (no ... targeted at a specific window. ...
    (microsoft.public.vc.mfc)
  • Re: Creating a simple windows messaging app
    ... a broker app that receives packets from a canbus and pushes them out to ... each application thread a copy of the packet. ... appThread responds to: ... consists of putting the message into a queue to be sent to the bus (no ...
    (microsoft.public.vc.mfc)
  • Re: Creating a simple windows messaging app
    ... a broker app that receives packets from a canbus and pushes them out to ... each application thread a copy of the packet. ... appThread responds to: ... consists of putting the message into a queue to be sent to the bus (no WriteFile ...
    (microsoft.public.vc.mfc)