PRODUCT HOW-TO: State machine design is as easy as telling the time - Embedded.com

PRODUCT HOW-TO: State machine design is as easy as telling the time

TI's innovative eZ430 Chronos watch evaluation kit is based on a traditional sports watch design incorporating pulse monitoring, 3-axis accelerometer and pressure sensor all enclosed in an attractive housing.

With its wireless functionality, not only can the watch (Figure 1 below ) be used as a comprehensive sports watch, but it can also act as, for example, a wireless mouse, or wireless control of slideshow presentations.

Figure 1. Texas Instruments eZ430 Chronos watch evaluation kit

If you look at a typical sports watch at an abstract level it is a very good example of an event-driven system, which at a given time operates in one of several distinct modes or sub-modes.

We can, for example, quickly list a number of abstract events that can be interesting to an application built on this platform:

Button presses: the watch has 5 buttons. The original firmware reacts to all of these and also assigns meaning to a long (2 seconds) press on two of these buttons. It can also detect and generate repeating, i.e. continuous button pressing that generates a series of button events.

Timer events: A number of timers can be running and generate periodic events. A stopwatch, for example, probably needs accurate timer events at a rather high speed to keep the display updated.

The heart rate is polled periodically as well, at least on the application level— exactly how the communication with the chest strap works is buried in a set of proprietary libraries.

The expiry of user-defined alarms or the crossing of user-defined thresholds for heart rate etc. can be viewed as abstract events that should have an impact on the application behavior.

The watch has a number of different modes, or states, where the events mentioned above can take on a different meaning. For example:

1) Stop watch mode
2) Set time and date mode
3) Activated radio mode for heart rate monitoring
4) Wake-up alarm mode
5) Different display modes to chose what to view on the display
6) Exercise energy estimation

An application like this, for a relatively resource-constrained MCU, is often based on the “fat interrupt routine” idiom, where most of the application logic is spread out over a number of interrupt functions.

For example, the main timer interrupt function for the eZ430-Chronos original firmware is close to 180 lines, including single-line comments and blank lines; the function drives quite a lot of the application functionality by way of function calls and manipulation of global data.

This way of working has a lot of advantages. It is, for example, very easy in this particular case to control the different low-power modes of the watch's MSP430 MCU, because the only thing the main loop has to take care of is to do some low-priority processing and then go back to the appropriate low-power mode.

However, the potential drawback is that the application logic is spread out over a number of different modules and it can thus be difficult to trace how different functionality interacts during a debug session or when new functionality is to be added.

A state of mind
An alternative way of breaking down this type of application is to organize it around a main loop where most of the high-level logic is taken care of and to simplify the interrupt routines as far as possible to only detect and report events to the application. In a state/event-oriented application, a state machine approach can then be utilized to design and implement the logic.

(State machines are often used to solve certain kinds of control-oriented problems where the control flow can be pictured as moving through a set of distinct states. There is a number of different definitions and practical descriptions of what a state machine is. At a theoretical level a state machine is a kind of automata that responds to some kind of stimuli by changing state. )

The advantage is that it is possible to achieve a clean separation between input device drivers, application logic, and output device drivers. The code for input detection and output handling could then easily be reused in different projects on the same hardware without the need to clean the code to remove application-specific knowledge.

The drawback is that the book-keeping needed for a centralized state machine can also become quite unwieldy as application complexity grows, at least if it is to be fully implemented in hand-written code with no high-level tools support.

However, help can be found by adopting a tool assisted state machine approach to your application design. For example, tools such as visualSTATE from IAR Systems, can help you develop an event-driven state-based application and, can bring a number of benefits across the development process, including:

Increased productivity. There is of course a learning curve and you need to learn some new habits, but in the end productivity will go up as you spend less time on the book-keeping in your code and focus on the functionality. For example, visualSTATE also generates the code for the state machine, ensuring you make immediate gains by using this approach.

Increased quality. The use of state machines are regarded as a semi-formal method and by treating a state/event-oriented problem as a state machine problem already at the design stage you can reap the benefits of working in the more formalized setting presented by well-defined state machine semantics.

You can start simulating the behavior of your design immediately to make sure that it behaves as intended. You can also utilize the formal verification to make sure that there are no dead-locks in the design or even states that cannot be reached, ever, etc.?

A clean separation between the input/output part of your application (in essence the board support code) and the application logic. This simplifies application architecture and promotes reuse across different hardware platforms.

As an example we can take a look at a small model designed for the ez430-Chronos that takes care of button debouncing and deciding if a button press is a short or long press (Figure 2 below .

Figure 2. Dealing with button debouncing on the Chronos

(To view an expanded image , Click here ).

In this example the depicted state machine sends signals to the application part of the state machine to indicate what kind of button press it has just decoded.

The state NoButton is the start state for this state machine, as indicated by the small circle (the initial state) and accompanying transition to the state.

In a real-world application the strategy of performing the debouncing logic inside the state machine is maybe not the best, or even the obvious choice, but it can nevertheless serve as an illustration to the power of hierarchical state machines.

In the original application code for the watch, this functionality is spread out over a number of modules and the main logic for the decoding and debouncing is a complex switch statement spread out over some 200 lines of code. Granted, it also contains high-level application logic, but that only serves to underline the point about complexity.

The debouncing state machine can react to three events; eComplexButton , eSimpleButton and eNobutton . The interrupt routine that reacts to button events now simply determines if the interrupt is from one of the buttons that does not have a meaning assigned to a long press.

In that case an eSimpleButton event is generated. An eComplexButton event is generated for the two buttons that have different meaning for short and long presses. The state machine can in turn use a helper function aPollButton() to instantaneously determine if a certain button is still active.

This function can in addition to the other button events generate the eNoButton event to indicate that the button that was recently pressed is no longer active.

The state machine, like the original debouncing code, also utilizes a set of timers to control debouncing and determine the length of button presses. When the state machine has detected one of the various button presses, it reports it to the rest of the state machine (not shown here) by sending a signal ” the notation can for example be seen on the transitions from state MaybeLongPress to NoButton (^sM1long ).

The semantics of signals is that the signal is processed immediately after the state machine has processed the event that led to the generation of the signal.

Anders Holmberg is software tools product manager at IAR Systems.

(Editor's Note: To learn more about the eZ430 kit , register for the Embedded Systems Conference in Silicon Valley. There, Texas Instruments will be offering hands-on experience in two classes: a teardown of TI's eZ430 Chronos Wireless Watch Development Tools and a Chronos Workshop. In each class, the first 125 attendees will receive one of the integrated, wearable wireless development systems for the CC430 microcontroller in a sports watch format. )

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.