Interrupts

Read time: 31 minutes (7997 words)

Polling to check a signal works, but the processor still needs to check things periodically. This puts a load on the chip we really do not need. What we really need is a way to set an alarm that will go off when we need to react to something, and that is why interrupts were invented!

What is an interrupt?

Most computer systems support the idea of an interrupt. Basically, an interrupt is just a signal generated by some device and sent to the processor. These events happen at unpredictable times. The source of the interrupt can be external or internal. The AVR can sense signals though the I/O pins on the chip Internal devices can generate them as well, and that is what we will be examining in this lecture.

We will set up Timer0 so it generates an interrupt when it rolls over.

Asynchronous events

Interrupts are asynchronous events, meaning we do not know exactly what we will be doing when they happen. The chip handles interrupts using something like a procedure call. The bad thing is that this call might happen in the middle of your code, not at some point where you would be happy to take a break!

We need to preserve the state of the chip before dealing with the event. When we return, the original code should not know this happened!

Recognizing the interrupt

We can turn all interrupts on or off with code. The AVR has a Global Interrupt Enable flag which basically shuts off the entire interrupt system.

Every internal device that can generate an interrupt has an enable flag We need to set all these bits correctly for the interrupt system to work.

Controlling the global interrupt system

If allowing interrupts might cause problems, we can do this:

  • CLI - disable interrupts
  • SEI - enable interrupts

The processor is initialized on power-up with interrupts disabled.

Handling the interrupt

Basically, the interrupt is handled by a special procedure call. It happens between two instructions right after the event. We need to set up code for the procedure at specific addresses associated with the particular interrupt. The interrupt system will make sure that the correct interrupt procedure is called for that particular device. We need as many handlers as we have interrupt sources.

AVR Interrupt table

To handle all potential sources of interrupts, the AVR sets up a jump table, also called an interrupt vector table. This table starts at address 0x00. If we are not using the interrupt system, we cna eliminate this table by providing a special flag to the compiler.

Note

I added a way to decide if you want to use the interrupt system in your AVR projects. Just add a line in your Makefile that looks like this:

NOINTS := TRUE

In avr-build.mk make these changes:

ifeq ($(NOINTS), TRUE)
    LFLAGS += -nostartfiles
endif

The original Makefile system always eliminated this table, meaning the interrupt projects will not work properly!

Each entry in this table is just a jump to the actual procedure code needed. We only need entries at places where we want to handle specific interrupts. The other jump table locations could be left blank, but the compiler generates a table with a jump to location zero for any interrupt that you do not use. The zero address is reserved for the reset interrupt which directs the processor to the start of your program!

New style AVR code

To get things working with avr-gcc, we need to change code a bit. The linker will set up the interrupt vector table. Unfortunately, some simple code becomes not so simple We will use macros to make things work correctly! avr-gcc will set up the chip!

Interrupt handler code

The actual handler code looks like other procedures, except this one ends with a new instruction:

InterruptHandler:
            ...
            reti
  • The last instruction is vital. It resets the interrupt system after each interrupt is recognized.

The Reset Vector

One special signal related to the interrupts, but is a bit different. This one happens when powering up of the processor. Some systems have a reset button, which directs the processor to the reset handler. avr-gcc will set this up so your main entry point gets called on reset.

Saving Processor State

We need to save the processor state in our handlers. The question is where to save this data! I know, use the stack!

We need to be careful here, not to save too much, or too little. Save any registers you intend to use. But we need to also pay attention to any other registers the user might be using. For instance, we need to save the system flag register SREG as well. The interrupted code will thank you!

Using interrupts with Timer0

Let’s put this all together with a simple example.

Our polling code checked the Timer0 Overflow (TOV0) interrupt flag. This flag was being set by the timer, but did not generate an interrupt. In fact, we were running with interrupts disabled!

To generate an interrupt, we need to reprogram the timer (and chip). We will use the blinking light for this example. Again, we want the LED to blink once per second

