State Machine Model and Blocking Code

Why does MPLAB® Harmony utilize a state-machine based programming model?

The state-machine programming model may seem a bit foreign if you’re not used carving up the tasks that your application performs into byte-sized pieces. However, it very quickly becomes necessary in the polled “super loop” environment with which most embedded developers are very familiar. Once an application requires a significant set of capabilities, the processing required by all of the necessary modules becomes too much to simply do one thing at a time.

The Blocking Code Problem

If an application utilizes a graphics library, a TCP/IP networking stack and a SPI driver, all working within the same main loop, then it is very likely that by the time the graphics library finishes drawing a complete WVGA screen image followed by the TCP/IP stack processing a 3 KB network packet, that the SPI driver sending audio data to a CODEC is going to underflow and either repeat stale data or stop sending data all together.

non_state_machine.jpg

Even if the SPI driver is interrupt-driven, it must still work out of a buffer that is supplied by an application or other module that executes in the polled loop. Just using a bigger buffer is ultimately a losing proposition. In this situation it becomes very difficult, if not impossible, to effectively share the processor execution bandwidth between these different modules. Simply using a faster processor will not usually solve this issue.

The problem is not the processor speed or memory size. It is the one-thing-at-a-time blocking approach used. Such libraries frequently spend a large amount of time blocking in a loop while waiting for something to happen in the real world. The problem is frequently not the processor workload, it’s the time spent waiting your turn.

Non-Blocking State Machines

To solve this problem, a library’s task must be broken down into smaller sub-tasks that can be performed from start-to-finish in an acceptable amount of time. Any time a library must wait a significant period of time for something to happen, it should not block the rest of the system. Instead, it should release the processor and let the rest of the system execute. To do this requires either the capabilities of an operating system, or it requires breaking up the application’s tasks into smaller sub-tasks and using a state machine methodology to step through these sub-tasks as it transitions from one state to another. That is why MPLAB® Harmony libraries are designed using a state-machine based model. This is what allows you to create incredibly complex systems using MPLAB Harmony libraries, either with or without an operating system.

© 2024 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.