Workshop

RTOS Design and Debugging Techniques Hands-on

Watch Now

01:55:37

EOC 2021

Workshop

RTOS Design and Debugging Techniques Hands-on

Jacob Beningo

01:55:37 EOC 2021

Jacob Beningo

01:55:37

Real-time operating systems (RTOS) have found their way into nearly every embedded system. The problem though is that an RTOS can often complicate implementation, increase module coupling and make debugging a nightmare.

In this workshop, Jacob Beningo will walk attendees through RTOS implementation and debugging techniques that will help developers accelerate their design cycle and implement more robust and flexible design techniques. Attendees will learn hands-on about topics such as:

How to initialize tasks
How to properly set task stack size and monitor for stack overflows
Decouple application code from the RTOS
Properly protect shared resources
Minimize response time for system events
Perform application tracing and performance analysis

Additional topics and details about specifics boards and RTOS will be provided closer to the conference.

1 / 6

Please log in or create an account to test your knowledge and see the answers.

Why does Jacob Beningo recommend using a centralized task configuration table when creating RTOS tasks?

A It automatically assigns optimal priorities and stack sizes using a built-in optimizer.

B It centralizes all task creation parameters so tasks are easy to add, remove, and maintain instead of being scattered throughout the code.

C It forces all tasks to be created dynamically at runtime which improves flexibility.

D It eliminates the need to write the actual task function bodies elsewhere in the code.

E It obviates the need for any configuration headers or build-time constants.

What is Jacob Beningo's main reason for recommending the CMSIS-RTOS2 API when possible?

A Because CMSIS-RTOS2 provides better real-time performance than every native RTOS API.

B Because CMSIS-RTOS2 is required to use FreeRTOS on STM32 boards.

C Because CMSIS-RTOS2 abstracts the RTOS API so you can more easily swap RTOS implementations later.

D Because CMSIS-RTOS2 eliminates the need to configure task stack sizes and priorities.

E Because CMSIS-RTOS2 only supports static allocation and prevents dynamic memory usage.

Why does Jacob warn against using malloc/dynamic allocation for RTOS task creation in production systems?

A Because malloc is always much slower than any static allocation and makes code run orders of magnitude slower.

B Because dynamic allocation is non-deterministic and can cause heap fragmentation, making it unsuitable for real-time production systems.

C Because dynamic allocation is incompatible with FreeRTOS and will not work at all.

D Because static allocation requires no configuration and therefore is always safer.

E Because dynamic allocation prevents the use of any debugger hooks or logging.

Which technique does Jacob suggest to make it obvious that a shared data structure is protected and must be accessed with mutual exclusion?

A Place a separate global mutex variable in a different module and document its use in README files.

B Put a mutex handle inside the shared data structure itself (e.g., at the top) so protection is obvious when accessing it.

C Rely on the RTOS scheduler to automatically serialize all accesses to that structure without any explicit locking.

D Use a binary semaphore instead of any mutex, since semaphores and mutexes are identical in meaning.

E Make the shared structure a public global and trust developers to remember to lock before access.

What is the primary practical benefit of using a tracing tool like Tracealyzer in RTOS-based embedded development, according to Jacob?

A It replaces the need for any unit or integration testing because traces prove correctness automatically.

B It allows detailed, streaming traces that visualize task execution, stack and heap usage, and help identify worst‑case response times and race conditions.

C It guarantees zero runtime overhead and therefore can be left enabled in production without consideration.

D It requires no configuration and will automatically fix stack overflows when they occur.

E It prevents any need to review map files or symbol locations since it hides memory layout details.

What guidance does Jacob give about assigning the same priority to multiple tasks in FreeRTOS?

A Never give two tasks the same priority; it will cause undefined behavior in FreeRTOS.

B It's fine to give tasks the same priority if they have the same period, but you must ensure schedulability and acceptable response times.

C Always give lower-priority tasks priority zero because zero is the highest priority in FreeRTOS.

D Assigning the same priority makes tasks execute simultaneously on separate cores automatically.

E If two tasks share priority, FreeRTOS will round-robin them with guaranteed equal CPU time regardless of deadlines.

Formatting help

