#24 RTOS Part-3: Automating the scheduling with round-robin policy

Summary

In this lesson on Real-Time Operating Systems (RTOS), Miro Samek demonstrates how to automate thread scheduling using a round-robin algorithm within the MiROS RTOS. The tutorial focuses on refactoring the existing code to store threads in an array, ensuring scalability and avoiding hard-coded scheduling. The lesson also covers the use of embedded systems-friendly assertions, efficient interrupt handling, and the performance of the system. Testing reveals minimal RTOS overhead, with a context switch time of just 3.5 microseconds. The course emphasizes improvements in thread composability and sets the stage for future optimizations in thread blocking.

Takeaways

• 😀 MiROS RTOS now supports a round-robin scheduler for automating thread scheduling, ensuring efficient multitasking.
• 😀 The scheduling process previously required manual configuration, which is now automated by storing thread pointers in a pre-allocated array (OS_thread[]).
• 😀 The scheduler selects the next thread in a circular order by incrementing the current index and wrapping around when necessary.
• 😀 Threads are composable, meaning that adding new threads to the system doesn’t require changes to existing threads or the RTOS code.
• 😀 Assertions are used to handle situations where the system might overflow the thread array, providing a safe mechanism to prevent runtime errors.
• 😀 Interrupt configuration and enabling should occur only after all threads are initialized to avoid potential issues with premature context switches.
• 😀 The OS_run() function centralizes the transition to the RTOS and manages thread execution, ensuring that interrupts are enabled after all threads have been set up.
• 😀 The PendSV exception handles context switching, allowing threads to switch in a way that respects the interrupt context.
• 😀 The MiROS RTOS achieves efficient thread switching with minimal overhead, as demonstrated by the small context switching times (around 1.5 microseconds or 75 clock cycles).
• 😀 RTOS overhead is minimal, with a context switch taking approximately 3.5 microseconds, representing only 0.00035% of the CPU time at a 50 MHz clock rate.
• 😀 Future improvements could focus on optimizing the BSP_delay() function to use blocking mechanisms, reducing unnecessary CPU cycles during thread delays.

Q & A

What is the main goal of this lesson in the MiROS RTOS course?

The main goal of this lesson is to automate the scheduling of threads in the MiROS RTOS using a round-robin scheduler, allowing threads to run in a circular order without manual intervention.

How does the manual scheduling in the MiROS RTOS work before automation?

Before automation, scheduling was hard-coded using an `if` statement to manually switch between two threads (blinky1 and blinky2), which is not scalable for more threads.

What is the purpose of the `OS_thread[]` array in the automated scheduler?

The `OS_thread[]` array is used to store pointers to all threads created in the system. This array allows the scheduler to automatically select the next thread to run in a round-robin fashion.

How does the round-robin scheduler handle the index for the next thread?

The round-robin scheduler increments the current index of the running thread, wraps it around when it exceeds the number of threads, and sets the `OS_next` pointer to the next thread in the array.

Why is it important to use assertions like `Q_ASSERT()` in the implementation?

Assertions such as `Q_ASSERT()` are used to ensure the integrity of the system, such as preventing the overflow of the thread array, and provide a mechanism to catch errors early in the embedded system environment.

What is the significance of composability in the MiROS RTOS?

Composability refers to the ability to add new threads to the system without changing the existing thread code or RTOS code. This allows for flexible and modular thread management.

How does the initialization timeline affect interrupt handling in the MiROS RTOS?

The initialization timeline must ensure that interrupts are enabled only after all threads are started to prevent a context switch from occurring too early, which could interrupt the initialization process and prevent threads from starting.

What role does the `OS_run()` function play in the RTOS?

The `OS_run()` function transfers control to the RTOS after all initialization is complete, configuring interrupts and starting the scheduling of threads without returning to the main function.

What is the measured context switch time in the MiROS RTOS, and why is it important?

The context switch time is measured to be around 1.5 microseconds (75 clock cycles). This is important as it shows the efficiency of the RTOS in managing threads with minimal overhead.

What is the next topic to be covered in the MiROS RTOS course after round-robin scheduling?

The next lesson will focus on improving thread management by implementing efficient blocking during delays, instead of using the `BSP_delay()` function, which wastes CPU cycles.