Avoiding global variables when using interrupts in embedded systems

Question

Is there a good way of implementing communication between an ISR and the rest of the program for an embedded system which avoids global variables?

It seems that the general pattern is to have a global variable which is shared between the ISR and the rest of the program and used as a flag, but this use of global variables goes against the grain to me. I've included a simple example using avr-libc style ISRs:

volatile uint8_t flag;

int main() {
    ...

    if (flag == 1) {
        ...
    }
    ...
}

ISR(...) {
    ...
    flag = 1;
    ...
}

I can't see away around what is essentially a scoping issue; any variables accessible by both the ISR and the rest of the program must inherently be global, surely? Despite this, I've often seen people say things along the lines of "global variables are one way of implementing communication between ISRs and the rest of the program" (emphasis mine), which seems to imply that there are other methods; if there are other methods, what are they?

Answer 1

There is a de facto standard way to do this (assuming C programming):

• Interrupts/ISRs are low-level and should therefore only be implemented inside the driver related to the hardware that generates the interrupt. They should not be located anywhere else but inside that driver.
• All communication with the ISR is done by the driver and the driver only. If other parts of the program needs access to that information, it has to request it from the driver through setter/getter functions or similar.
• You should not declare "global" variables. Global meaning file scope variables with external linkage. That is: variables that could be called upon with extern keyword or simply by mistake.
• Instead, to force private encapsulation inside the driver, all such variables shared between the driver and the ISR shall be declared static. Such a variable is not global but restricted to the file where it is declared.
• To prevent compiler optimization issues, such variabels should also be declared as volatile. Note: this does not give atomic access or solve re-entrancy!
• Some manner of re-entrancy mechanism is often needed in the driver, in case the ISR writes to the variable. Examples: interrupt disable, global interrupt mask, semaphore/mutex or guaranteed atomic reads.

Answer 2

this use of global variables goes against the grain to me

This is the real problem. Get over it.

Now before the knee-jerkers immediately rant about how this is unclean, let me qualify that a bit. There is certainly danger in using global variables to excess. But, they can also increase efficiency, which sometimes matters in small resource-limited systems.

The key is to think about when you can reasonably use them and are unlikely to get yourself into trouble, versus a bug just waiting to happen. There are always tradeoffs. While generally avoiding global variables for communicating between interrupt and foreground code is a understandable guideline, taking it, like most other guidelines, to a religions extreme is counter-productive.

Some examples where I sometimes use global variables to pass information between interrupt and foreground code are:

1. Clock tick counters managed by the system clock interrupt. I usually have a periodic clock interrupt that runs every 1 ms. That is often useful for various timing in the system. One way to get this information out of the interrupt routine to where the rest of the system can use it is to keep a global clock tick counter. The interrupt routine increments the counter every clock tick. Foreground code can read the counter at any time. Often I do this for 10 ms, 100 ms, and even 1 second ticks.

   I make sure the 1 ms, 10 ms, and 100 ms ticks are of a word size that can be read in a single atomic operation. If using a high level language, make sure to tell the compiler that these variables can change asynchronously. In C, you declare them extern volatile, for example. Of course this is something that goes into a canned include file, so you don't need to remember that for every project.

   I sometimes make the 1 s tick counter the total elapsed up time counter, so make that 32 bits wide. That can't be read in a single atomic operation on many of the small micro I use, so that isn't made global. Instead, a routine is provided that reads the multi-word value, deals with possible updates between reads, and returns the result.

   Of course there could have been routines to get the smaller 1 ms, 10 ms, etc, tick counters too. However, that really does very little for you, adds a lot of instructions in place of reading a single word, and uses up another call stack location.

   What's the downside? I suppose someone could make a typo that accidentally writes to one of the counters, which then could mess up other timing in the system. Writing to a counter deliberately would make no sense, so this kind of bug would need to be something unintentional like a typo. Seems very unlikely. I don't recall that ever happening in well over 100 small microcontroller projects.

2. Final filtered and adjusted A/D values. A common thing to do is to have a interrupt routine handling readings from a A/D. I usually read analog values faster than necessary, then apply a little low-pass filtering. There is often also scaling and offseting that get applied.

   For example, the A/D may be reading the 0 to 3 V output of a voltage divider to measure the 24 V supply. The many readings are run through some filtering, then scaled so that the final value is in millivolts. If the supply is at 24.015 V, then the final value is 24015.

   The rest of the system just sees a live updated value indicating the supply voltage. It doesn't know nor need to care when exactly that is updated, especially since it is updated much more often than the low pass filter settling time.

   Again, a interface routine could be used, but you get very little benefit from that. Just using the global variable whenever you need the power supply voltage is much simpler. Remember that simplicity isn't just for the machine, but that simpler also means less chance of human error.

Answer 3

Any particular interrupt will be a global resource. Sometimes, however, it may be useful to have several interrupts share the same code. For example, a system might have several UARTs, all of which should use similar send/receive logic.

A nice approach to handle that is to place the things used by the interrupt handler, or pointers to them, in a structure object, and then have the actual hardware interrupt handlers be something like:

