Study guide — what to focus on

This module is curated — the teaching is a top free course (linked in the card above); our job is to point you at the right things, make you prove it, and certify you.

The plan

1. Watch the course (the card above — Shawn Hymel's Digi-Key Introduction to RTOS series). You don't need every part memorised — aim to understand the ideas below. Parts 1–8 cover everything the check tests.
2. Focus on these — they're what the check tests and what you'll use for real:
   • What an RTOS is — a small kernel that runs many tasks on one microcontroller, with predictable timing, instead of one big loop() (a "superloop").
   • Tasks — each is like a thread: its own function and stack, created and run by the scheduler.
   • Scheduling, priorities & preemption — the scheduler runs the highest-priority ready task, and can preempt (interrupt) a lower-priority one the instant something more important needs to run.
   • Blocking vs. busy-waiting — vTaskDelay() blocks a task so others get the CPU; a spin-loop busy-waits and starves them.
   • Queues — the thread-safe way to pass data from one task to another (e.g. sensor → display).
   • Mutexes & semaphores — a mutex locks a shared resource so only one task uses it at a time; a semaphore signals between tasks (or from an interrupt) that an event happened.
3. Prove it in Forge (next section) — apply the multitasking idea to a real device.
4. Take the K-Check to earn your certificate.

Why this connects to building real products

A real product rarely does just one thing. It reads a sensor on a schedule, drives a screen, watches a button, maybe talks over Wi-Fi — all at once, and the time-critical jobs can't be allowed to miss their deadlines. That's exactly the problem an RTOS solves: you split the work into tasks, give the urgent ones higher priority, and let them share data through queues instead of tangled global state. It's the difference between firmware that mostly keeps up and firmware you can trust. When you design a device in Forge, the boards it picks (the ESP32 especially) run precisely this kind of code — so knowing tasks, queues and semaphores is what lets you turn a parts list into a product that actually behaves.

Time to apply it. The course taught you how an RTOS splits work into concurrent tasks; now design a device that genuinely needs that.

Send the prompt below in Forge Design and picture the firmware behind it: the scheduled sensor read is one task, driving the display is another, and the button response is a third — each with its own priority, sharing data through a queue. That mapping — concurrent jobs ↔ RTOS tasks — is the whole point of this module.