Feature: Software and tools
As embedded applications move toward greater connectivity, tighter timing requirements and multi-core architectures, the need for better visibility into RTOS
behaviour at runtime has become harder to ignore
unsuitable for analysing scheduling behaviour or trace conditions. Logging statements can help, but they quickly become intrusive and generate large volumes of unstructured data. Even when a fault can be reproduced, the developer is oſt en leſt
guessing: Was a deadline missed because the task ran too long? Was it pre-empted unexpectedly? Was it blocked by another task holding a resource? Without a clear view of what the scheduler and RTOS primitives
are doing at runtime, diagnosing these issues becomes an exercise in speculation.
RTOS trace and observability RTOS trace tools address this visibility gap by recording key kernel events during execution, including task switches, interrupt entry and exit, synchronisation operations and precise timing information. T is data is then visualised on the host as a time-ordered trace of system activity. Instead of inferring behaviour from symptoms, developers can
directly observe how tasks interact over time. It becomes possible to see which task was running at any given moment, why it was pre-empted or blocked, and how long each operation took. Crucially, this approach supports system-level analysis. Trace
visualisation reveals cause- and eff ect-relationships and makes it easier to reason about emergent behaviour – the kind that arises only when many independently correct components interact under real workloads.
Everyday development benefi ts Trace-based analysis is oſt en associated with advanced debugging, but its benefi ts extend well beyond chasing rare bugs. One immediate advantage is timing verifi cation. Periodic tasks can
be checked against their deadlines over long execution runs, revealing jitter and worst-case response times that would be diffi cult to measure otherwise. When a deadline is missed, the trace shows not only that it happened, but why.
Figure 1: In principle, a high-priority task (H) should never be blocked by lower-priority tasks. In practice, certain design decisions can result in this happening anyway, a condition known as “priority inversion”
Figure 2: RTOS trace timeline showing task execution, pre- emptions and interrupts over time. This view makes scheduler behaviour and task interactions directly observable
www.electronicsworld.co.uk March 2026 39
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48