void UART1_handler(void) { uart_handler(&uart1_info); }
void UART2_handler(void) { uart_handler(&uart2_info); }
void UART3_handler(void) { uart_handler(&uart3_info); }

The objects uart1_info, uart2_info, etc. would be global variables, but they would be the only global variables used by the interrupt handlers. Everything else that the handlers are going to touch would be handled within those.

Note that anything which is accessed both by the interrupt handler and by the main-line code must be qualified volatile. It may be simplest to just declare as volatile everything that will be used at all by the interrupt handler, but if performance is important one may want to write code that copies information to temporary values, operates upon them, and then writes them back. For example, instead of writing:

if (foo->timer)
  foo->timer--;

write:

uint32_t was_timer;
was_timer = foo->timer;
if (was_timer)
{
  was_timer--;
  foo->timer = was_timer;
}

The former approach may be easier to read and understand, but will be less efficient than the latter. Whether that is a concern would depend upon the application.

Answer 4

Here's three ideas:

Declare the flag variable as static to limit the scope to a single file.

Make the flag variable private and use getter and setter functions to access the flag value.

Use a signalling object such as a semaphore instead of a flag variable. The ISR would set/post the semaphore.

Answer 5

I'm coding for Cortex M0/M4 at the moment and the approach we are using in C++ (there is no C++ tag, so this answer might be off-topic) is the following:

We use a class CInterruptVectorTable which contains all the interrupt service routines which are stored in the actual interrupt vector of the controller:

#pragma location = ".intvec"
extern "C" const intvec_elem __vector_table[] =
{
  { .__ptr = __sfe( "CSTACK" ) },           // 0x00
  __iar_program_start,                      // 0x04

  CInterruptVectorTable::IsrNMI,            // 0x08
  CInterruptVectorTable::IsrHardFault,      // 0x0C
  //[...]
}

The class CInterruptVectorTable implements an abstraction of the interrupt vectors, so you can bind different functions to the interrupt vectors during runtime.

The interface of that class looks like this:

class CInterruptVectorTable  {
public :
    typedef void (*IsrCallbackfunction_t)(void);                      

    enum InterruptId_t {
        INTERRUPT_ID_NMI,
        INTERRUPT_ID_HARDFAULT,
        //[...]
    };

    typedef struct InterruptVectorTable_t {
        IsrCallbackfunction_t IsrNMI;
        IsrCallbackfunction_t IsrHardFault;
        //[...]
    } InterruptVectorTable_t;

    typedef InterruptVectorTable_t* PinterruptVectorTable_t;


public :
    CInterruptVectorTable(void);
    void SetIsrCallbackfunction(const InterruptId_t& interruptID, const IsrCallbackfunction_t& isrCallbackFunction);

private :

    static void IsrStandard(void);

public :
    static void IsrNMI(void);
    static void IsrHardFault(void);
    //[...]

private :

    volatile InterruptVectorTable_t virtualVectorTable;
    static volatile CInterruptVectorTable* pThis;
};

You need to make the functions which are stored in the vector table static because the controller cannot provide a this-pointer as the vector table is not an object. So to get around that problem we have the static pThis-pointer inside the CInterruptVectorTable. Upon entering one of the static interrupt functions, it can access the pThis-pointer to gain access to members of the one object of CInterruptVectorTable.

---

Now in the program, you can use the SetIsrCallbackfunction to provide a function pointer to a static function which is to be called when an interrupt happens. The pointers are stored in the InterruptVectorTable_t virtualVectorTable.

And the implementation of an interrupt function looks like this:

void CInterruptVectorTable::IsrNMI(void) {
    pThis->virtualVectorTable.IsrNMI(); 
}

So that will call a static method of another class (which can be private), which then can contain another static this-pointer to gain access to member-variables of that object (only one).

I guess you could build and interface like IInterruptHandler and store pointers to objects, so you don't need the static this-pointer in all those classes. (maybe we try that in the next iteration of our architecture)

The other approach works fine for us, as the only objects allowed to implement an interrupt handler are those inside the hardware abstraction layer, and we usually only have one object for each hardware block, so it's fine working with static this-pointers. And the hardware abstraction layer provides yet another abstraction to interrupts, called ICallback which is then implemented in the device layer above the hardware.

---

Do you access global data? Sure you do, but you can make most of the needed global data private like the this-pointers and the interrupt functions.

It's not bulletproof, and it adds overhead. You'll struggle to implement an IO-Link stack using this approach. But if you're not extremely tight with timings, this works quite well to get a flexible abstraction of interrupts and communication in modules without using global variables which are accessible from everywhere.

Answer 6

An interrupt (i.e., the vector that points to your handler) is a global resource. So even if you use some variable on the stack or on the heap:

volatile bool *flag;  // must be initialized before the interrupt is enabled

ISR(...) {
    *flag = true;
}

or object-oriented code with a 'virtual' function:

HandlerObject *obj;

ISR(...) {
    obj->handler_function(obj);
}

… the first step must involve an actual global (or at least static) variable to reach that other data.

All these mechanisms add an indirection, so this is usually not done if you want to squeeze the last cycle out of the interrupt handler.