Catch-22 (?), interrupt driven serial Tx, HCS12

Something like that was the case with the ACIA, MC6850 (ages ago but I am sure I am not the only one here who remembers it). Basically the way was to disable tx IRQ on the ACIA after the last character available on the output queue has been written to the output data register (this must be done in the IRQ handler), and enable the Tx IRQ every time you put a character on the output queue (or sort of, this not in the IRQ handler, obviously).

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

------------------------------------------------------

While I am not familiar with that particular processor, your (1) seems to say that just reading the status register in the interrupt routine should do it.

On every processor that I know of you can do at least one of the following:

1) Clear the interrupt request flag for the transmit interrupt (and it is edge sensitive so it doesn't automatically set itself again).

2) Disable the interrupt enable bit for the transmitter without disabling other interrupts for that serial port (in particular, the data received interrupt).

You need to clear the transmitter enable interrupt bit (TIE) before sending your last byte.

You can't clear TDRE without sending a character, as it is an indication that the buffer is empty.

Andy

Something like that is pretty typical in my experience. You mask off the TX IRQ when you empty the TX buffer, then turn it back on when you queue up the first byte.

Often you can't just turn on the IRQ and count on fact that the TX is empty cause an interrupt -- you have to interrogate the status of the TX, load it if it and your buffer are empty, and put stuff in the buffer if not.

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com

A better solution is to let the last character signal a TxIRQ and disable the IRQ in *that* "final" ISR (assuming, at that time, that you haven't discovered that you have something else to send).

Some (typ unbuffered) devices would corrupt a serialization in progress if the transmitter (*not* THR) was reloaded while "busy". So, if you later decided that you wanted to send another character (restart the transmitter), you would have to

*poll* the TxE bit waiting for the transmitter to be ready to accept another "write". Far easier (and more elegant) to have the transmitter time its own activity and signal (via TxIRQ) when it was appropriate to load the transmitter. [If you're going to disable the TxIRQ, you can just as easily disable it *after* it has done all of its work instead of *before*]

YMMV

[I don't know anything about the HCS12, so this response is based on my experiences with other MCUs.]

This is exactly what I do; there's never been a problem with turning off the Tx empty interrupt from within the interrupt handler when there's no more data to transmit and to me it seems like the standard way of handling this.

This is true on the PC style serial ports showing up on MCUs these days, but with the Atmel MCUs I used in the past, you could just turn on the Tx empty interrupt and let the MCU jump to your interrupt handler to load the initial character.

BTW, with the PC style serial ports, when queuing the first byte of the next batch of data to transmit, you need to turn on the Tx empty interrupt unconditionally and _before_ checking if Tx is empty so if it goes empty just after the check, it will be caught by the interrupt handler.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
[Note: email address not currently working as the system is physically moving] 
Microsoft: Bringing you 1980s technology to a 21st century world

Yes, and it's nice when you have interrupt hardware that supports that. But you can't count on it: you have to check.

Yea verily!

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com