italics	surround text with asterisks
bold	surround text with two asterisks
hyperlink	[hyperlink](https://example.com) or just a bare URL
inline code	surround text with single `backticks`
code block (multi-line)	wrap on its own lines with three backticks: ``` your code here ```
~~strikethrough~~	surround text with ~~two tilde characters~~
quote	prefix with >

Upvotes Newest Oldest

Jacob_BeningoSpeaker

Score: 0 | 5 years ago | no reply

Well, I accidentally deleted the workshop files from Dropbox. So the link in the workshop recording will no longer work. However, I've reposted the materials to the following link: https://www.dropbox.com/s/4tn40bbopu8a4mf/EOC21-RTOS-Workshop_Labs.zip?dl=0

SimonSmith

Score: 1 | 5 years ago | 1 reply

Great workshop! I particularly liked your suggestion to initialize tasks from a table (mine are all over the place...) and the intro to Tracealyzer. It looks amazing - I just wish it was more affordable for the node-locked license.

Jacob_BeningoSpeaker

Score: 0 | 5 years ago | no reply

Thanks! I've found it to help organize tasks.

dcomer

Score: 1 | 5 years ago | 1 reply

"Just a consultant?". Seems to me that you have provided a valuable service to the embedded community with your talks, books, involvement in this conference, etc. Thanks Jason.

Jacob_BeningoSpeaker

Score: 0 | 5 years ago | no reply

Thanks!

Jeremy

Score: 0 | 5 years ago | 1 reply

Hi Jacob, this one got lost in the queue in the session. Can you comment on the proper STM32 configuration for interrupts related to scheduling? Specifically the priority of SysTick and PendSV as well as as the HAL's tick increment method. I've heard differing opinions... not sure I've seen a solid answer yet.

Jacob_BeningoSpeaker

Score: 0 | 5 years ago | no reply

Thanks for posting it and sorry for the delay!

The short answer is, it depends on your application.

General rule of thumb that I use is to set the SysTick to a high priority since it is the primary time manager for the RTOS. PendSV is typically used by the RTOS to perform a context switch. It is generally the lowest priority interrupt.

For the HAL time tick, I typically choose a priority less than SysTick, greater than PenSV. I look carefully at the other interrupts in the system and the response time requirements and then set it based on the system needs.

I hope that helps. Relatively generic answer but let me know if you have any follow-up questions / comments.

aldo_coronado

Score: 0 | 5 years ago | 1 reply

What is the best way to implement an application which has an inherent need for state control (i.e. state machine, controlled by driver inputs) in and RTOS design paradigm?
I have implemented an Event Handler which distributes messages from a Queue to the running context, but so far hasn't been deterministic.

Jacob_BeningoSpeaker

Score: 0 | 5 years ago | no reply

Sorry for the delay! The conference kept me busy and I overlooked my messages.

Typically, I will design my state machine and then have a StateMachine_Run function that is called from the task. You can process your driver inputs and then feed it to the state machine. Like you mentioned, you lose some determinism and also may inject jitter. Jean Labrosse made a great comment that if your response times are ok, you can process your state machine on the previous dataset, then process the new driver inputs in order to minimize jitter.

aldo_coronado

Score: 0 | 5 years ago | 1 reply

How many is too many tasks? How can I decide whether or not to implement a task in, let's say, a peripheral driver?

Jacob_BeningoSpeaker

Score: 0 | 5 years ago | no reply

My rule of thumb is to not have more than a 12 tasks that are grouped together. So for example, I may have 6 tasks that handle TCP/IP and web communications, 8 tasks that manage interactions with peripherals, 10 tasks that manage core application features, 4 tasks that manage optional application features, etc.

Technically you can have as many tasks as you want, but I like to build them out in logical groups of no more than 12, just so it?s easy to manage.

As far as peripheral drivers go, I would keep the RTOS out of the drivers. We want to keep a domain separation between between driver code, middleware and the application. An RTOS task can call a driver function, but try to keep them RTOS independent.

I hope that helps!

Partners & Sponsors

Percepio

Zeroplus

Edge Impulse

Crank Software

STMicroelectronics

Microchip

Joulescope

The Qt Company

NXP

TUXERA

XMOS

Lager

Qoitech

Become a Sponsor