DEV Community: Shyam Kumar

RTOS Scheduling — What Nobody Told You

Shyam Kumar — Thu, 26 Mar 2026 11:22:17 +0000

Motor controller. Production hardware. The system would run perfectly for hours, then suddenly freeze — no crash, no fault handler, just... silence. The watchdog would reset everything and we'd be back in business. For about six hours.

It took me two days to figure out it was a priority inversion. A low-priority logging task was holding a mutex that a high-priority motor task needed. A medium-priority CAN handler kept preempting the logger. The motor task starved. The watchdog fired.

I'd been writing RTOS code for a year at that point. I thought I understood scheduling. I did not. This post is everything I learned the hard way — written for you, so you don't have to spend two days staring at a logic analyzer.

<10µs
Context switch on Cortex-M4 @ 168MHz

O(1)
Task selection — single CLZ instruction

69.3%
Max CPU utilization under RMA (n→∞)

First, Let's Kill a Myth

The most common thing I see new embedded engineers get wrong: they think an RTOS makes their system faster. It doesn't. It makes timing predictable. That's a completely different thing, and it's the whole point.

On a bare-metal superloop, everything runs in sequence. Your 100ms display refresh sits right next to your 1ms motor update. You're always one long function away from missing a deadline. You can go fast — but you can't go on time.

An RTOS gives you a contract: 'A task with sufficient priority will preempt whatever is running within a bounded window.' That bound is what makes real-time systems work. Not speed. Predictability.

Think of the RTOS scheduler as a function that runs at every tick and after every blocking call, answering one question: 'Which task should own the CPU right now?' In a fixed-priority system, the answer is always: 'the highest-priority task that is Ready.' Everything else is just implementation detail.

The moment you need to service a CAN interrupt, update motor PWM, and refresh a display — all with distinct timing requirements — you need a scheduler. That's it. If your timing requirements are all the same, a superloop is fine. The second they diverge, you need this.

What the Scheduler Actually Does

Most tutorials show you a pretty diagram of task states and then show you xTaskCreate(). That's skipping the good part. Let me show you the actual scheduler code — FreeRTOS, stripped to its bones.

tasks.c — vTaskSwitchContext (simplified)
C
/* This is the entire scheduler. Seriously. */
void vTaskSwitchContext( void )
{
    UBaseType_t uxTopPriority;

    /* Find the highest-priority bit set in the ready-list bitmap */
    portGET_HIGHEST_PRIORITY( uxTopPriority, uxTopReadyPriority );

    /* Pick the first task at that priority level */
    listGET_OWNER_OF_NEXT_ENTRY( pxCurrentTCB,
        &( pxReadyTasksLists[ uxTopPriority ] ) );
}

/* On ARM Cortex-M, portGET_HIGHEST_PRIORITY expands to:
   uxTopPriority = ( 31UL - __clz( uxReadyPriorities ) );

   That's it. One CLZ instruction. O(1). No matter how many tasks.
   This is why RTOS context switches are so fast. */

Task States — Draw This on Paper

Seriously, take five minutes and draw the task state machine on paper. More RTOS bugs come from not having this mental model clearly loaded than from any API misuse. Here it is:

The thing people get wrong: they think 'BLOCKED' means the task is stuck. It's not stuck — it's efficiently parked. A blocked task consumes zero CPU. It's sitting in a list, waiting for something specific. The scheduler doesn't even look at it until that event fires.

This is why RTOS-based systems can run dozens of tasks on a Cortex-M4 with sub-millisecond response times and still have 90% CPU headroom. Most tasks are blocked most of the time. The scheduler only runs tasks that have something to do.

