termios support

[Eric Norum]

I sent this yesterday, but it never showed up......

> Hello !
>
> To sum up, David and I did a console driver for our boards,
> respectively the SBC 5206 (Coldfire) and 68340, with termios
> support We seem to have reached the same point: it does not really
> work. Indeed a single "printf" leads to the termios buffer looping
> round so we get the same string again and again.
>
> I've been looking at the termios code, the gen68360 bsp and many
> questions
> came into sight.
>
> To my opinion, the driver should work like this:
> 1. in the init code, enable the Rx Ready interrupt, not the Tx
> Ready one 2. when console_write is called, call rtems_termios_write
> to fill the output buffer, then enable Tx Ready interrupt
> 3. When there's nothing left in the output buffer, disable Tx
> interrupt
>
> The problem is that, from what I understand, all the interrupts are
> enabled
> in the init code, so that the InterruptHandler function is
> immediately called, even if the buffer is empty.
> At the moment, the InterruptHandler function calls
> rtems_termios_dequeue_characters function, in which stg strikes me:
>
> newTail = (tty->rawOutBufTail + len) % RAW_OUTPUT_BUFFER_SIZE;
> if (newTail == tty->rawOutBufHead) {
> /* buffer empty */
>
> The rtems_termios_open implies tty->rawOutBufTail equals
> tty->rawOutBufHead
> so that termios emits "\0" character as soon as the interrupts are
> enabled.
>
> So, tell me if I'm wrong, but I would:
> 1. add two functions: console_enable_tx_interrupts and
> console_disable_tx_
> interrupts.
> 2. when buffer is empty (in rtems_termios_dequeue_character),  
call> console_disable_tx_interrupts
>

You may have taken too much of the 68360 device-dependent code into  
your driver.  The 68360 serial ports are handled by a Communications  
Processor Module (CPM) that takes care of many of the low-level  
details of sending and receiving characters.  Because of this  
hardware support, the 68360 can run with transmitter interrupts  
enabled `all the time'.

Your device-dependent code, on the other hand, has to take care of  
stuffing characters into the UART output register itself.  Because of  
this you have to worry about when to enable/disable interrupts.  But  
this enabling/disabling should be done in the device-dependent  
portion of your driver I/O code -- NOT in the device-independent  
termios routines.

> And is it necessary to disble all the interrupts, couldn't we just
> disable
> UART interrupts??

The termios-level code doesn't `know' about things like UART  
interrupts, so it just blocks all interrupts.  The blocking time is  
brief, though.  An alternative solution would be to handle serial I/O  
(or *all* I/O for that matter) like the network code does -- a  
separate read thread and write thread for each I/O device.  Then all  
(or at least most) of the code now protected by interrupt blocking  
would turn into sections of code protected by a semaphore.

This is a big (and IMHO desirable) change that shouldn't be allowed  
to hold up the 4.0 release.


So I guess my bottom line on all this is that the existing termios  
code is not in (immediate) need of change.........

Rebuttals and counter-examples are welcomed.

---

---
Eric Norum                                 eric at skatter.usask.ca
Saskatchewan Accelerator Laboratory        Phone: (306) 966-6308
University of Saskatchewan                 FAX:   (306) 966-6058
Saskatoon, Canada.