Breaking a switch case from an ISR

Question

I'm struggling with something. My CPU sits in a switch case state machine like this:

switch(expression) {

   case constant-expression_1  :
      statement(s);
      break; /* optional */

   case constant-expression_2  :
      statement(s);
      break; /* optional */

   /* you can have any number of case statements */
   default : /* Optional */
   statement(s);
}

I have an interrupt that occurs on a button press. In the interrupt, I change the switch expression to the case I want to go next, like this:

void ISR(void){
   expression = constant-expression_2;
}

After the interrupt has been handled, I want the CPU to return directly to the case being switched to, and to not continue where it left off.

Does anyone have any good ideas on how to implement this, if it's possible? I'd prefer to not have to wait for the code to finish what was happening in the previous case before going to the one being switched to.

Thanks in advance!

Answer 1

It is certainly possible, although I do not think there is any clean way of doing it...

Here is an idea that may work: right before the switch statement, you save the current context with the setjmp() function. Then, in the ISR, you restore that context with longjmp(). This is kind of like a goto statement that works across functions:

#include <setjmp.h>

jmp_buf env;

ISR(FOO_vect) {
    expression = ...;
    longjmp(env, 1);  // go to start of loop
}

void loop() {
    setjmp(env);  // landing point from ISR exit
    switch (expression) {
        ...
    }
}

Notice that the normal exit sequence of an ISR (the reti instruction) re-enables the interrupts. Since we are skipping this exit sequence, we have to enable them explicitly upon return from setjmp() interrupts are re-enabled not by the reti instruction but by longjmp() restoring the CPU's status register.

Warning: This is a (very dirty) hack that I have not tested. If I were to use this trick, I would first:

1. Carefully examine the generated assembly to convince myself it does the right thing.
2. Test, test, test...

In case of problems, debugging this may be harder than just testing the expression inside every slow function you have.

Addendum: Although I am saying that there is no clean way of doing what you intend, there certainly is a clean way of achieving the same end result: just make sure your switch statements return fast. My preferred way of doing this would be to make sure no function ever waits. For example:

• A routine reading sensors would not wait for them to respond. Instead, it would return immediately if no reading is available. If a reading is available, it would retrieve it, send a query to the next sensor in the list, then return.
• A communication routine would not wait for complete messages. Instead, it would return immediately if no byte is available. If a byte is available, it would buffer it and return. Unless it's the last byte of a complete message, in which case it would process the message.

Obviously this could require a heavy refactoring of your code, probably using finite state machines (see for example the tutorials here and here). It may be easier to just test whether the expression has changed inside every busy-wait loop you have, as recommended by Gerben's and Nick's answers.

Answer 2

Most of the time this isn't a problem, because code normally runs pretty fast. The problem, most of the time, is the use of delays. What I did was use my own delay function that checks if the expression has changed, and if so, immediately returns.

Below is my code. I had to modify it a bit, so it might not work out of the box, but will give you the idea as to how.

volatile byte expression;
volatile boolean expressionChanged = false;

switch(expression) {

   case constant-expression_1  :
      statement(s);
      myDelay(1000);
      statement(s);
      break; /* optional */

   case constant-expression_2  :
      statement(s);
      myDelay(500);
      statement(s);
      break; /* optional */

   /* you can have any number of case statements */
   default : /* Optional */
      statement(s);
}

void myDelay(int ms)
{
    uint32_t start = micros();
    while (ms > 0 && !expressionChanged)
    {
        //yield();not implemented in arduino
        if ( (micros() - start) >= 1000)
        {
            ms--;
            start += 1000;
        }
    }   
}

void ISR(void){
   expression = constant-expression_2;
   expressionChanged = true;
}

Answer 3

First, put your major processing into functions. That looks better anyway. eg.

switch(expression) {

   case constant-expression_1  :
      function1 ();
      break; /* optional */

   case constant-expression_2  :
      function2 ();
      break; /* optional */

   /* you can have any number of case statements */
   default : /* Optional */
      function_default ();
}

Now inside your functions do a return if you notice the expression has changed. This will get you out of any number of nested loops. For your 30 sensors, for example, you can now have a loop.

void function1 ()
  {
  for (int i = 0; i < 30; i++)
    {
    if (expression_changed)
       return;
    // take sensor reading
    }
  }  // end of function1

Also, as Gerben suggested, replace any delay calls with a function that does the delay, however which ends early if the expression changes. It can return a boolean to let you know this happened. eg.

boolean myDelay(int ms)
  {
    uint32_t start = micros();
    while (ms > 0)
    {
        if (expression_changed)
           return true;   // early return
        if ( (micros() - start) >= 1000)
        {
            ms--;
            start += 1000;
        }
    }   
  return false;   // normal return
  }

Now any function that needs delays can use that, like this:

void function2 ()
  {
  do_something ();
  if (myDelay (1000))  
     return;   // bail out
  do_something_else ();
  }  // end of function1

My problem is, one of my cases includes a communication transceiver method, which can take a lot of time to get through

There must be logical spots where you can just test the expression and do a return (preferably cleaning up anything that needs it) when required.