Bad Example of Interrupt Handling

In life, you need two examples: good one, and bad one. Here’s one of my bad design of interrupt handling.

The purpose of the firmware was to read a line (CR/LF terminated characters) from serial port, then parse it. Actually, I tried to port my simple AT handler from Java into C (AVR-GCC). It works, and as you can see, this program runs okay under x86 PC, but not under AVR with 8Mhz xtal.

Here’s the actual problem:

AVR Auto Power Mode Selection

To optimize the AVR’s power consumption, you will need to modify its power mode according to the peripheral that you need at that time.

This is the part of the TinyOS ATMega128 driver that you can use directly (without TinyOS). It will select the best power mode for the MCU, based on the peripheral(s) that is active.

AVR UDRIE vs TXCIE Interrupt

Newbies in AVR are always confused by these two interrupts (I’m not an exception here). What’s the difference between these two interrupts ? After googling for a while, I found avrfreaks forum discussion about the difference between the two (here).

To summarize the discussion:

Timing Diagram of UDRE vs TXC
Example for transmitting 2 bytes, loading on UDRE

Action    Flags         Comment
Startup   UDRE=1 TXC=0
Load UDR  UDRE=0 TXC=0  Software loads UDR
UDR->SR   UDRE=1 TXC=0  Hardware loads Shift Register
LOAD UDR  UDRE=0 TXC=0  Software loads UDR

after first byte finishes shifting
UDR->SR   UDRE=1 TXC=0  Hardware Loads Shift Register

after second byte finishes shifting
nothing   UDRE=1 TXC=1

Application
UDRE is normally used. TXC is normally not used, except for these situations:

• Half duplex communication, such as RS485: where the application needs to know whether all of the bits has been transmitted or not, before releasing the bus.
• Power saving mode: where the application needs to know whether the transmission has done, before switching to deeper power saving mode (where the UART peripheral is not available anymore).