Re: Serial port read latency (SERIOUS - NEED HELP FAST!)
- From: "Gary G. Little" <glittle@xxxxxxxxx>
- Date: Mon, 16 Mar 2009 13:26:29 -0500
So, XP embedded does not "suffer" from the 10 ms quantum that XP suffers? In regular Windows XP, expecting a 5ms interval would normally encounter geers and cat-calls from the news group.
The 16550 has a 16 byte FIFO. How are you setting the FIFO trigger? Per character or on FIFO full? It should be set to per character. Is the 5ms "window" the only termination, or are you using a protocol that defines end of text or message? Also, what are the states of DCD, RTS/CTS, and DTR/DSR that you use, if you use them?
--
The personal opinion of
Gary G. Little
"Alexander Grigoriev" <alegr@xxxxxxxxxxxxx> wrote in message news:u9eJKDZpJHA.6132@xxxxxxxxxxxxxxxxxxxxxxx
In kernel mode: ExSetTimerResolution(10000, TRUE);
Which probably is about the same as NtSetTImerResolution(10000, TRUE, &iCurrentResolution);
In user mode:
timeBeginPeriod(1);
Also make sure:
1. your OVERLAPPED structures stay valid until the IO request is complete.
2. The handle is opened with FILE_FLAG_OVERLAPPED.
3. You could simply issue a ReadFile without ClearCommError. ReadFile will complete when there is 5 ms interval between received bytes.
4. Call SetupComm to set the RX buffer size.
"PeniWize" <PeniWize@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:DD363F16-9065-4490-A5EF-6D2CD00D0807@xxxxxxxxxxxxxxxxHi Alexander,
The read interval timeout is set to 5ms.
What method do you suggest to set the timer resolution to 1ms? I'm
currently calling "NtSetTimerResolution(0x1500, TRUE, &iCurrentResolution);".
"Alexander Grigoriev" wrote:
Why don't you use SetCommTimeouts with ReadIntervalTimeout=5ms.
Note that you need to set the timer resolution to 1 ms.
"PeniWize" <PeniWize@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E673D32C-4EF2-4927-8EE4-1C14489631A4@xxxxxxxxxxxxxxxx
> Hello everyone,
>
> I've got a serious problem that is killing our product and requires an
> immediate solution. Our situation is CRITICAL! Please do not reply > to
> this
> post unless you have genuinely useful feedback because otherwise those
> that
> can help may not respond thinking that someone else already did. > Thanks!
>
> We have implemented support for a real-time serial protocol in our > Windows
> XP Embedded based device. It uses a regular 16550 based UART/COM port > on
> the
> motherboard and the following settings: 19.2Kbps, space parity, one > stop
> bit,
> and eight data bits. The COM port is configured with COMMTIMEOUTS = > { 5,
> 0,
> 0, 0, 0 }. The machine contains a 1.6GHz Celeron M processor and 1GB > or
> RAM,
> which is not completely used.
>
> The protocol requires our embedded device to respond to a packet > within
> 20ms
> so it is imperative that our process receive the packet from the > kernel
> (serial.sys) as fast as possible. The end of a packet is identified > by
> 5ms
> or more passing between bytes. We've implemented several different
> solutions
> using both synchronous and overlapped I/O and have determined that the
> most
> reliable way to get the data as fast as possible is to start up a read
> thread
> with real-time priority and invoke ClearCommError() at 5ms intervals > while
> tracking the amount of data in the receive buffer with COMSTAT. > cbInQue.
> When the amount of data does not change for 5ms we call ReadFile() to
> obtain
> it. This solution seems to work fairly well for a few minutes and > then
> suddenly ReadFile() begins returning the data after 100ms or more > instead
> of
> the 10ms-15ms it was previously. It's also returning the data in
> non-contiguous fragments even though our serial line monitor shows > that
> the
> data is being sent to our device in one solid block (that never > exceeds
> 260
> bytes and is usually 32-48 bytes). The only "solution" we've found so > far
> is
> to shutdown and restart the process. We've even tried having the > process
> close and reopen the port with no success.
>
> I've considered modifying serial.sys to automatically handle packet
> reception at the device level, but I'm concerned that it wouldn't > solve
> the
> problem because it appears to be a latency issue coming from somewhere
> other
> than the driver. The protocol code is very large and complex so > moving it
> into a driver is so undesirable that we will probably move to embedded
> Linux
> instead (if it's necessary).
>
> Please help!
>
> Thanks,
> Matt
>
.
- Follow-Ups:
- Re: Serial port read latency (SERIOUS - NEED HELP FAST!)
- From: Ben Voigt [C++ MVP]
- Re: Serial port read latency (SERIOUS - NEED HELP FAST!)
- From: Alexander Grigoriev
- Re: Serial port read latency (SERIOUS - NEED HELP FAST!)
- References:
- Serial port read latency (SERIOUS - NEED HELP FAST!)
- From: PeniWize
- Re: Serial port read latency (SERIOUS - NEED HELP FAST!)
- From: Alexander Grigoriev
- Re: Serial port read latency (SERIOUS - NEED HELP FAST!)
- From: PeniWize
- Re: Serial port read latency (SERIOUS - NEED HELP FAST!)
- From: Alexander Grigoriev
- Serial port read latency (SERIOUS - NEED HELP FAST!)
- Prev by Date: Re: OID_GEN_PHYSICAL_MEDIUM for Bluetooth
- Next by Date: Re: Hibernation is in NT Service
- Previous by thread: Re: Serial port read latency (SERIOUS - NEED HELP FAST!)
- Next by thread: Re: Serial port read latency (SERIOUS - NEED HELP FAST!)
- Index(es):
Relevant Pages
|
Loading
