RE: wince serial driver

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Michael--J (MichaelJ_at_discussions.microsoft.com)
Date: 10/14/04 

Date: Wed, 13 Oct 2004 20:09:11 -0700

Hi Reinhard,

I know what it's like to be in your position. I've been working with Win CE
for 5 months now, and there hasn't been a lot of smooth sailing let me tell
ya! I have posted so many "SOS" emails just in the last few days, it's not
funny! Replying to your post would be the least thing i could do.

Anyway, with regards to whether i solved my problem or not... I did sorta
solve it. My problem was my app was not picking up all the parity error
events that the serial driver was raising. This was because i would do a lot
of processing after a parity error, and this would miss other incoming parity
errors. So to test this, i commented out all my processing code to see how
many parity errors it could pick up. It turned out, the app could pick up
more parity errors without the processing. So then i thought, why not modify
the serial driver such that i insert an escape character just before the
parity error byte? In my app, i would search for these escape characters to
determine where the parity error was and what the byte was. The only downside
to this is it's not event-driven so it lowers performance.

This driver mod out actually worked! i did not miss one parity error at all
and the performance wasn't that bad. I could still do all my required
processing in between parity errors and no parity error was missed.

I am not a driver expert myself. In fact, i was so overwhelmed by the
complexity of the source i wasn't looking forward to modifying it at all. But
after a few weeks of studying it, some of it did make sense and i was a bit
more courageous in applying some changes.

David Liao's suggestion is probably right... but to be honest, i wouldn't
even know what those drivers are and how i could exchange between the two. If
anyone can tell me how to do that... that would be awesome.

Kind Regards,

Michael--J.

"Reinhard Fischer" wrote:

