Termios Problem

[Mike Siers]

Hi Thomas,
Attached is the interrupt handler if you want to take a look
at it.  Basically I think the interrupt handler is getting
called when the transmit buffer is empty.  So it is passing
a one to rtems_termios_dequeue_characters().  This increments
the t_dqlen value by one and calls the rtems_termios_refill_transmitter()
function.  Under normal circumstances, this function copies the
t_dqlen value and then sets the t_dqlen value to zero.  But
if the buffer is empty, the t_dqlen value is not reset to zero.
So the next transmit request will send more data values than
are in the transmit buffer.

I could have the BSP's interrupt handler not enable tx interrupts
when it notices the buffer is empty.  But how does the BSP know
when the transmit buffer is empty without having knowledge about 
the tty data structure?

Mike Siers


> -----Original Message-----
> From: Thomas Doerfler [mailto:Thomas.Doerfler at imd-systems.de]
> Sent: Friday, September 28, 2001 12:47 PM
> To: Mike Siers
> Cc: joel at oarcorp.com
> Subject: Re: Termios Problem
> 
> 
> Hello Mike,
> 
> > 
> > I traced the problem to the following functions.  The 
> transmit interrupt
> > handler
> > was calling the function rtems_termios_dequeue_characters().  
> This function
> > increments a dequeue length variable and then calls the 
> function
> > rtems_termios_refill_transmitter().  The problem is that 
> when the transmit
> > buffer is empty, the dequeue length variable is not reset to 
> zero.  So the
> > next valid transmit request was sending extra data.  
> Resetting the dequeue
> > length variable to zero, fixes the problem.
> 
> If I got you right, then the termios tx buffer pointers and 
> t_dqlen run somewhat out of sync. I think this might happen, 
> when you call rtems_termios_dequeue_characters() with a "len" 
> parameter, that is bigger than it should be. Keep in mind, 
> that you always should set the "len" parameter to the number 
> of bytes that have been actually sent out. So when you have 
> sent three bytes, len should be 3 (and not the maximum number 
> of characters that the hardware is able to send out in after 
> one service). When you get "empty" transmit interrupts (maybe 
> they signal, that the transmitter IS empty, and not HAS JUST 
> BECOME empty), then you should not call 
> rtems_termios_dequeue_characters() at all. 
> 
> Hm. Maybe that helps a bit. I am currently working with rtems-
> 4.5.0, so there is no coldfire bsp included. If you like, you 
> can send me the coldfire "console" module and I might have a 
> look at it (out of curiosity).
> 
> Bye,
> 	Thomas.
> 
> > 
> > Any thoughts?  Should this problem be fixed with a simple 
> change to
> > the termios code?  Or should I have to make the fix in the 
> BSP code
> > to ensure that transmit iterrupts are not enabled when the 
> buffer is empty.
> > 
> > Thanks
> > Mike Siers
> > 
> > 
> > 
> 
> --------------------------------------------
> IMD Ingenieurbuero fuer Microcomputertechnik
> Thomas Doerfler           Herbststrasse 8
> D-82178 Puchheim          Germany
> email:    Thomas.Doerfler at imd-systems.de
> PGP public key available at: http://www.imd-
> systems.de/pgp_key.htm
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: console.c
Type: application/octet-stream
Size: 21478 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20010928/7f5e0b52/attachment-0001.obj>