Super-Simple Tasker - Hardware RTOS for ARM Cortex-M

Super-Simple Tasker (SST) is a preemptive, priority-based RTOS kernel fully compatible with Rate Monotonic Analysis/Scheduling (RMA/RMS). It was initially published in 2006.

This session will present a unique hardware implementation of a modern version of SST for ARM Cortex-M (M0, M0+, M3, M4, M7, etc.).

The session will begin with introducing preemptive but non-blocking multitasking with so-called basic tasks (as defined in the OSEK/VDX/AUTOSAR operating system). Such tasks are ideal for executing event-driven state machines (a.k.a. active objects), which are also non-blocking and handle events in a run-to-completion fashion.

Next, you will see how these basic tasks can be mapped to ARM Cortex-M interrupts and how to program the NVIC interrupt controller to manage both interrupts and basic tasks.

The bulk of the session will demonstrate various preemption scenarios, including inter-task communication and the compatibility of SST with RMA/RMS. The demos will utilize a logic analyzer and will run on a low-end ARM Cortex-M0 and on a high-end ARM Cortex-M7 with FPU.

If you are interested in real-time performance, you should see SST in action. SST is available on GitHub under the permissive MIT open-source license. SST is likely the most efficient and performant RMS-compatible RTOS kernel for ARM Cortex-M.

Go to Session

Live Q&A - Super-Simple Tasker - Hardware RTOS for ARM Cortex-M

Live Q&A with Miro Samek for the talk titled Super-Simple Tasker - Hardware RTOS for ARM Cortex-M

Go to Session

Testing of Event-Driven Embedded Software with Python

Testing event-driven software typically involves injecting events to the system and verifying that the software reacts by executing the expected sequence of actions. These actions might be quite complex. For example, a single transition in a hierarchical state machine might trigger several exit actions from the source state configuration, followed by entry actions and nested initial transitions into the target state configuration. The actions themselves might involve interactions with multiple hardware components, such as toggling GPIOs, sending data through various interfaces, etc.

In traditional unit testing frameworks, the verification of such potentially complex interactions typically requires applying mock objects as the test doubles for the various hardware components. But even though generating mocks can be automated, it's difficult to verify sequences of expected interactions among multiple mocks (multiple hardware components). Also, working with mocks reverses the natural sequencing, because the expectations must be specified before the actual call to the CUT (code under test).

This session will show a more intuitive approach, conceptually similar to "debugging with printf", where you instrument the code with printf statements to output the software trace information. You then run the CUT with a controlled set of inputs, and examine the produced trace to determine whether the CUT operates correctly. The main differences from using actual printfs will be: (1) that the much more efficient software tracing mechanism will be used instead and (2) that both generating the inputs and the checking of the trace output will be automated.

This approach has many interesting implications:

• It separates the execution of the CUT from checking of the "test assertions". The embedded target is concerned only with running a test fixture that calls the CUT and produces the trace, but it does not check the test expectations.
• Checking the generated trace output against the expectations is performed separately on the host computer and can be done in a different programming language (e.g., Python) than the CUT (C or C++).
• Virtually all test doubles can be implemented as simple "spy" test doubles without the need to applying mocks or other complex test doubles. Verifying trace output from multiple such "spy" test doubles is trivial.
• The testing process follows the natural sequencing where the generating of inputs to the CUT is naturally followed by the expectations of the performed actions. 

This session will utilize hands-on demonstrations of the QUTest (pronounced "cutest") unit testing harness running on both the host computer and STM32-NUCLEO board. Specifically, you will see a comparison between the traditional approach with a mock test double and the QUTest approach with software tracing and a "spy" test double.

Go to Session

Live Q&A - Testing of Event-Driven Embedded Software with Python

Live Q&A with Miro Samek for the talk titled Testing of Event-Driven Embedded Software with Python

Go to Session

Modern Embedded Programming with Hierarchical State Machines and Active Objects

Perhaps you've heard about hierarchical state machines (UML statecharts), modeling tools and automatic code generation, but have never tried them or seen them used in practice.

This presentation will show you, step-by-step, the process of designing and implementing a fun "Fly 'n' Shoot" game to run on an embedded ARM Cortex-M board as well as on your PC.

Specifically, you will see how to partition a problem into loosely coupled, event-driven components called active objects and then how to design interactions among them using sequence diagrams.

Next, you will see how to elaborate the internal behavior of identified active objects with modern hierarchical state machines.

And finally, you will see how the state machines are implemented in C and how this code can be generated automatically.

Go to Session

Live Q&A - Modern Embedded Programming with Hierarchical State Machines and Active Objects

Live Q&A with Miro Samek for the talk titled Modern Embedded Programming with Hierarchical State Machines and Active Objects

Go to Session

Modern Embedded Software Goes Beyond the RTOS (2020)

Some of the most difficult problems with real-time and embedded programing are related to concurrent code execution as well as code organization, which all too often degenerates into "spaghetti code". These problems are usually intermittent, subtle, hard-to-reproduce, hard-to-isolate, hard-to-debug, and hard-to-remove. They pose the highest risk to the project schedule.

This session presents a set of best practices of concurrent programming, which are collectively known as the active object (or actor) design pattern. In this pattern, applications are built from event-driven, non-blocking, asynchronous, encapsulated threads (active objects), with the internal behavior of each active object controlled by a state machine.

While active objects can be implemented manually on top of a traditional RTOS, a better way is to use an active object framework. You will see how this leads to inversion of control, enables architectural reuse, and allows the framework to automatically enforce the best practices.

In the second part, the session will introduce modern hierarchical state machines as the powerful "spaghetti reducers". You will see how state machines complement active objects and enable graphical modeling and automatic code generation.

The session will utilize hands-on demonstrations using EFM32 Pearl-Gecko ARM Cortex-M4 board, the QP/C real-time embedded framework and the QM modeling and code-generation tool.

Go to Session