The Tick Rate Trap (I've Seen This a Dozen Times)
vTaskDelay(1) does not delay for 1 millisecond. It delays for 1 tick. If your tick rate is 100Hz, that's 10ms. Always use pdMS_TO_TICKS(1) and always know what your tick rate is configured to. I once inherited a codebase where someone had set configTICK_RATE_HZ to 10 — every vTaskDelay(100) was actually a 10-second delay. Fun to debug.

Context Switching in Assembly

This is the part most tutorials skip. A context switch isn't magic — it's assembly code that saves every CPU register from the current task onto its stack, calls the scheduler to pick the next task, then restores every register from the new task's stack. That's it.

On ARM Cortex-M, the hardware helps you out. When an interrupt fires (including the PendSV interrupt the RTOS uses for scheduling), the CPU automatically pushes 8 registers onto the current stack before jumping to your ISR. The RTOS just has to handle the rest.

port.c — PendSV_Handler, ARM Cortex-M4F (annotated)
ASM
PendSV_Handler:
    ; Hardware already saved: xPSR, PC, LR, R12, R3, R2, R1, R0
    ; Those 8 are free. Now we save the rest.

    MRS     R0, PSP              ; Get current task's Process Stack Pointer
    LDR     R3, =pxCurrentTCB   ; Load address of current TCB pointer
    LDR     R2, [R3]            ; R2 = current TCB

    VSTMDB  R0!, {S16-S31}      ; Save FPU registers (if task used FPU)
    STMDB   R0!, {R4-R11, R14}  ; Save R4-R11 + EXC_RETURN value
    STR     R0, [R2]            ; Save updated stack pointer back into TCB

    ; ↑ Current task is now fully frozen. Stack holds its entire world.

    BL      vTaskSwitchContext   ; Pick the next task (updates pxCurrentTCB)

    ; ↓ Restore the new task. It was frozen exactly like this at some point.

    LDR     R1, [R3]            ; R1 = new TCB (pxCurrentTCB was updated)
    LDR     R0, [R1]            ; R0 = new task's saved stack pointer
    LDMIA   R0!, {R4-R11, R14}  ; Restore R4-R11 + EXC_RETURN
    VLDMIA  R0!, {S16-S31}      ; Restore FPU registers
    MSR     PSP, R0             ; Update Process Stack Pointer

    BX      R14                 ; Return from exception.
                                ; Hardware restores the other 8 registers.
                                ; CPU is now running the new task as if
                                ; it was never interrupted. Magic. (It's not magic.)

The Task Control Block (TCB) is a struct whose first member is always the saved stack pointer. That's not an accident — it means the assembly above can find it at offset zero without needing to know anything else about the struct layout. Clean engineering.

Stack Sizing Is Not a Guess
Each task needs enough stack for its own local variables, its call chain, AND the full context save shown above (17 core registers + 16 FPU registers = 33 words = 132 bytes just for the context frame, before your code does anything). Undersize the stack and you get silent memory corruption — the overflow writes into whatever is adjacent in RAM. Enable configCHECK_FOR_STACK_OVERFLOW 2 in every development build. Every one.

Priority Inversion — Back to My Bug
Remember the motor controller bug from the intro? Let me walk you through exactly what happened — because understanding this scenario saves careers.

In 1997, the Mars Pathfinder landed on Mars. Within a few days, the system started resetting itself. Telemetry showed a watchdog timeout. NASA engineers pored over the data, running the same software on Earth, trying to reproduce it. Eventually they found it: a priority inversion between a low-priority meteorological task holding an information bus mutex, a medium-priority communications task preempting it repeatedly, and a high-priority bus manager task starving as a result. The fix — enabling priority inheritance in VxWorks, a single config flag — was uploaded to a spacecraft 190 million kilometres away. It worked.

Here's the exact scenario. Three tasks, one mutex:

The scheduler isn't broken. It's doing exactly what you told it to do. HIGH is blocked (legitimately waiting on a mutex). MEDIUM is ready. So MEDIUM runs. The scheduler cannot know that MEDIUM's execution is indirectly preventing HIGH from getting what it needs.

The fix is priority inheritance: when HIGH blocks on a mutex held by LOW, temporarily raise LOW's priority to match HIGH's. Now MEDIUM can't preempt LOW. LOW finishes, releases the mutex, its priority drops back to normal, and HIGH gets what it was waiting for.

The fix — one word difference, massive impact
C
/* ❌ WRONG — binary semaphore has NO priority inheritance */
xMutex = xSemaphoreCreateBinary();

/* ✅ CORRECT — mutex implements priority inheritance automatically */
xMutex = xSemaphoreCreateMutex();

/* That's it. That's the entire fix.
   When a high-priority task blocks on this mutex, FreeRTOS
   automatically boosts the holding task's priority.
   No code changes anywhere else required. */

/* The general rule: if you're protecting a shared resource
   (SPI bus, I2C peripheral, buffer, state) — use a MUTEX.
   Binary semaphores are for signalling, not resource protection. */

Scheduling Algorithms — Your Actual Options

Most embedded RTOS implementations give you Fixed-Priority Preemptive Scheduling. Tasks have static priorities. Highest-priority ready task runs. Higher-priority tasks preempt lower ones immediately. Clean. Simple. Auditable. Use it.

There's a theorem behind priority assignment called Rate Monotonic Analysis (RMA): assign higher priority to tasks with shorter periods. A task running every 1ms gets a higher priority than one running every 10ms. This is provably optimal — if any fixed-priority assignment can meet all deadlines, the rate-monotonic assignment will too.

📐 The Utilization Bound Formula (Worth Memorising)
For n tasks, the system is provably schedulable if:

U = Σ (C_i / T_i) ≤ n(2^(1/n) − 1)

Where C_i = worst-case execution time, T_i = period. As n grows, this approaches ln(2) ≈ 69.3%. If your total utilization is under ~70%, you're almost certainly fine. Over 70%, you need to run Response Time Analysis to be sure.

Property	Cooperative	Preemptive
Context switches when	Task explicitly yields	Any tick or ISR return
Interrupt latency	Unbounded	Bounded (≤1 tick)
Race conditions	Fewer — natural protection	Must use mutexes
Hard real-time	No	Yes
Debug difficulty	Easier	Timing-dependent bugs
When to use	Tiny MCUs, all tasks same priority	Anything with mixed timing requirements

In practice, use preemptive. Cooperative scheduling is a useful teaching tool and occasionally appropriate for deeply resource-constrained parts, but if you're on a Cortex-M with an RTOS, you want preemption. You're not writing an Arduino sketch.

Patterns That Actually Work in Production

1. Keep ISRs Stupid Short

An ISR that does actual work is a bug waiting to happen. You're running at interrupt priority — you can't use most FreeRTOS APIs, you can block the scheduler, and you're eating into every other interrupt's latency. Post to a queue and return. Let a task do the work.

The deferred interrupt pattern — the right way to handle hardware events
C
/* ISR: as short as humanly possible */
void USART1_IRQHandler( void )
{
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    uint8_t   byte = USART_ReceiveData( USART1 );

    xQueueSendFromISR( xRXQueue, &byte, &xHigherPriorityTaskWoken );

    /* If posting unblocked a higher-priority task, trigger a context
       switch before this ISR returns. No delay. Immediate handoff. */
    portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}

/* Task: does the actual work at task priority */
void vUARTTask( void *pvParams )
{
    uint8_t byte;
    for(;;) {
        /* Zero CPU usage while nothing arrives */
        if( xQueueReceive( xRXQueue, &byte, pdMS_TO_TICKS(100) ) )
            vProcessByte( byte );
    }
}

2.Use vTaskDelayUntil — Not vTaskDelay

This one bites people constantly. vTaskDelay() starts counting from when the task wakes up. So if your task body takes 2ms and you delay for 10ms, your actual period is 12ms. And it drifts. Use vTaskDelayUntil() for anything periodic — it measures from the last wake time, so execution time doesn't accumulate into your period.

periodic_task.c — do it this way, every time
C
void vMotorControlTask( void *pvParams )
{
    TickType_t xLastWake = xTaskGetTickCount();
    const TickType_t xPeriod = pdMS_TO_TICKS( 1 );  /* 1ms hard */

    for(;;) {
        vTaskDelayUntil( &xLastWake, xPeriod );
        /* Blocks until (xLastWake + xPeriod), then updates xLastWake.
           Even if you ran long last iteration, the next wake time
           is still correct. No drift. */

        vReadEncoders();
        vRunPIDLoop();
        vSetPWMOutputs();
    }
}

3.Enable Stack Overflow Detection — Always

FreeRTOSConfig.h + hooks.c
C
/* FreeRTOSConfig.h — method 2 fills stack with 0xA5 pattern
   and checks it on every context switch. Catches it early. */
#define configCHECK_FOR_STACK_OVERFLOW  2

/* hooks.c */
void vApplicationStackOverflowHook( TaskHandle_t xTask, char *pcName )
{
    /* Stack is corrupt — do NOT call any FreeRTOS API here */
    taskDISABLE_INTERRUPTS();
    /* Hang. Let the debugger catch it or watchdog reset.
       pcName will tell you which task overflowed.
       Then go back and double its stack size. */
    for(;;);
}

/* After a while, use this to check headroom in normal operation: */
UBaseType_t remaining = uxTaskGetStackHighWaterMark( xMyTask );
/* If this is under ~50 words, size up. */

Mistakes I've Seen (And Made)

No judgment here. These are real mistakes from real systems, some of them mine.

The Mistake	What You'll See	The Fix
Calling blocking API from ISR	Hard fault, immediate crash, watchdog reset	Use xQueueSendFromISR() and friends
Binary semaphore as mutex	Intermittent timing violations, priority inversion	xSemaphoreCreateMutex() — always
vTaskDelay() for periodic tasks	Gradual period drift, cumulative jitter	vTaskDelayUntil() — no exceptions
Stack too small	Corrupted globals, random crashes, hours of debugging	Enable overflow check, use watermark API
Acquiring mutexes in different orders	Deadlock. Full stop. System hangs forever.	Global mutex acquisition order. Document it. Enforce it.
Task that never blocks	Everything starves. System appears frozen at lower priorities	Every task must call a blocking API somewhere in its loop
Using FreeRTOS API before vTaskStartScheduler()	Silent corruption, crash on first switch	Initialise hardware in main, start everything in tasks

Conclusion

Embedded systems engineering in India has matured fast. The engineers writing firmware for automotive ECUs, medical devices, and industrial controllers across Bangalore, Pune, and Hyderabad are dealing with exactly these problems — priority inversion on a CAN bus, stack overflows at 3am, a watchdog nobody can explain.
Institutes like the Indian Institute of Embedded Systems (IIES) exist because this gap between knowing C and understanding what the kernel is actually doing underneath is real, and it costs production hours.
But no course closes that gap alone. The concepts in this post — task states, context switching, priority inheritance — only become instinct after you've broken something in production and had to find it.
Read the theory. Then go write a task, starve it on purpose, and debug it yourself. That's the part nobody can teach you.

How to Program STM32 Microcontroller: Complete Beginner Guide with Architecture

Shyam Kumar — Wed, 21 Jan 2026 12:06:25 +0000

Learning how to program STM32 microcontroller devices has become an essential skill for anyone entering the embedded systems field. From IoT sensors and robotics to automotive electronics and smart medical devices, STM32 boards are used in thousands of real-world products. Because of their performance, low power consumption, and integrated peripherals, they are often considered the industry standard for modern embedded design.

For students, hobbyists, and professional engineers alike, STM32 provides a practical balance between ease of development and powerful hardware control. This guide explains STM32 architecture, development tools, programming basics, and real applications so you can confidently start building your own projects.

Understanding STM32 Architecture Before You Start Programming

Before writing firmware, it is important to understand how the STM32 architecture works internally. Every STM32 microcontroller is built on the ARM Cortex-M core, which is optimized for real-time and low-power embedded tasks. Unlike a general processor, STM32 integrates memory, timers, communication interfaces, and analog peripherals directly into the chip.

This tight integration allows the microcontroller to read inputs, process logic, and control hardware without delays. Because everything is available on a single device, systems become more reliable and cost-effective.

A typical STM32 architecture includes:

ARM Cortex-M CPU core
Flash memory for program storage
SRAM for runtime data
GPIO pins for hardware control
Timers, ADC, DAC, PWM modules
UART, SPI, I2C, CAN, USB communication

Understanding these blocks makes STM32 programming easier because you know exactly which peripheral controls each task.

Why Use STM32 Microcontroller in Embedded Systems?
Many developers ask why STM32 is preferred over traditional 8-bit controllers. The answer lies in efficiency and scalability. Modern embedded systems require faster computation, multitasking, and connectivity, which older platforms struggle to provide.

The advantages of STM32 microcontrollers become clear in real projects:

Higher 32-bit processing performance
Rich built-in peripherals
Very low power consumption
Wide product range for different budgets
Strong software ecosystem and documentation

Because of these benefits, STM32 is now widely used in industrial automation, IoT, consumer electronics, and healthcare devices.

STM32 Microcontroller Features That Simplify Development

STM32 microcontroller features are designed to reduce both hardware complexity and software effort. Instead of adding multiple external chips, most functionalities are already built into the MCU.

Key capabilities include fast clock speeds, multiple communication interfaces, integrated analog modules, and advanced timers. This allows developers to implement motor control, sensor acquisition, data logging, and wireless communication on a single board.

The result is smaller PCBs, lower costs, and faster product development cycles — which is extremely important in commercial environments.

STM32 Development Tools You Need to Get Started

Choosing the right STM32 development tools makes programming much easier, especially for beginners. STMicroelectronics provides a complete ecosystem that handles code writing, configuration, and debugging.

The most commonly used tools are:

STM32CubeIDE – official IDE with compiler and debugger
STM32CubeMX – graphical peripheral configuration tool
HAL/LL libraries – ready-made drivers
ST-Link debugger/programmer

These tools automatically generate initialization code, saving hours of manual setup. Even beginners can configure GPIO, UART, or ADC using simple graphical options.

This is one reason STM32 is often recommended as a beginner-friendly platform.

How to Program STM32 Microcontroller: Step-by-Step Workflow

If you are new to STM32 programming, the process usually follows a simple structure. After a few projects, it becomes routine.

Typical workflow:

Create project in STM32CubeIDE
Configure peripherals in CubeMX
Generate initialization code
Write application logic in C/C++
Compile, flash, and debug

Most STM32 programming is done in Embedded C because it provides low-level hardware control and high performance.

First Example: LED Blink Program (STM32 Programming Guide)

A basic LED blink is often the first experiment in any STM32 beginner guide. It demonstrates GPIO control and helps verify that your board is working correctly.

#include "stm32f4xx_hal.h"

int main(void)
{
    HAL_Init();
    __HAL_RCC_GPIOD_CLK_ENABLE();

    GPIO_InitTypeDef led;
    led.Pin = GPIO_PIN_12;
    led.Mode = GPIO_MODE_OUTPUT_PP;
    led.Pull = GPIO_NOPULL;
    led.Speed = GPIO_SPEED_FREQ_LOW;

    HAL_GPIO_Init(GPIOD, &led);

    while(1)
    {
        HAL_GPIO_TogglePin(GPIOD, GPIO_PIN_12);
        HAL_Delay(500);
    }
}

This simple firmware continuously toggles an LED every 500 milliseconds. From here, you can extend the program to read sensors, send UART data, or control motors.

STM32 Applications in the Real World

The true strength of STM32 becomes clear when you see where it is used. These controllers are not limited to academic projects; they power many commercial systems that require reliability and precision.

Common STM32 applications include:

Smart home and IoT devices
Robotics and drones
Automotive control systems
Industrial monitoring
Medical instruments

These STM32 real-time applications benefit from fast interrupt response and stable performance, which are critical in safety-sensitive environments.

This scalability allows you to start small and upgrade without redesigning everything from scratch.

Final Thoughts

Understanding how to program STM32 microcontroller devices opens the door to modern embedded system development. With a strong architecture, rich peripherals, low power design, and professional development tools, STM32 provides everything needed to build reliable real-time products.

Whether you are a student learning fundamentals or an engineer developing industrial solutions, STM32 offers a practical and future-proof platform. By mastering STM32 programming, you gain skills that directly apply to IoT, robotics, automation, and many other high-demand technologies. If you want structured guidance, hands-on embedded training, and real-world project support, you can explore more learning resources and programs at IIES: https://iies.in

What I Wish I Knew Before Learning Embedded Systems

Shyam Kumar — Mon, 29 Dec 2025 11:29:00 +0000

I believed that learning embedded systems was as simple as writing C code and flashing it onto a microcontroller.

I wish someone had told me sooner because I was mistaken.

Embedded systems are more than just another area of programming. They are rewarding and challenging because they make you think differently.

Embedded Systems Are Not “Just Software

One of the biggest misconceptions is treating embedded systems like regular software development.

In embedded:

Memory is limited
Timing actually matters
Hardware behavior affects your code
A small mistake can freeze the entire system

You don’t just write code, you work with the physical world.

Debugging Is a Core Skill(Not an Optional One)

Early on, I thought debugging meant fixing compiler errors.In reality,embedded debugging often looks like:Code compiling perfectly but not working LEDs not blinking as expected Communication protocols silently failing Timing issues that appear randomly Learning how to read datasheets, inspect registers, and test step-by-step is more important than memorizing syntax.

Tools Matter More Than People Realize

Another surprise was how important tools are:

Debuggers
Logic analyzers
Oscilloscopes
Serial monitors

Knowing how to use these tools efficiently can save hours, sometimes days, of frustration.

Theory Alone Is Not Enough

Books and tutorials help, but embedded systems don’t really click until you:

Wire real hardware
Burn firmware multiple times
Break things and fix them again
Deal with unexpected behavior
Hands-on practice teaches lessons no tutorial can fully explain.

Patience Is a Required Skill

Embedded systems can be slow to learn, especially in the beginning. Progress doesn’t always feel linear:Some days nothing works Some bugs take hours for a one-line fix Some concepts take time to sink in But once things start connecting, the learning becomes incredibly satisfying.

Advice for Beginners

If you’re starting your embedded journey, here’s what actually helps:

Focus on fundamentals before jumping to advanced topics

Learn how to read datasheets early
Don’t skip hardware basics
Practice debugging deliberately
Build small projects and iterate

You don’t need to know everything at once, consistency beats speed.

Final Thoughts

Embedded systems aren’t for everyone, but for those who enjoy problem-solving at the intersection of hardware and software, it’s deeply rewarding.
If you’re currently learning embedded systems, you’re probably struggling and that’s completely normal. Stick with it. The skills you build here stay relevant for a long time. If you’re exploring structured learning resources in embedded systems, having access to hands-on labs and mentorship can be helpful. Platforms focused on practical embedded training are worth exploring.

If you found this helpful, For more detail visit here: https://iies.in/