How to detect which timer interrupt called callback when using ASF

avrinterruptstimerxmega

I have a general function, which gets passed among others a timer. It initializes the timer using common callback function:

void setup(config_t* config) {
    ...
    tc_enable(config.timer);
    tc_set_overflow_interrupt_callback(config.timer, common_callback);
    ...
}

That function might be called a few times with different configurations, timers included. In the interrupt callback I'd like to somehow identify which timer caused the callback.

void common_callback() {
    // Which timer called?
}

I did not find an asf tc_ function that would give me some kind of id.

I tried looking at TCXX.INTFLAGS, but the overflow flags seems to get reset by the asf code.
A hacky approach I could come up with is comparing the count register

Is there a simple way to do this using Atmel Software framework. I assume asf has an internal interrupt handler that does thing like reset the interrupt flags before calling the user defined callback. Another approach would be write similar tc_set_overflow_interrupt_callback-function that would keep some of that information.

Best Answer

The Atmel Studio Framework doesn't clear any of the flags and the underlying code is quite straightforward in that area. The callback routines get setup as follows:

void tc_set_overflow_interrupt_callback(volatile void *tc,
        tc_callback_t callback)
{
#ifdef TCC0
    if ((uintptr_t) tc == (uintptr_t) & TCC0) {
        tc_tcc0_ovf_callback = callback;
    } else
#endif
#ifdef TCC1
    if ((uintptr_t) tc == (uintptr_t) & TCC1) {
        tc_tcc1_ovf_callback = callback;
    } else
#endif
... etc for other timers

And the actual interrupt code is:

ISR(TCC0_OVF_vect)
{
    if (tc_tcc0_ovf_callback) {
        tc_tcc0_ovf_callback();
    }
}
... etc for other timers

The XMEGA is a little different to some processors in that some of the flags get cleared before the interrupt code is called rather than on return. For example the following is the description of the OVFIF flag:

This flag is set either on a TOP (overflow) or BOTTOM (underflow) condition, depending on the WGMODE setting. OVFIF is automatically cleared when the corresponding interrupt vector is executed. The flag can also be cleared by writing a one to its bit location.

One implication of using ASF is that the #ifdef directives above cause all interrupt vectors applicable to a device to be included once you include the timer/counter driver in the project.

But back to your original question as you've found those flags get cleared before the interrupt routine is called. After re-checking the documentation and taking a look at the various timer / interrupt flags before and after an interrupt in a debugger I can't see any way to achieve exactly what you're after. You might have to stick with a seperate callback for each timer that calls the main handler with a parameter. At least the code overhead shouldn't be too great because all the vectors are already included.

Related Solutions

Electronic – PIC32, XC32, timer interrupt vector not entered

I also had to turn on the global interrupts. Its somewhat of a hidden bit.

It is a bit within the Coprocessor status register, and you can enable it by using:

__asm__("EI");

or disable it by using:

__asm__("DI");

Simple Interrupt Handling program

You are correct with #2: two "threads" will be required.

Typically, your interrupt routine will save characters into a buffer. Your main program will continuously read the buffer, call detectString and implement your logic.

You can use hardware flow control if you're concerned about missing characters. One the buffer is full, you can make the sender wait until you're ready again.

Your FSM might be a switch statement inside your main loop.

EDIT: Some code:

/* UART0 Receive Interrupt Vector */
ISR(USART0_RX_vect)
{
    static uint8_t tmp;

    // calc next insert index & store character
    tmp = (uart0_rx_insert_idx + 1) % UART0_RX_BUFFER_SIZE;
    uart0_rx_buffer[uart0_rx_insert_idx] = UDR0;

    // check for more room in queue
    if (tmp != uart0_rx_extract_idx)
        uart0_rx_insert_idx = tmp; // update insert index

}

enum fsm {
    IDLE,
    MAGIC,
};

int main(void) {

    // setup
    enum fsm state = IDLE;
    uint8_t wordbuf[10];
    uint8_t wordbuf_index = 0x00u;
    setLed(0);
    uartSetup();

    //activate interrupts
    sei();

    // mainloop
    while (1) {

        switch (state) {
        case IDLE:

            if (characterInBuffer()) {

                // if buffer is full; word still not found
                // shift all characters by one
                if (wordbuf_index == sizeof(wordbuf) - 1)
                    memcpy(&wordbuf[1], &wordbuf[0], sizeof(wordbuf));

                // save current character
                wordbuf[wordbuf_index] = readCharacterFromBuffer();

                // increment index if not at end of buffer
                if (wordbuf_index != sizeof(wordbuf) - 1)
                    wordbuf_index++;

                if (detectString(wordbuf))
                    state = MAGIC;
            }

            if (getCharacter())

            break;

        case MAGIC:

            setLed(1);

            if (buttonPressed()) {
                setLed(0);
                state = IDLE;
            }

            break;
        } /* switch */
    } /* while */

return 0;
} /* main */

This would be for an Atmel AVR ATmega microcontroller. Many microcontrollers have static vector tables that store the addresses of interrupt service routines (ISRs for short) that are present in your code.

When a peripheral interrupt is activatde, such as the UART Receive interrupt in the example above, and global interrupts are enabled (sei() call), the microcontroller will stop executing the main code and start executing the ISR code. When the ISR exits, execution will resume in the main code.

There are microcontrollers that have a programmable vectored interrupt controller (VIC). With these, you can freely assign an ISR at runtime instead of compile time (and even switch at runtime!). The idea remains the same though:

hardware notices interrupt condition,
main program flow stops
ISR is executed
main program flow resumes

You can have mutex locks and spin locks in your code. You just have to be careful about dead locks and use proper types, i.e. atomic types.

There are some flavors of microcontrollers that have a hiararchical interrupt system: one type of interrupt can interrupt another interrupt. With these, you have to be especially mindful of using mutual exclusion and proper typing.

In general, ISRs are supposed to be very slim and should not have long pieces of code or loops in them. The reason is simple: While your ISR is being executed, the main program is not. Since the main program usually does something very useful, you wouldn't want it to be interrupt for a prolonged amount of time.

Having an operating system (OS) on microcontrollers is usually optional. You can certainly write one-off C code and be done with it. If you care about re-usability of your code or being able to use pre-existing code, you might want to look into ChibiOS, FreeRTOS, etc.

OSes will typically encapsulate the idea of interrupts (or even vectored interrupts) and present a common interface for your higher-level program. The workings "under the hood" are the ones described above though.

If you're looking to do many things in parallel and use threaded applications, you should definitely look into popular code. They usually have mutexes, spin locks, etc. pre-made and ready-to-use.

Best Answer

Related Solutions

Electronic – PIC32, XC32, timer interrupt vector not entered

Simple Interrupt Handling program

Related Topic