White Papers
RTOS 101
RTOS 101 explains fundamental RTOS concepts, such as tasks, priority-based scheduling, queues, semaphores and mutexes, and provides examples of how Tracealyzer can be used to understand such issues.
Stop Guessing
Stop Guessing – Trace Visualization for RTOS Firmware Debugging explains key motivations of using an RTOS, current trends in this area, and common pitfalls in RTOS-based development (including an example from NASA).
Real-Time demands of the IoT
Real-Time Demands of the IoT discusses some of the challenges with running software on battery-powered MCUs, and suggests ways that RTOS-based software can help minimise power consumption.
How to visualize response times in FreeRTOS
How to visualize response times in FreeRTOS describes a customer case where Tracealyzer was used to measure and greatly improve response time for network I/O requests.
Tracealyzer Hands On
Tracealyzer – more than a debugging tool
In our new blog series Hands On, which launches today, we will examine many ways that developers can Tracealyzer besides debugging.
Analyzing communication and data flow in an unknown software stack
One of the biggest problems in embedded development today is understanding what a software stack or demo that you didn’t write is doing. In this post, we’ll examine how we can find this out using the Tracealyzer communication flow diagram.
Verifying Task Timing and Scheduling
Quite a few embedded software developers don’t know whether their applications meet their timing requirements. In today's Tracealyzer Hands On post, we will explore how to use Tracealyzer to verify task timing and scheduling.
RTOS Debugging Blog Series
#1: Dealing with timing issues
There is a learning curve when you begin using a real-time operating system in your development. You will work at a higher abstraction level, using parallel tasks that interact with each other, and you will deal with timing issues.
#2: CPU starvation
In embedded systems using multitasking, you may run into a situation where some of your tasks run slowly or not at all. This is called task starvation and it can happen for a number of reasons.
#3: Chasing the jitter bug
When you have a task in your system that is supposed to execute at regular intervals, say every 5 milliseconds, then you have a system that is sensitive to random delays – also known as “jitter”.
#4: Priority inversion
In embedded systems using multitasking, you may run into a situation where some of your tasks run slowly or not at all. This is called task starvation and it can happen for a number of reasons.
#5: Deadlock
A clear indication that you may have a deadlock problem is when multiple tasks suddenly stop executing, although no higher priority tasks are running.