Re: SerialPort Caching?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Yep, I hit problem a couple times and just never looked back. I'm fine with
line parsing myself, so I don't much care if they ever fix it - I just like
to let others be aware of the pitfalls.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com



"Graham McKechnie" <gmknospam@xxxxxxxxxxxxxx> wrote in message
news:BB27EAE7-52BA-4B88-AEE5-CBA08B7CC2A2@xxxxxxxxxxxxxxxx
Chris,

Experience.

Interesting, my experience has been the exact opposite. However you've got
me going and so I think I will do some more testing.

Dropping the odd GPS sentence is hardly going to stuff things up much if
there is another one following. I'm not suggesting deliberately dropping
something, but you do have to test whether its a valid sentence anyway and
reject it if it isn't, so losing a single sentence isn't going to do much
harm

I've read through those threads you posted and I can honestly say I never
struck anything like that - the most serious issues I've had is when the
pda automatically shutsdown and how to handle that gracefully. My gps
stuff is for golf and a round of golf does tend to tax the battery life of
some pdas. The following helped with that along time ago now
http://blogs.msdn.com/anthonywong/archive/2006/03/03/542625.aspx

I've also seen the ReadLine call f it all up and become confused about
it's location, causing all sorts of grief for developers. The
performance tends to also blow in the cases that it miraculously does
work.

The obd stuff is coming from a vehicle engine and transmission ecus and
because I log every message, it would be very obvious if I was loosing
data or getting incorrect data because something got dropped on the floor.

It is a bit of a mystery why some are having problems with Readline and
not others, maybe I just got lucky!

Graham

"<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote in message
news:%23TVH3hPQIHA.5988@xxxxxxxxxxxxxxxxxxxxxxx
Experience.

ReadLine looks at the buffer for a line break, however I've seen in many
cases that if the data that has come in doesn't end very nicely with a
line break (so let's say we have half an NMEA sentence trailing in the
buffer) then that data is often either dropped on the floor or ignored in
the next call to ReadLine one additional data comes in. IIRC Dick Grier
(who does a *lot* of serial work) had also seen bed behavior along these
same lines. If you have data that has errors in it, I've also seen the
ReadLine call f it all up and become confused about it's location,
causing all sorts of grief for developers. The performance tends to also
blow in the cases that it miraculously does work.
ReadLine has also been known to throw a NullReferenceException if you
close the port during a read.

Just a few threads that talk about some of the issues seen in the wild:

http://groups.google.com/group/microsoft.public.dotnet.framework.compactframework/browse_thread/thread/565e6108d83ccdba/ccfa3ec9cea9213a?lnk=st&q=#ccfa3ec9cea9213a
http://groups.google.com/group/microsoft.public.dotnet.framework.compactframework/browse_thread/thread/50a90485ff52de0d/636ec9590f1e25df?lnk=st&q=#636ec9590f1e25df
http://groups.google.com/group/microsoft.public.dotnet.framework.compactframework/browse_thread/thread/420608f4408743d9/911486572cd5febb?lnk=st&q=#911486572cd5febb
http://groups.google.com/group/microsoft.public.dotnet.framework.compactframework/browse_thread/thread/7fca036066a59f2c/a959970dd5d1220e?lnk=st&q=serial+readline+group%3Amicrosoft.public.dotnet.framework.compactframework#a959970dd5d1220e


--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com




"Graham McKechnie" <gmknospam@xxxxxxxxxxxxxx> wrote in message
news:E01B38FD-D23A-4B1D-B179-CA5E0F545BA4@xxxxxxxxxxxxxxxx
Hi Chris,

Your comments re ReadLine come as a bit of a shock. I've been using
ReadLine in a couple of applications, one is gps and another is obd and
I've never come across a problem using it in either of them. The obd
app, also has a desktop version and I've never experienced problems with
either - same code shared by desktop and pda.

Why do you claim it is totally broken piece of you-know-what?

Graham


"<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote in message
news:eKINGKNQIHA.1184@xxxxxxxxxxxxxxxxxxxxxxx
Yeah, Port.ReadLine is poorly implemented (ok, that's generous - it's a
totally broken piece of you-know-what) and is the worst thing they ever
put in. I can't say I've ever seen an instance where it was used and
it actually worked.


