search.noResults

search.searching

saml.title
dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
Feature: Software and tools


Seeing inside the scheduler: RTOS trace and observability matter!


By Andreas Lifvendahl, CEO, Percepio


M 38 March 2026 www.electronicsworld.co.uk


odern embedded systems increasingly rely on real-time operating systems (RTOS) to manage growing soſtware complexity. Multithreading, pre-emptive scheduling and inter-task communication enable efficient use of hardware resources, but they also


introduce subtle timing and concurrency problems that are difficult to reason about from source code alone. 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.


The hidden complexity of RTOS-based systems RTOS applications rarely fail because a single task behaves incorrectly in isolation. Instead, problems emerge from interactions: a task blocked on a mutex, an unexpected priority inversion, a higher-priority interrupt arriving at an inconvenient moment, or timing variations that only occur under specific system load. Tese interactions are oſten invisible at the code level. While the


source may show which tasks use which synchronisation objects, it does not show when these interactions occur, how long tasks are blocked, or how scheduling decisions play out over time. On multi-core systems, additional sources of non-determinism such as cache effects and shared buses further complicate the picture. As a result, systems can appear stable during testing, only to exhibit elusive failures in the field that are nearly impossible to reproduce.


Traditional debugging falls short Conventional embedded debugging tools were not designed to answer system-level timing questions. Breakpoints and single stepping fundamentally disturb the timing of a real-time system, making them


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