Electronic – Finite State Machine Handling Timers Gracefully

cmicrocontrollermicroprocessor

I've been working with mostly 8 bit MCUs, where most RTOSes are too much overhead.

Most of the applications I've worked one have just been a periodic interrupt with if/else chains for all the processing logic, and then the MCU goes back to sleep.

This has worked well for a lot of things and has a really minimal overhead. But for one system, I'm getting to the point where there are so many control flags that I'm ready to call my own system "spaghetti". It would be horrifying for someone new to pick up this system and implement some new functionality.

(I have a dual color LED, that must have like 8 different states and timing dependent blinking patterns depending on what state the rest of the system is at. It's a horrifying exercise, for what should be so simple…)

I was looking at maybe doing a finite state machine, and trying to weed out so many control flags.

One conceptual problem I am seeing is the use of timers in a state machine. Currently, I have one hardware timer and then a bunch of variable defined timers counters that increment / deincrement, a control flag variable goes to 0/1, and so we go through the if/else chain.

In my planning stage for a more strict state machine, would you just use more hardware timers and trigger the external interrupts as events to go back to the state machine?

My gut reaction (whether right or not) is using as many external interrupts as possible for the state machine is you 1)introduce all kinds of potential interrupt priority issues that bring their own set of problems, where currently the timing is very deterministic but the control logic is simply confusing and 2) you are using more current running a bunch of timers vs. just handling the timer logic as variables.

I see how you could still increment/deincrement variable timers across your state machine, but isn't that anti-ethical to the state machine pattern?

I'm pretty comfortable with the function pointers vs. switch statement debate on how you code the state machine, or if you want to use a transition table, etc.

I'm specifically wondering how folks have handled the timer management aspect of their state machines in a graceful way.

Best Answer

A common way to do this would be to set a maximum execution time for each state and then benchmark each of them (with 100% code coverage) and ensure that they never exceed the maximum execution time. With some luck you can even use the on-chip watchdog to ensure this, if it can run with low enough timeouts.

Now what you are probably looking for is not one, but several state machines. That is, you can have an universal state machine such as

STATE_MACHINE[state++](); 
if(state == STATES_N) 
{ /* reset state machine */ 
}

which does nothing but to cycle through the various software modules, giving them each a "time slice". Either you can run through all various hardware drivers in one go and go back to sleep, or you can chose to only run a single one of them. This does of course depend on the real-time requirements.

One such state could be led_execute(), which would be the LED routine keeping track of what is happening on the LEDs right now. This routine is residing inside the LED driver and can in turn keep track of every LED state, so that it looks something like:

typedef enum
{
  LED_OFF,
  LED_RED_LIT, // whatever names make sense
  LED_RED_BLUE_LIT,
  ...
  LED_DONE,
  LED_N
} led_state_t;
...    
static led_state_t led_state = LED_OFF;
...

void led_execute (void)
{
  led_state = LED_STATE_MACHINE[led_state]();
}

If the states depend on external input, then maybe skip the return state part and have the state update through setters/getters only.

This should completely eliminate the need of flags - in particular non-related flags located in the same scope, which can be a nightmare. The most important part here is not to mix up the LED complexity with some other hardware's complexity.

Lets say that you are simultaneously de-bouncing a button. Say that you need to finish de-bouncing before the LEDs can lit - that doesn't mean that the buttons have to know about LEDs or that LEDs have to know about buttons. The caller code should keep track of these things. Meaning you might need some abstraction layer between the outer-most state machine and the drivers themselves. If the LED driver only gets one input "do this!" from the caller, then it couldn't care less about the reasons behind it.

Related Solutions

Electronic – Measuring 0 – 1MHz ( 0.25Hz resolution) Squarewave using an MCU

If possible I'd suggest selecting a microcontroller that supports a counter operation using the timer inputs; rather than manually incrementing a counter inside an ISR (which at high frequencies quickly ends up saturating the microcontroller activity) you allow the hardware to handle the counting. At this point your code simply becomes a matter of waiting for your periodic interrupt then calculating the frequency.

To extend the range and make the frequency counter more generalised (removing the need for multiple ranges at the expense of a little more work for the MCU) you could use the following technique.

Select a periodic interrupt rate that allows for measurement accuracy at the highest input frequency; this should take into account your counter size (you need to select the timer period such that the timer counter will not overflow at the maximum input frequency). For this example I'll assume that the input counter value can be read from the variable "timer_input_ctr".

Include a variable for counting periodic interrupts (should be initialised to 0 at startup); for this example I'll refer to this variable as "isr_count". The interrupt period is contained in the constant "isr_period".

Your periodic interrupt should be implemented as (C pseudo-code):

void timer_isr()
{
  isr_count++;
  if (timer_input_ctr > 0)
  {
    frequency = timer_input_ctr / (isr_count * isr_period).
    timer_input_ctr = 0;
    isr_count = 0;
  }
}

Obviously this rough example relies on some floating point math that may not be compatible for low-end microcontrollers, there are techniques to overcome this but they are outside of the scope of this answer.

Electronic – Interrupt handling in microcontrollers and FSM example

The first tactic is to architect the overall firmware so that it's OK for interrupts to occur at any time. Having to turn off interrupts so that the foreground code can execute a atomic sequence should be done sparingly. There is often a architectural way around it.

However, the machine is there to serve you, not the other way around. General rules of thumb are only to keep bad programmers from writing really bad code. It is far better to understand exactly how the machine works and then architect a good way to harness those capabilities to perform the desired task.

Keep in mind that unless you really are tight on cycles or memory locations (can certainly happen), that otherwise you want to optimize for clarity and maintainability of the code. For example, if you have a 16 bit machine that updates a 32 bit counter in a clock tick interrupt, you need to make sure that when the foreground code reads the counter that the two halves of it are consistent. One way is to shut off interrupts, read the two words, and then turn interrupts back on. If interrupt latency isn't critical, then that's perfectly acceptable.

In the case where you must have low interrupt latentcy, you can, for example, read the high word, read the low word, read the high word again and repeat if it changed. This slows down the foreground code a little, but adds no interrupt latency at all. There are various little tricks. Another might be to set a flag in the interrupt routine that indicates the counter must be incremented, then do that in the main event loop in the foreground code. That works fine if the counter interrupt rate is slow enough so that the event loop will do the increment before the flag is set again.

Or, instead of a flag use a one-word counter. The foreground code keeps a separate variable that contains the last counter it has updated the system to. It does a unsigned subtract of the live counter minus the saved value to determine how many ticks at a time it has to handle. This allows the foreground code to miss up to 2^N-1 events at a time, where N is the number of bits in a native word the ALU can handle atomically.

Each method has its own set of advantages and disadvantages. There is no single right answer. Again, understand how the machine works, then you won't need rules of thumb.

Best Answer

Related Solutions

Electronic – Measuring 0 – 1MHz ( 0.25Hz resolution) Squarewave using an MCU

Electronic – Interrupt handling in microcontrollers and FSM example

Related Topic