CS452 - Real-Time Programming - Spring 2008

Lecture 23 - Serial Server

Questions & Comment

1. 16550 UART

Serial Server

Policy issues

1. One or two servers?
2. How should screen echo be handled?
   • and DELETE/BS, and line-editting, and ...
3. How should the buffers in the UART be handled?
4. Who will initialize the hardware?
5. What traffic do I expect through the server?
6. Should the be I/O units above the single character level?

As a general policy we would like to concentrate the hardware dependence

Hardware

RS232

UART

Five interrupts

1. Transmit buffer empty
2. Receive buffer not empty
3. Line status changed
4. Modem status changed
5. Character timeout

Twelve registers.

• 0 (read) Data to transmit
• 0 (write) Received data
• 0 (dlab set) Divisor latch
• 1 Interrupt enable: R/W
  • [0] received data, and character timeouts
  • [1] transmit buffer empty
  • [2] line status
  • [3] MODEM status
  • What about character timeout
• 1 (dlab set) Divisor latch
• 2 (read) Interrupt identification: R
  • xxxxxxx1: no interrupt
  • xxxx0110: receiver line status
    • overrun, parity, framing, break
    • cleared by reading register 5
  • xxxx0100: received data available
    • character in buffer, OR trigger level reached (FIFO)
    • cleared by reading register 0, OR reading register 0 enough times that the FIFO drops below the trigger
  • xxxx1100: character timeout (FIFO only)
    • no characters received since ?? and one character available
    • cleared by reading register 0
  • xxxx0010: transmitter buffer empty
    • cleared by writing register 1 or reading register 2
  • xxxx0000: MODEM status
    • CTS, DSR, etc
    • cleared by reading register 6
• 2 (write) FIFO Control: W
  • [0] enable both FIFOs
  • [1] clear receive FIFO
  • [2] clear transmit FIFO
  • [67] trigger level in receive FIFO
• 3 Line control: R/W
• 4 Modem control (DTR, RTS): R/W
  • [0] set DTR
  • [1] set RTS
  • [4] enable loopback (for debugging)
• 5 Line status (Enables divisor latches): R
  • [0] data ready
  • [1] overrun error: data lost or (FIFO) more data beyond trigger level
  • [2] parity error
  • [3] framing error
  • [4] break interrupt
  • [5] transmit buffer empty
  • [6] transmitter empty and transmit buffer empty
• 6 Modem status (DSR, CTS): R
  • [4] CTS
  • [5] DSR
  • [7] DCD
• 7 Scratch

Accessing the registers

Stubs

int Get( int port );

int Put( int port, int c );

Both are Sends to a serial server

Software

Task Structure

1. simplest, which is usually best
   • Notifier AwEv, Send
   • Server
2. buffer send
   • Notifier: AwEv, Receive, Reply
   • Courier: Send, Send
   • Server
3. guards with couriers

   Guards only make sense if there are are lots of clients, which might happen if

   • there is input to be broadcast
   • the server is demultiplexing several input sources or output destinations

   Structure

   • Notifier
   • Courier
   • Server
   • Courier
   • Guard

What, if anything, should we do about the FIFO?

• Maybe it's just plain obsolete

Should we have one server for input, one for output?

• echo?

These components merely handle a generic serial line.

• Sometimes we can take advantage of structure in the input.

More than one Notifier

One (or more?) server(s)

What about guards?

• Does it make sense to have more than one reader/writer task per port?
• If it does how should they be related?

Return to:

• Bill Cowan's Winter 2008 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page