IO4: Reliable firmware: interrupts, RTOS tasks, watchdogs and safe state
RTOS tasks, queues and priorities
🎯You'll be able to
Explain how a real-time operating system runs tasks, and use queues and mutexes to share work safely.
🏠The everyday picture
A small restaurant has a cook, a waiter and a cashier. Each has their own job; orders pass on slips. If two people need the one knife, they take turns.
📘What it really is
-
An RTOS (such as FreeRTOS or Zephyr) runs several tasks, switching between them so each seems to run at once. Each task has a priority; the scheduler runs the highest-priority task that's ready.
-
Tasks might be: read sensors, manage the network, handle the display.
- Queues pass data between tasks safely: the sensor task puts readings in, the network task takes them out.
- Mutexes protect something only one task should use at a time, such as an I2C bus.
- Blocking is fine in a task: a task waiting for a queue or a delay lets others run, and the chip can sleep when all are waiting.
-
Pitfalls: a low-priority task holding a mutex can block a high-priority one (priority inversion); two tasks each waiting for the other's mutex never continue (deadlock).
-
Real-time means "on time, predictably", not "fast".
📝A worked example
Input: a device with a sensor task (every second) and a network task (every minute) that both use the I2C bus.
Steps:
- Give the sensor task a higher priority so readings stay on schedule.
- Put readings in a queue; the network task sends a batch each minute.
- Protect the I2C bus with a mutex, held only for each transaction.
Expected output: a design where a slow network doesn't delay readings and the bus isn't used by two tasks at once.
🌍Where it's used
- Wearables with a display, sensors and Bluetooth at once.
- Industrial controllers with tight timing.
- Connected appliances with a user interface and a network.
📝Case scenario
A device froze once a week. Two tasks each took one mutex and waited for the other's. Rewriting both to take the mutexes in the same order removed the deadlock.
🖱️Try it
Sketch JalSetu as three RTOS tasks (sensor, storage, network). Draw the queues between them and mark any shared resource that needs a mutex. Success: a diagram with at least one queue and one mutex.
⚠️Common mistakes
- Sharing variables between tasks without protection. Sign: rare corrupted values. Fix: queues or mutexes.
- Holding a mutex during slow work. Sign: other tasks stall. Fix: hold it for the shortest time.
- Too many tasks. Sign: memory runs out (each task needs a stack). Fix: only as many as the design needs.
🛠️For your project
JalSetu's practice firmware runs one task per wake; the capstone design notes ask whether you'd use an RTOS on a real board.
✅Quick check
What does "real-time" mean in an RTOS?
Show the answer
Predictably on time, not simply fast.
How should two RTOS tasks pass readings to each other?
Show the answer
Through a queue.