On Mon, 02 Feb 2004 21:48:26 +0100, Doublehp wrote:

>> 1)
> I have the same error when using iwrite since I have one char in the
> buffer after my write, that mean the serial port receives 3 chars
> instead of 2 !!!

I also made false steps with receiving the expected number of characters.
My program is W32 API but maybe your problem is the same. The 16550 UART
has a 16 bit FIFO to avoid the loss of incoming data. In Win32 you can 
setup the level on wich the kernal driver receives a interrupt for RX
pending data. That is usually 14 characters and if the kernel driver is 
a bit dilly-dally, there are still 2 more characters to buffer in Fifo 
until they are lost. 

The question is with the mon08 protocol if you only expect 3 characters. 
After the incoming 3 characters no interrupt will be generated by the
16C550 UART. Therefore the UART listens to RX line for a time of 3 more
characters. If there is no further data in this time, he will generate
a interrupt to flush its FIFO buffer. 

The kernel driver starts service for that interrupt but does not know
how many bytes are pending. Unfortunately in this time further bytes can
be rx - ed (from whatever the reason is like electrical noise spikes or
others). If you know read only the expected bytes by readfile, possibly
some bytes remain in the queue. I do not know the task mechanism in Linux
but windows uses a WaitForObjectEvent to notify the application for
incoming data. If the number of readed bytes and the number of incoming
bytes comes out of sync, you will read a previous pending byte with the
next event. This is specially the case for the break characters what
may insert a unknown number of bytes to the rx - data stream what the 
application is responsible to drop. 

Maybe the 16C550 problems are exactly same with Linux and I always only
can recommend to use external trace and see what really happens instead
of trusting own SW code. 

Hope to hear from your project again
& Good luck

I am not sure my problem is so complex: I have a bug only when
transmitting 2 chars: 0x0A and an other one I forgot (see prevew
posts)

Without heaving read all of this thread, you should look at the
ASYNC_LOW_LATENCY setting in the termio ioctls. Linux will delay
interrupting a program doing serial I/O until a certain time
has elapsed or enough characters have arrived to make the context
switch efficient.

I found this when addressing the same problem in my DB11, 68hc11
debugger for *nix - find it on my website as a free source download.

Clifford Heath.

I did not find ASYNC_LOW_LATENCY in any man page ... can you give more
details or a link ?

Doublehp wrote:
> I did not find ASYNC_LOW_LATENCY in any man page ... can you give more
> details or a link ?

DB11 isn't hard to find. Just google for my name.