Sample program

This program will consist of a main routine and timer code in separate files

#include "config.h"

        .extern Timer0Setup
        .global main

        .section    .text
main: 

        ; set up the system clock
        ldi     r24, 0x80               ; set up prescaler
        sts     CLKPR, r24
        sts     CLKPR, r1               ; set to full speed

        ; set up LED port
        sbi     _(DDRB), 5              ; set up the output port (bit 6)
        cbi     _(PORTB), 5             ; start off with the LED off

As usual, project configurarion details are defined in config.h.

This code does the normal processor setup, and configures the LED so we can make it blink.

The interrupt jump table

Interrupts are managed using a “jump table” in low memory. This table will be set up by avr-gcc during the link step i building youe applicarion. We need to declare labels defined in the include files for this chip to set things up properly, something we do in timer.S.

        .global     TIMER0_OVF_vect
TIMER0_OVF_vect:
  • The linker will place a jump to this routine in the table at the right spot

Finishing up

Back in our main program, we cna continue to do whatever work we need. In this example, we will do nothing! (All the magic happens in the interrupt code!)

        call    Timer0Setup             ; initialze the timer
1:      rjmp    1b   

Huh? Where is the work going to happen? In the handler!

In this simple example, we really have no work for the program to do, other than what will happen when interrupts occur. For that reason, we simply put the main code in an infinite lop. The interrupts will happen, and the processor will take care of those events with the code we provide.

Timer code

timer.S starts up with this code

; timer.S - Timer0 code for blink

#include "config.h"

        .global Timer0Setup

        .section    .data

ISRcount:   .byte   0

#define MAX_ISR 61

We will discuss the ISRcount data item later.

Timer setup

Set up the timer prescaler value here

        .section    .text

;----------------------------------------------------------------------
; Initialize Timer 0 for interrupts
;
Timer0Setup:
        in      r16, _(TCCR0B)
        ori     r16, (1 << CS02) | (1 << CS00) ; divide by 1024
        out     _(TCCR0B), r16      ; set timer clock

Enabling interrupts

One simple line tells the timer module to generate an interrupt signal when overflow happens. The same flag we watched for the buzzer project is being used, but now the processor will be notified when overflow happens.

        out     _(TCCR0B), r16      ; set timer clock
        sbi     _(TIFR0), (1<< TOV0); clear interrupt flag
;
        lds     r16, TIMSK0         ; get interrupt mask reg
        ori     r16, (1 << TOIE0)   ; enable interrupts
        sts     TIMSK0, r16
        out     _(TCNT0), r1        ; zero the timer counter
        sts     ISRcount, r1        ; and our counter variable
        ;
        sei                         ; let the fun begin
        ret

The sei line turns on the interrupt system, and we are now ready for the timer interrups, except we need to show the handler code!

The handler code

Finally, we need our handler code:

;----------------------------------------------------------------------
; Timer0 overflow ISR
;

        .global     TIMER0_OVF_vect
TIMER0_OVF_vect:
        ; save callers registers
        push    r1
        push    r0
        in      r0, _(SREG)
        push    r0
        eor     r1, r1
        push    r24
        push    r25
        ;

This code protects the important registers in the chip, and any registers we plan on using in our code.

Do the work

We let the handler toggle the LED on/off

        ; toggle LED port
        in      r24, _(PORTB)       ; get current PORTD
        ldi     r25, (1 << LED_PIN) ; LED bit position
        eor     r24, r25            ; toggle bit
        out     _(PORTB), r24       ; set back in place

Finishing up

Finally, we restore the system state

        ; recover user's registers
        pop     r25
        pop     r24
        pop     r0
        out     _(SREG), r0            
        pop     r0
        pop     r1
        reti

Wow - we are blinking fast

  • The above code blinks about 61 times per second.
    • Let’s try a simple trick.

