Quite a claim, I agree. But I think realistic for some applications at least. In recent times I have developed a number of Picaxe-based systems to automate things in my house, with a life-expectancy in use of at least several years. During this work I have created a simple code structure using Finite-State Machine principles that I have been able to reuse for a number of projects. This has proven helpful for very rapid and reliable development so I thought I would share it. This article explains how it works and how to adapt it for another project. There is little original about it, but the key thing is that it is simple and it works. In essence, a simple program flow is pre-coded, and only the definition of the events and how to respond to them is added for each project.
To be suitable as an FSM an application must logically be expressible as a set of States of manageable size. The system is in one State at a time, and makes a transition from one State to another when events occur. Events are inputs or derived from inputs. Transitions are when the system needs to do something in response to an event. FSMs can be used in many ways, including parsing machine language, applying gaming rules, or in this case real-time embedded control. They are a core computer science concept, though you don't need to know much computer science to use them.
The program structure supports any system that responds to a number of external inputs and activates a variety of outputs, especially where the response to an input may change depending on what has gone before, and where a response time measured in mS is fast enough. It will work just as well on an 08M2 as on a 40X2, but it is hard to fit on the older chips such as the 08 due to code space limits. Most embedded systems that I have come across are suitable.
To illustrate the point, the diagram shows a very simple, almost trivial, FSM with three States – Day, Night, and Light_On. It is a lighting controller that operates lights when it receives a signal from a PIR. Much more complex FSMs are possible, and indeed it is for highly complex systems where the technique really pays off, an extreme case I worked on once being the automation of a software-controlled telephone exchange. For more modest Picaxe examples, see my garage-door and solar panel pump controllers in the finished projects section. With this code structure, the application can be made much more complex as it evolves but with only a little extra code, mainly in the Process_Event routines, as the entire control structure works more or less unchanged for any number of States and Events. Because the program control logic is separate from the application logic (which is in the State and Process_Event definitions), it is easy and safe to change the states and events if you get them wrong initially.
View attachment 9733
In the example, the light can only switch on when in the Night state – in the Day state the PIR input is ignored. The code is attached. This simple example could easily be coded in other ways. However, using this technique it took less than a day to complete the code and install it in the finished hardware, knowing that the code would be reliable and easy to maintain. It is in use now and should be readily maintainable for some years.
Real-time embedded systems
A real-time system has a number of essential components which are all present in the example.
Event detection: the external world has to be examined for relevant inputs. Event_Monitor performs this function. In systems that require interrupts, the 'interrupt' routine is used to set a 'handle' flag that Event_Monitor notes and acts upon. If timers are required they are checked here. Otherwise, it simply polls all the relevant inputs and decides if action is required.
Task allocation: Once an event has been identified as needing a response, the task allocator (here the main program loop) calls a Process_Event subroutine for that event.
Transitions: Each Process_Event routine carries out the necessary work according to the current State, and if a State change is called for it is done here.
Hardware interface: All control of the hardware is done through interface routines, and these are used to control the relay and led in this case.
How to create an FSM-based system using this structure
If you want to try this technique then take a look at the example code and see how simple these things really are. Then these steps should get you started:
View attachment 9734
Conclusion
FSM techniques are very useful in making the task of coding of an embedded system closer to that of configuring a standard program. If you have a suitable application problem, and you want to build a real-time system using Picaxe and get it up and running quickly, then this technique may help get you started.
To be suitable as an FSM an application must logically be expressible as a set of States of manageable size. The system is in one State at a time, and makes a transition from one State to another when events occur. Events are inputs or derived from inputs. Transitions are when the system needs to do something in response to an event. FSMs can be used in many ways, including parsing machine language, applying gaming rules, or in this case real-time embedded control. They are a core computer science concept, though you don't need to know much computer science to use them.
The program structure supports any system that responds to a number of external inputs and activates a variety of outputs, especially where the response to an input may change depending on what has gone before, and where a response time measured in mS is fast enough. It will work just as well on an 08M2 as on a 40X2, but it is hard to fit on the older chips such as the 08 due to code space limits. Most embedded systems that I have come across are suitable.
To illustrate the point, the diagram shows a very simple, almost trivial, FSM with three States – Day, Night, and Light_On. It is a lighting controller that operates lights when it receives a signal from a PIR. Much more complex FSMs are possible, and indeed it is for highly complex systems where the technique really pays off, an extreme case I worked on once being the automation of a software-controlled telephone exchange. For more modest Picaxe examples, see my garage-door and solar panel pump controllers in the finished projects section. With this code structure, the application can be made much more complex as it evolves but with only a little extra code, mainly in the Process_Event routines, as the entire control structure works more or less unchanged for any number of States and Events. Because the program control logic is separate from the application logic (which is in the State and Process_Event definitions), it is easy and safe to change the states and events if you get them wrong initially.
View attachment 9733
In the example, the light can only switch on when in the Night state – in the Day state the PIR input is ignored. The code is attached. This simple example could easily be coded in other ways. However, using this technique it took less than a day to complete the code and install it in the finished hardware, knowing that the code would be reliable and easy to maintain. It is in use now and should be readily maintainable for some years.
Real-time embedded systems
A real-time system has a number of essential components which are all present in the example.
Event detection: the external world has to be examined for relevant inputs. Event_Monitor performs this function. In systems that require interrupts, the 'interrupt' routine is used to set a 'handle' flag that Event_Monitor notes and acts upon. If timers are required they are checked here. Otherwise, it simply polls all the relevant inputs and decides if action is required.
Task allocation: Once an event has been identified as needing a response, the task allocator (here the main program loop) calls a Process_Event subroutine for that event.
Transitions: Each Process_Event routine carries out the necessary work according to the current State, and if a State change is called for it is done here.
Hardware interface: All control of the hardware is done through interface routines, and these are used to control the relay and led in this case.
How to create an FSM-based system using this structure
If you want to try this technique then take a look at the example code and see how simple these things really are. Then these steps should get you started:
- Draw a State/Transition diagram. Spend some time on this as it is the crucial step. Identify all the States and the possible events that can occur, and decide what needs to be done in each case. Qfsm is a great way to document the diagram.
- Create the Event_Monitor routine to detect all the events as they occur. The program will loop in Event_Monitor indefinitely until something happens that needs action. When it does, set the variable B_event to the event type and exit from the loop. Only one event at a time is processed.
- Create the Process_Event routine for each recognised event. If an event is valid in more than one State, use a Select/Case construction to define different responses. Where hardware interaction is needed, create a subprogram to do it.
- Then create the main program loop to allocate the events to the Process_Event subroutines.
View attachment 9734
Conclusion
FSM techniques are very useful in making the task of coding of an embedded system closer to that of configuring a standard program. If you have a suitable application problem, and you want to build a real-time system using Picaxe and get it up and running quickly, then this technique may help get you started.