--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com



"Brandon" <Brandon@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:81AD2B0C-50DC-4112-A563-9A446930D600@xxxxxxxxxxxxxxxx
You are a genius. Works great. Thanks for the tip!

"<ctacke/>" wrote:

First suggestion is to abandon ReadLine, as it only causes problems.
Just
read the data directly and look for line breaks yourself. Doing that
will
probably eliminate any kind of caching. If for some reason data is
still
cached (and I can only imagine that if the incoming data is faster
than you
can read, and with a GPS I just can't believe it) then when a
disconnect
happens, flush the buffer. Again, I can't imagine that would ever
happen
though.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com



"Brandon" <Brandon@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:B4DCA456-A80E-43B9-BDE9-0059679F3EBE@xxxxxxxxxxxxxxxx
Platform is WM2K3 (not SE) with compact framework 2.0.

I have a thread that is using SerialPort.Readline() to read raw GPS
data
from an RS232 GPS device (the RS232 port that the GPS device is
plugged
into
is on the vehicle cradle that the device is in). If I just open
the
serial
port and then repeatedly call SerialPort.Readline(), I seem to
continue to
get data off of the serial port for a period of time after I have
un-cradled
the device (effectively disconnecting it from the RS232 port). The
length
of
the period of time seems to be directly related to the lenght of
time that
this thread is successfully reading from the port (for example, I
put the
device in the cradle and read for 5 seconds, then uncradle, I
continue to
get
data from the SerialPort for X seconds...If I put the device in the
cradle
and read for 50 seconds, then uncradle, I continue to get data from
the
SerialPort for 10x seconds...not sure what the exact numbers are,
just
trying
to give a clear example).

The basics of this method looks something like:
SerialPort.Open();
while(!shutdown)
{
data = SerialPort.Readline();
...
}
SerialPort.Close();

If I instead repeatedly open the SerialPort, read until I get a
parseable
update that has an acceptable quality value, and then close the
SerialPort, I
do not have this issue, but instead I just get updates very slowly
(there
is
a lot of trash in the data for the first few reads, then you get a
bunch
of
initilization sentances, then you start getting position updates),
and
they
seem to jump around a lot.

The basics of this method look something like:
while(!shutdown)
{
SerialPort.Open()
Until(gotAGoodRead)
{
data = SerialPort.Readline();
...
}
SerialPort.Close()
}

I'd like to be able to keep the port open so I can read faster, but
the
caching behavior is a serious problem...any ideas?













.

Relevant Pages

  • Re: SerialPort Caching?
    ... Dropping the odd GPS sentence is hardly going to stuff things up much if there is another one following. ... ReadLine looks at the buffer for a line break, however I've seen in many cases that if the data that has come in doesn't end very nicely with a line break then that data is often either dropped on the floor or ignored in the next call to ReadLine one additional data comes in. ... ReadLine has also been known to throw a NullReferenceException if you close the port during a read. ... > data from the SerialPort for X seconds...If I put the device in the> cradle ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: SerialPort Caching?
    ... I've been using ReadLine in a couple of applications, one is gps and another is obd and I've never come across a problem using it in either of them. ... > port and then repeatedly call SerialPort.Readline, ... > data from the SerialPort for X seconds...If I put the device in the> cradle ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: SerialPort Caching?
    ... ReadLine looks at the buffer for a line break, ... the port during a read. ... SerialPort for 10x seconds...not sure what the exact numbers are, ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Share built in GPS
    ... CECreateFileW when using the programport configured by the GUI for GPS ... The most-likely cause is that the SerialPort object is opening the device ... supported for multiple clients of a serial port. ... GENERIC_WRITE, as I'm sure the default SerialPort class does, or b) replaces ...
    (microsoft.public.dotnet.framework.compactframework)
  • RE: rs232?
    ... // Setup the serial port using hardware handshaking ... "CSerial is the base serial class, which provides a wrapper around the Win32 ... CSerialWnd fits in the Windows event driven model. ... I tried to enter words like SerialPort class in the help, ...
    (microsoft.public.vc.language)