Hello group !

I get a strange comportment few for a few days.
My company is developping a RFID Reader embedded in a device (M3
Mobile from mobile compia).
And i am making C# application using it (basic SDK)

the RFID Reader is not the problem, we have other hardware test method
to be sure it is ok, with good timming.

I have create a class :
public class BaseReader : System.IO.Port.SerialPort
this class works very well on Windows CE 5.0, i get a reading time of
an RFID tag about 0.6 sec.
When i use this class on a Windows Mobile 6.1, the code is working as
good as it allways working. But i get à 7 seconds time to read the
RFID tag.

so i get a 10 factor on the time access on the port between CE5 and
WM6.1.

As far as i have allready see such difference between WCE and WM, i
know how to correct it, i use my own Serial Port Class (from CF1.1),
and usually it works good and faster than CF2.0 SerialPort on every
plateform.
But i never implement the ByteToRead method from now (never need it).
And my new BaseReader class use it a lot.
I implement this property, but i allways get 0.

public int BytesToRead
{
get
{
int lpErrors = 0;
if(!ClearCommError(this._handle, ref lpErrors, ref
this.comStat))
throw new Exception("WinIOError()"); // never
go there !

return (int)this.comStat.cbInQue; // Allways return 0;
}
}

this is a standard implementation i found the same every where....
I am trying now to make this code work, with no succes !
But the read works, and when i write a command to my RFID Reader, i
can read the attempting response (no depending what BytesToRead
saying)

the second way (suggested by a friend) is that the RxFIFO of the
serial port is badly configure in registry. then the internal timeout
in the driver is timming up before the fifo is full, so it wait a few
milli second in each of my 64 read command, and i get back the rx
buffer good, but late.
It can explain the time, and may be it can explain that i allready get
0 when trying to get the ByteToRead, because the driver has allready
read the Hard buffer and store the data in a soft buffer (which has
the oversized fifo).

but I don't found nothing about this anywhere

So i have the following questions :
- I suppose it is well known that the System.IO.Port.Serial present
different timming perf depending it is on WCE or WM, where i can found
doc about that ? and workaround ?
- How can i implement the BytesToRead better ? (i need it
fonctionnal )
- how can i configure the RxFIFO size, and/or the internal timeout of
the driver ? (registry ?)

thank you for your help, i can send precision of my problems if
necessary, but i think i have tell everything i can

Romain TAILLANDIER

I solve my BytesToRead problem.
I had implement native ComStat structure using a class, and use the
ref as weel, removing the ref solve the problem.

I search aroud this 2 days ...:s
5 years developpement on C# from Windows CE 4.2, 5 years experience on
DllImports, and i still continue to do newbie errors ....
I love to be a developper !

Romain TAILLANDIER

I think that the most-likely cause for this is the serial port driver in your
WM6.1 target hardware. While the code to *access* the serial port from .NET
CF is standard and works the same on all devices (having the same version of
..NET CF, at least), each device OEM has to provide a serial port driver and
many of them have funny little problems that show up because of quirks of the
hardware or overlooked test cases for the driver. For a long time, the
Microsoft serial port driver returned incorrect values for the number of
characters in the receive buffer. I fixed that same bug in three different
versions of Windows CE for the devices I was building.

It sounds like you have a good relationship with the hardware vendor, yes?
If so, I would do the following: write a program in C, not C#, that uses
standard calls to check the RX buffer level, uses ReadFile() to read the data
with various time-out values set via SetCommTimeouts(), etc. Show them how
their driver behaves differently than "standard" or doesn't follow the
specifications, and ask them to fix it. You may, in the process of writing
this test code, figure out a set of parameters that you can use to work
around the problem, too. You can then back-port that work-around to your C#
code.

Paul T.


"romain taillandier" wrote:

> Hello group !
>
> I get a strange comportment few for a few days.
> My company is developping a RFID Reader embedded in a device (M3
> Mobile from mobile compia).
> And i am making C# application using it (basic SDK)
>
> the RFID Reader is not the problem, we have other hardware test method
> to be sure it is ok, with good timming.
>
> I have create a class :
> public class BaseReader : System.IO.Port.SerialPort
> this class works very well on Windows CE 5.0, i get a reading time of
> an RFID tag about 0.6 sec.
> When i use this class on a Windows Mobile 6.1, the code is working as
> good as it allways working. But i get Ã* 7 seconds time to read the
> RFID tag.
>
> so i get a 10 factor on the time access on the port between CE5 and
> WM6.1.
>
> As far as i have allready see such difference between WCE and WM, i
> know how to correct it, i use my own Serial Port Class (from CF1.1),
> and usually it works good and faster than CF2.0 SerialPort on every
> plateform.
> But i never implement the ByteToRead method from now (never need it).
> And my new BaseReader class use it a lot.
> I implement this property, but i allways get 0.
>
> public int BytesToRead
> {
> get
> {
> int lpErrors = 0;
> if(!ClearCommError(this._handle, ref lpErrors, ref
> this.comStat))
> throw new Exception("WinIOError()"); // never
> go there !
>
> return (int)this.comStat.cbInQue; // Allways return 0;
> }
> }
>
> this is a standard implementation i found the same every where....
> I am trying now to make this code work, with no succes !
> But the read works, and when i write a command to my RFID Reader, i
> can read the attempting response (no depending what BytesToRead
> saying)
>
> the second way (suggested by a friend) is that the RxFIFO of the
> serial port is badly configure in registry. then the internal timeout
> in the driver is timming up before the fifo is full, so it wait a few
> milli second in each of my 64 read command, and i get back the rx
> buffer good, but late.
> It can explain the time, and may be it can explain that i allready get
> 0 when trying to get the ByteToRead, because the driver has allready
> read the Hard buffer and store the data in a soft buffer (which has
> the oversized fifo).
>
> but I don't found nothing about this anywhere
>
> So i have the following questions :
> - I suppose it is well known that the System.IO.Port.Serial present
> different timming perf depending it is on WCE or WM, where i can found
> doc about that ? and workaround ?
> - How can i implement the BytesToRead better ? (i need it
> fonctionnal )
> - how can i configure the RxFIFO size, and/or the internal timeout of
> the driver ? (registry ?)
>
> thank you for your help, i can send precision of my problems if
> necessary, but i think i have tell everything i can
>
> Romain TAILLANDIER
>
>
>
>
> .
>

it seems the same problem i have : get answer from received event :

i try to send some chars over a serial
connection to the board with hyperterminal, but the key entered in
hyperterminal gets displayed (= DataReceived(c#) event fired) not until about
10sec ?!?

did you share your class you wrote for testing ?

"romain taillandier" wrote:

> I solve my BytesToRead problem.
> I had implement native ComStat structure using a class, and use the
> ref as weel, removing the ref solve the problem.
>
> I search aroud this 2 days ...:s
> 5 years developpement on C# from Windows CE 4.2, 5 years experience on
> DllImports, and i still continue to do newbie errors ....
> I love to be a developper !
>
> Romain TAILLANDIER
> .
>

Sounds right to me. I haven't seen this problem, but I don't have any 6.1
hardware.

Dick

--
Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
Lakewood, CO 80228 303-986-2179 (voice) Homepage: www.hardandsoftware.net
Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
2006.