Re: Thorny Serial Comms "UART: Overrun" error Windows CE 5.0

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



I'd try the handshaking. I did extensive testing on the library and found
speed to be comparable to a C implementation.

--
Chris Tacke
Co-founder
OpenNETCF.org
Has OpenNETCF helped you? Consider donating to support us!
http://www.opennetcf.org/donate


"Andrew Revell" <andrew_revell@xxxxxxxxxxx> wrote in message
news:6dd1a40b.0504051257.3506a786@xxxxxxxxxxxxxxxxxxxxx
> OK. I will try to be more precise with my description.
>
> First of all, in my case I am actually looping back from one COM port
> on my WinCE device to the another (with a cross serial cable).
> Previously I was communicating with an external machine (which was
> when I noticed the problem). I have switched to looping back onto
> myself so I have more control of the comms.
>
> So the numbers I quoted are for the % of reads that do not succeed.
> That is, I output 1000 bytes on one port, then attempt to read these
> 1000 again on the other. 8% of the time at 19200, the full 1000 bytes
> are not read (say 998 are), and I get the CommErrorEventHandler event
> fired.
>
> I don't know if it is the serial driver or the UART. What actually
> happens is that within the OpenNETCF code, the
> "m_CommAPI.WaitCommEvent(hPort, ref eventFlags)" call fails, and when
> "m_CommAPI.ClearCommError(hPort, ref errorFlags, commStat)" is called,
> errorFlags has (only) the OVERRUN bit set. This code interprets this
> as a UART error.
>
> (This code can be found at
> http://www.opennetcf.org/SourceBrowse/view.aspx?f=d:/sites/OpenNETCF/InetPub/wwwroot/Source/OpenNETCF/IO/Serial/Port.cs
> - about line 913 - 1011)
>
> So I am at a bit of a loss...
> It doesn't appear to be related to how fast my app reads the data - I
> am basically going full speed in a tight loop. The buffers I am using
> (which get passed to "m_CommAPI.SetupComm(hPort, rxBufferSize,
> txBufferSize") are large - 10000 bytes.
>
> It would seem to me that the best approach at this point is to:
> a) Try and get hardware handshaking to work. The external device
> supports DTR/DSR)
> b) Rewrite in C (to bypass any problems with OpenNETCF/CF.NET?)
>
>
> pietdesomere@xxxxxxxxx (Piet) wrote in message
> news:<b498cce3.0504042314.1fc30326@xxxxxxxxxxxxxxxxxx>...
>> What do these percentages mean? Do you lose 8% of the bytes?
>>
>> Do you know if it's the UART's FIFO buffer or the Serial Driver's
>> buffer that overruns? Do you have debug output from the serial driver?
>>
>> If it's the UART's FIFO buffer: I think you should be fast enough to
>> read even at 115200, and if you are not handshaking should solve this.
>> You say it makes no difference, this could mean it's not enabled on
>> the other side. Can you change the settings for the thing you're
>> communicating with?
>>
>> If it's the Serial Driver's buffer that overruns, your application is
>> not reading fast enough. If you create a loop that does nothing except
>> reading from the COM port, and you read say 4K at a time, and you
>> still have problems the problem is probably not in your application.
>>
>> From your description it's most likely the UART buffer so I think you
>> will need handshaking.
>>
>> Regards,
>> Piet
>>
>> andrew_revell@xxxxxxxxxxx (Andrew Revell) wrote in message
>> news:<6dd1a40b.0504041731.3f59cd91@xxxxxxxxxxxxxxxxxx>...
>> > I am writing an application on the following platform:
>> >
>> > Advantech 133Mhz PCM3348.
>> > Windows CE 5.0 (Build 1400).
>> > Compact Framework
>> > OpenNETCF SDF 1.2.
>> >
>> > What I am experiencing is within my C# code, I am occasionally getting
>> > a UART: Overrun error (caught by the handler for
>> > CommErrorEventHandler).
>> >
>> > The pattern is roughly:
>> >
>> > 9600 baud ? no errors (or so few I never see them).
>> > 19200 baud ? errors about 8% of the time.
>> > 115200 baud ? errors about 11% of the time.
>> >
>> > Number of errors also increases as the number of received increases.
>> >
>> > Along with the CommErrorEventHandler event being fired, the received
>> > buffer is usually missing a char or two (out of 1000). The position of
>> > the missing char is random.
>> >
>> > Things that do not seem to make a difference:
>> > Handshaking (DSR/DTR, CTS/RTS etc)
>> > Buffer sizes (I have set to 10 times maximum receive buffer).
>> >
>> > I have also given the "Installable ISR" serial driver a go, by putting
>> > entries such as:
>> > "Irq"=dword:4
>> > "IsrDll"="isr16550.dll"
>> > "IsrHandler"="ISRHandler"
>> >
>> > This _appears_ to improve matters, but not fix completely.
>> >
>> > I have tried this with another .Net library as well (CFSerialClass).
>> > The number of errors are less, but not much.
>> >
>> > What I would appreciate advice on is:
>> >
>> > Is this a common problem when dealing with serial?
>> > Are these errors just a fact of life with serial? But surely 19200
>> > isn't too fast for it to handle?
>> > Should I try writing direct eVC++ code? Will this help?
>> > Are there settings in the Device Control Block that could help here?
>> > Should I try changing serial interrupt priorities? If so, how?
>> >
>> > I guess I am searching for ways of narrowing this down. Is it
>> > OpenNETCF, .NET, Windows CE, my hardware??.?


.



Relevant Pages

  • Re: Thorny Serial Comms "UART: Overrun" error Windows CE 5.0
    ... If it does not uses PDC or DMA, this could explain the overruns ... > I don't know if it is the serial driver or the UART. ... >> Do you know if it's the UART's FIFO buffer or the Serial Driver's ... and if you are not handshaking should solve this. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Thorny Serial Comms "UART: Overrun" error Windows CE 5.0
    ... Do you know if it's the UART's FIFO buffer or the Serial Driver's ... and if you are not handshaking should solve this. ... If it's the Serial Driver's buffer that overruns, ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Monitor RS232 Line Communication - PC hookup
    ... If you really don't want to implement handshaking then as ... > the device can process commands anyway. ... Then tried 300baud with the USB to serial adaptor, ... (header errors, not buffer overflow). ...
    (comp.arch.embedded)
  • Re: UART
    ... A lot of the time those handshaking signals run across the same chip ... where the UART function is found. ... and argue that the buffer and it's controller are ... merely part of a driver transformed into hardware. ...
    (comp.arch.embedded)
  • Re: Playing multiple mp3s simultaneously
    ... OpenNETCF definitely can't do it. ... decode the data to a buffer that you mix either before playing or during ... playback. ...
    (microsoft.public.dotnet.framework.compactframework)