OpenNETCF on the M5

[AKlopper]

In my quest to write a Garmin protocol implementation for the M5 as I did for the iQue3600 (which will just happen to function as an NMEA to Garmin protocol converter on any other PPC) I tried out the SerialCSharp sample application from the OpenNETCF Smart Device SDK. My experience was not good.

Irrespective of how large or small the chunks are that you try to read from the serial port, there seems to always be at least a 1 second delay between successvie reads, which results in data being read at a much slower rate than it is being written by the sender. This is probably the reason why WiFiFoFum lags so far behind in its GPS coordinates when used on the M5.

I don't know if this is an issue with COM2 on the M5, or with the serial port class implementation of the SDF SDK. I suspect the latter, but to prove it I am having to go back to C++, which is something I was hoping to avoid. Oh well, at least the install will be smaller...

[Bokkie]

A lot of people are waiting for version 1.3 of the OpenNetCF which supposedly makes GPS coding more robust and reliable. I think they have a sort of 'beta' of the GPS code available but I've not tried that.

[AKlopper]

I figured out why it wasn't working properly. If you only perform a partial read of the receive buffer when you receive a read event, you won't get another notification that there is still data available until the sender sends more data, even though there is still data waiting to be read in the buffer. I am used to the convention where an incomplete read triggers another read event until the receive buffer is empty. The SerialCSharp test application is broken in this respect as well.

The problem basically boils down to this: you request a read event for every byte that arrives, then read a single byte from the port. If the sender sends two bytes, you will only read the first, leaving a byte behind in the receive buffer which will sit there until the sender sends more data. If the sender continues sending multiple bytes at a time, you will get further and further behind. Ideally, reading the first byte should result in another read event being triggered so that you are notified to read the second byte as well.

Anyway, the solution is simple. Request read events for every byte of data that is sent, and attempt to read the entire receive buffer each time, thereby ensuring that nothing is left behind.

I'll have to see if the GPS code suffers from these issues, but I can get by without it. All I am really after is a simple way to access the serial port, since the methods I use under Windows are not portable to the Pocket PC environment.

[jonasolof]

I spoke today to a person in Sweden doing programming for both Palm and windows CE. He said he found it practical to use the software from www.nsbasic.com since it saves work in adapting the apps to the respective OS.

I have no idea if it's useful for the parallell iQue/Que development that we sometimes see