> Hello Michael,
>
> thank you for the reply. It looks like you've found the fix for the problem
> that goes with the ARM based serial drivers. I have seen this problem with
> three ARM based systems for now (all Handheld PC's):
>
> - Manufacturer: LXE, Product: MX3-CE, Processor: SA-1110 B4 133 MHz,
> Operating System: Windows CE 3.0
> - Manufacturer: LXE, Product: MX3X, Processor: PXA255 rev A0 400 MHz,
> Operating System: Windows CE 4.20
> - Manufacturer: Panasonic, Product: CF-P1, Processor: SA-1110 206 MHz
> Operating System: Windows CE 3.0
>
> I am wondering if this is just the problem of one special serial driver or
> if this is a fundamental problem with all serial drivers of ARM platforms.
> The CF-P1 has got the Version 3.0 (Build 126), which was introduced around
> year 2000, as far as I know, whereas the MX3X is using 4.20, which was
> patched through May 04 2004. This problem obviously exists for years now and
> has not yet been fixed by Microsoft.
>
> I am happy, that there is somebody out there, who has encountered the same
> problem as I do and who obviously has a fix for this problem. Unfortunately,
> I have never been involved in drivers programming and I do not know much
> about drivers at all. So my original intention was, to figure out if there is
> existing solutions for this problem. I actually need someone exactly telling
> me which steps to follow, to replace the faulty driver.
> David Liao suggests to replace the XSCALE serial driver by using Windows CE
> 5.0 XSCALE CSP driver.
>
> Could you fix YOUR problem? Has it really been caused by the FIFO operation?
>
> Best Regards,
>
> Reinhard
>
> "Michael--J" wrote:
>
> > Hello Reinhard,
> >
> > Sorry for not replying sooner. If the driver is discarding bytes with parity
> > error, make sure that you modify the it so that it doesn't. I used the serial
> > drivers which came with CE 4.2, and the file which i needed to modify was
> > ser16550.c. Initially, this file would empty all bytes inside the FIFO if it
> > detected just one byte with parity error. This was happening in the LineIntr
> > handler. Originally it looked like:
> >
> > SL_LineIntr(
> > PVOID pHead // Hardware Head
> > )
> > {
> > PSER16550_INFO pHWHead = (PSER16550_INFO)pHead;
> >
> > DEBUGMSG (ZONE_READ,
> > (TEXT("+SL_LineIntr 0x%X\r\n"), pHead));
> > ReadLSR( pHWHead );
> > try {
> > OUTB(pHWHead, pIIR_FCR, pHWHead->FCR| SERIAL_FCR_RCVR_RESET ); // We
> > have to reset Receive FIFO because is is error.
> > while (INB(pHWHead, pLSR) & SERIAL_LSR_DR ) {
> > INB(pHWHead, pData);
> > }
> > }
> > except (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ?
> > EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH) {
> > ;
> > };
> > DEBUGMSG (ZONE_READ,
> > (TEXT("-SL_LineIntr 0x%X\r\n"), pHead));
> > }
> >
> > I had to change this to:
> >
> > SL_LineIntr(
> > PVOID pHead // Hardware Head
> > )
> > {
> > PSER16550_INFO pHWHead = (PSER16550_INFO)pHead;
> >
> > DEBUGMSG (ZONE_READ,
> > (TEXT("+SL_LineIntr 0x%X\r\n"), pHead));
> > ReadLSR( pHWHead );
> >
> > except (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ?
> > EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH) {
> > ;
> > };
> > DEBUGMSG (ZONE_READ,
> > (TEXT("-SL_LineIntr 0x%X\r\n"), pHead));
> > }
> >
> > This prevented it from discarding bytes with parity error. Maybe you could
> > try something similar. Thanks.
> >
> > Michael--J.
> >
> > "Reinhard Fischer" wrote:
> >
> > > Hello Michael,
> > >
> > > my application also has got a problem, which is pretty similar to yours. The
> > > application makes use of the parity bit to signal events. So I need the
> > > content of the arrived byte, even if it causes a parity error. This works
> > > fine, as long as Í am running it as a desktop application (Windows 95, NT,
> > > XP, ...). It still works fine, if I am running it as a CE application, as
> > > long as it is running on a MIPS platform. It will fail, if I try to port my
> > > application to an ARM platform (SA-1110, PXA255, ...). I guess, the serial
> > > driver of an ARM platform discards bytes arriving with an parity error. I
> > > don't think, that this problem is FIFO related. Otherwise, the desktop
> > > application wouldn't run, too.
> > > So you see, I am interested if you got already a solution to your problem.
> > >
> > > Best Regards,
> > >
> > > Reinhard Fischer, Hydrotechnik GmbH
> > >
> > >
> > >
> > > "Michael--J" wrote:
> > >
> > > > Hi,
> > > >
> > > > It seems as if the serial driver for Win CE.NET doesn't seem to be raising events for all parity error bytes received. So sending 5 bytes with parity errors results in only 1 or 2 error events being raised and my higher level C# application can only pick these.
> > > >
> > > > I'm trying to modify the serial driver source code that came with Platform Builder 4.2. What I did was modify the driver source code by adding the "0xFF" character everytime a parity error occurred. So if I send 5 bytes with parity errors, e.g. h-e-l-l-o, the drivers add "0xFF" in front of each, and my application should receive -> 0xFF-h-0xFF-e-0xFF-l-0xFF-l-0xFF-o. And this worked. My application basically searches for "0xFF" chars to determine where parity errors occurred, and it does so successfully. So this at least suggested to me that the drivers ARE detecting every single parity error.
> > > >
> > > > However, what I think the drivers AREN'T doing is in fact raise an error event for every corresponding parity error it detects, and that if it does raise an error event, I don’t know exactly which byte it is referring to. So instead of the application receiving 5 error events, it only receives 1 or 2 (may be random). I'm looking into the drivers to see what is causing this, but it is very complicated because it is tied in with the CE OS and kernel, and I am not very familiar with this.
> > > >
> > > > Any ideas as to why this might be happening?
> > > >
> > > > Kind Regards,
> > > >
> > > > Michael.

Relevant Pages

  • RE: wince serial driver
    ... David Liao and check with him, how to replace the driver. ... My problem was my app was not picking up all the parity error ... > events that the serial driver was raising. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: wince serial driver
    ... probably can get same result as you try to insert 0xff inside driver. ... "0xFF" character everytime a parity error occurred. ... what I think the drivers AREN'T doing is in fact raise an error ... instead of the application receiving 5 error events, it only receives 1 or 2 ...
    (microsoft.public.windowsce.platbuilder)
  • Re: [PATCH 2.6.8.1] drivers/char: New serial driver.
    ... > I am submitting a new serial driver for the 2.6 series of kernels. ... > Digi serial driver for the Digi Neo and Classic PCI serial port ...
    (Linux-Kernel)
  • Re: Problem with tcgetattr
    ... You are intercepting the ioctl or else replacing the ... These are the methods of the driver object. ... it looks like the serial driver to me. ... * is not handled by the tty layer or the low-level tty driver. ...
    (comp.os.linux.development.system)
  • Re: Personnal line discipline difficulties
    ... >> driver from Windows to Linux, and the Windows serial driver gives ... I'm sure there's no way to find that size but through the serial port ... I've already tried to totally replace the serial driver (by using inb and outb ...
    (Linux-Kernel)