Create a simple counter variable. We will have the interrupt handler increment the counter each time it is called. We will let this counter count up to 61, then trigger our LED toggle code. We will then reset the counter as we toggle the LED and start over. With any luck, we will end up with a blink every second.

counter setup

We need a counter variable

        .section    .data

ISRcount:   .byte   0

#define MAX_ISR 61

This was shown earlier.

We need to set the counter in the setup code

        out     _(TCNT0), r1        ; zero the timer counter
        sts     ISRcount, r1        ; and our counter variable

All we do here is zero the counter using our handy zero in r1.

Adding the count logic

In the handler, add this code to increment the counter

        ; bump the ISR counter
        lds     r24, ISRcount       ; get current count
        inc     r24                 ; add one
        sts     ISRcount, r24       ; put it back
        ;

Blinking only when the count is reached

        ; test the counter to see if we toggle the LED
        lds     r24, ISRcount       ; needed?
        cpi     r24, MAX_ISR        ; one second is 61 interrupts
        brcs    1f                  ; skip if not
        ;

The label (1) is after the blink logic, just before we restore all the registers and end the handler.

Resetting the count on toggle

  • The last thing we do is reset the counter after toggling the LED
        out     _(PORTB), r24       ; set back in place
        sts     ISRcount, r1        ; sero the counter

Notice the line that resets the counter for the next pass.

This now blinks (toggles) once per second!

This simple scheme to delay actions until some number of interrupts is seen is a simple mechanism to adjust when events are handled. We will use it later, when we explore a simple multi-tasking kernel for AVR projects.

Single Makefile

Since the Makefile setup we used for the simulator project was really designed to build example code to run in that simulator, it is not ideal for just building simple AVR code. So, I am providing a simple Makefile you can drop into any folder with the required AVR source code files, and it should build just fine. Be sure to make the needed changes so you are using the right PORT and chip. The Makefile is set up to run on my Mac at the moment:

Makefile
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
# source files
TARGET	:= $(shell basename $(PWD))
CSRCS	:= $(wildcard *.c)
COBJS	:= $(CSRCS:.c=.o)
SSRCS	:= $(wildcard *.S)
SOBJS	:= $(SSRCS:.S=.o)
OBJS	:= $(COBJS) $(SOBJS)

LST	:= $(TARGET).lst

# define the processor here
MCU		:= atmega328p
FREQ	:= 16000000L

# define the USB port on your system
#PORT	:= /dev/ttyACM0
PORT	:= /dev/tty.usbmodem14101
PGMR	:= arduino

# tools
GCC		:= avr-gcc
OBJDUMP	:= avr-objdump
OBJCOPY	:= avr-objcopy
DUDE	:= avrdude

UFLAGS	:=  -v -D -p$(MCU) -c$(PGMR)
UFLAGS		+= -P$(PORT)
UFLAGS		+= -b115200

CFLAGS	:=  -c -Os -mmcu=$(MCU)
CFLAGS		+= -DF_CPU=$(FREQ)

LFLAGS	+= -mmcu=$(MCU)

.PHONY all:
all:	$(TARGET).hex $(LST)

# implicit build rules
%.hex:	%.elf
	$(OBJCOPY) -O ihex -R .eeprom $< $@

%.elf:	$(OBJS)
	$(GCC) $(LFLAGS) -o $@ $^ 

%.o:	%.c
	$(GCC) -c $(CFLAGS) -o $@ $^

%.o:	%.S
	$(GCC) -c $(CFLAGS) -o $@ $<

%.lst:	%.elf
	$(OBJDUMP) -C -d $< > $@

# utility targets
.PHONY:	load
load:
	$(DUDE) $(DUDECONF) $(UFLAGS) -Uflash:w:$(TARGET).hex:i

.PHONY:	clean
clean:
	$(RM) *.hex *.lst *.o *.elf

Use this Makefile to run this project, and the final project as well. Both of those use interrupts. It would work for the Blink project if you add the -nostartfiles flag to the LFLAGS variable.