Developing interrupt driven serial driver


I am writing driver code for the serial communications interface (SCI) of the TI TMS320F2812.

So far I have been developing a set of functions analagous to C stdio stream IO calls that allow me to communicate via a RS232 link to a PC. The 16-byte receive and transmit FIFOs are utilized by the lowest level getc/putc functions. The other functions merely call getc/putc:

These functions work Ok:

int SCIb_getc(void); int SCIb_putc(int);

int SCIb_gets(char *s, int size); int SCIb_puts(const char *s);

These are not yet implemented, but will be for binary block transfer:

uint16 SCIb_write(const void *ptr, uint16 size, uint16 count); uint16 SCIb_read(void *ptr, uint16 size, uint16 count);

There are some other functions for initialization, setting baud, control char handling, echoing, etc.

My next task is to make this driver codebase interrupt driven. I am first trying to understand all of the reasons for using interrupts, and what the range of implementation possiblities might be.

So far I can see the following reasons to use interrupts:

  1. To implement flow control at the driver level. For ex., the simplest case would be to have the FIFO threshold interrupt handler deassert CTS so that the DTE would stop sending when the FIFO is full. The SCIx_getc() code could then reassert CTS when the FIFO has fallen below some threshold.

Interestingly, I have just learned that the RS232 standard does not provide for hardware flow control in the RxD direction. It would seem highly non-standard to use the DTR/DSR pair here. Thus, the transfer protocol level would have to ensure that the DTE doesn't get overrun. For my devices, this shouldn't be an issue. They will do much more receiving than transmitting.

  1. To increase the effective size of the FIFO buffer. By having the interrupt handler for the receiver put the data into a larger buffer than the 16 byte FIFO, and base the CTS state on the condition of the larger buffer rather than the FIFO then the user code can process data in larger chunks and less frequently.

This might increase throughput somewhat, but doesn't solve the fundamental problem of needing flow control. It just trnasfers the problem of buffer overrun from the hardware FIFO to the software buffer. Thus, either hardware must still do this via CTS or the protocol needs to be able to stop the DTE. If the protocol is XMODEM for instance, and the buffer is >=132 bytes, then I suppose this would guarantee no overruns.

One application will have a mixture of binary file transfer from DTE->DCE which will be XMODEM-like so this will be fine. However, it will also have a text command language, so it is conceivable that the buffer could overflow before the command processor had a chance to digest commands, if a machine was sending the commands rapidly. Thus, hardware flow control would be needed here, or limiting the data rate.

  1. It is possible for the SCI interrupts to call user code. Ie, the user can "register" a user function with the driver. Then the user could be "forced" to process data before the buffer overflows.

I don't particularly like this, nor do I think it is typical.

What can I expect of typical PC serial port drivers, on Windows and Linux? What do they do with the RTS/CTS and DTR/DSR lines?

Obviously I am learning about this by doing and for the first time. Comments regarding the direction I am taking and my understanding of the purpose for interrupts in a serial driver are welcome.

Good day!

 Click to see the full signature
Reply to
Chris Carlen
Loading thread data ...

Look at this example from Atmel. It should be very similar for the TMS320F2812 except for the hardware register. It should be easy to adapt for the TMS320F2812.

// AVR306: Using the AVR UART in C // Routines for interrupt controlled UART // Last modified: 02-06-21 // Modified by: AR

/* Includes */ #include #include

/* UART Buffer Defines */ #define UART_RX_BUFFER_SIZE 128 /* 2,4,8,16,32,64,128 or 256 bytes */ #define UART_TX_BUFFER_SIZE 128

#define UART_RX_BUFFER_MASK ( UART_RX_BUFFER_SIZE - 1 ) #if ( UART_RX_BUFFER_SIZE & UART_RX_BUFFER_MASK ) #error RX buffer size is not a power of 2 #endif

