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

Implementing interrupt-driven serial output on an HCS12, I have to Do Things while the serial data is on its way so a simple wait loop waits too much time. On the HCS12 (may be typical of other CPUs), the serial interrupt flag is reset by:

(1) Reading the serial status register while the TDRE flag is set (Tx data reg empty). (2) Writing to the TXDR (ie. sending out another character).

How do I reset the interrupt flag without sending another character (which I defnitely don't want to happen here) if I have nothing more to send?

Reply to
Bruce Varley
Loading thread data ...

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

formatting link

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

formatting link

Reply to
dp

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).

Reply to
Richard Damon

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

Reply to
Andy Sinclair

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 
 Click to see the full signature
Reply to
Tim Wescott

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

Reply to
Don Y

[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] 
 Click to see the full signature
Reply to
Simon Clubley

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 
 Click to see the full signature
Reply to
Tim Wescott

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.