#define UART_TX_BUFFER_MASK ( UART_TX_BUFFER_SIZE - 1 ) #if ( UART_TX_BUFFER_SIZE & UART_TX_BUFFER_MASK ) #error TX buffer size is not a power of 2 #endif

/* Static Variables */ static unsigned char UART_RxBuf[UART_RX_BUFFER_SIZE]; static volatile unsigned char UART_RxHead; static volatile unsigned char UART_RxTail; static unsigned char UART_TxBuf[UART_TX_BUFFER_SIZE]; static volatile unsigned char UART_TxHead; static volatile unsigned char UART_TxTail;

/* Prototypes */ void InitUART( unsigned char baudrate ); unsigned char ReceiveByte( void ); void TransmitByte( unsigned char data );

/* Main - a simple test program*/ void main( void ) { InitUART( 11 ); /* Set the baudrate to 19,200 bps using a 3.6864MHz crystal */

_SEI(); /* Enable interrupts => enable UART interrupts */

for( ; ; ) /* Forever */ { TransmitByte( ReceiveByte() ); /* Echo the received character */ } }

/* Initialize UART */ void InitUART( unsigned char baudrate ) { unsigned char x;

UBRR = baudrate; /* Set the baud rate */ /* Enable UART receiver and transmitter, and receive interrupt */ UCR = ( (1

Reply to

While I don't have the EIA/TIA standard in front of me, there is always flow control support in both directions AVAILABLE using normal signal lines on RS-232. For instance, if the DTE side of the 232 connection wants to stop the DCE from sending, it can drop any of its outputs to communicate this fact.

So it can drop DTR or RTS. RTS is definitely more common, but DTR is definitely used in some circles and supported. Microsoft, through their COMM api (I can get the details if you need this) can be configured for DTR/DSR flow control.

If its the DCE side you are talking about, then the DCE can drop CTS or DSR. Certainly CTS is more popular, but DSR works too.

There's a difference between non-standard, and not popular. See above. I use DTR/DSR flow control in my embedded hobby application because the particular implementation of the USB->serial converter chip I am using only supports DTR/DSR (and not rts/cts. and hence an example where a manufacturer chose to support dtr/dsr over rts/cts)

I don't think Linux has support for DTR/DSR flow control, at least not in any common recent major released/supported kernel. I searched for this awhile ago, and I forget the exact hangup on why or what the problem was in supporting it.

But for Windows, DTR/DSR is definitely common enough that it's supported in the base API's without hacks/additions.

As far as what they DO with it, you have to configure what mode you want the serial port to operate in. Dunno how specific you want, but if the receive buffer of PC fills, it drops RTS/DTR until that buffer has been emptied. Then it raises it again.

Dunno how much I've helped. My application is a async TTL-level 2mbps serial stream where the bulk of the conversation is microcontroller -> windows PC. The windows PC issues commands, and the uC responds with about 12K bytes of traffic -- with multiple commands / responses per second. Upwards of about 3 requests/responses second, if I'm doing the math right after a long day of Easter travel. :)

I've got a blog at

formatting link

that has covered some issues that you might run into. It's a rambling-style brain-dump, but if you can get past the format, you might find it interesting.



Reply to
Keith M


Thanks for the reply.

That's a pretty simple example. There isn't much going on there that I hadn't already inferred was the point of it all. I guess I'll just keep forging ahead.

Good day!

 Click to see the full signature
Reply to
Chris Carlen

If you want to do something else during sending or receiving of data then it's best to use a interrupt driven FIFO for rx and tx.

But if your aplication can sit and wait for rx or tx then it's ok not to use FIFOs.


"Chris Carlen" skrev i meddelandet news:

Reply to


., the




having the



e, and




=BF=BDIe, the


Hi, I have some serial routines, not for your chip though. Uses a software buffer instead of a FIFO, it's interrupt driven and uses XON/ XOFF comands for flow control. You may not be able to use them directly but it should show you how to go about it. Email me if you want them.

Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.