How to Learn Zephyr RTOS on Real Hardware: A 24 Week Plan

In the last post we looked at what Zephyr is and wrote a small program with two threads and a message queue. A common next question is: how do I actually learn this properly? Zephyr is big. There are hundreds of boards, a build tool, Devicetree, Kconfig and a long list of subsystems. It is easy to jump around and end up knowing a little of everything and not much of anything.

So in this post we share a plan for learning Zephyr on a real board over about 24 weeks. You can follow it on your own with any board Zephyr supports. We use the ESP32-S3-DevKitC-1 with Zephyr 4.1 and the west tool.

What to know in C first

Zephyr code is full of pointers, structs and macros. If those still feel shaky, fix that first. You will not get far reading Zephyr samples otherwise.

Before you start, you should be able to:

• pass a pointer to a struct into a function and change it there
• read a macro and work out what it expands to
• use static, const and volatile and say why each one is there
• split code across .c and .h files

Some earlier embedded work, like blinking an LED with a vendor SDK, helps. It is not a must.

Stage 1: the build system and kernel objects

Start with the tools. Install Zephyr and west, build a sample, flash it, and print Hello World over the serial port. This sounds small, but many people lose days here later because they skipped it. Learn what west build and west flash do, and where the build output goes.

Then go through the kernel objects one at a time:

• threads and sleep
• semaphores
• mutexes and condition variables
• message queues
• software timers and work queues

For each one, write a tiny program that only uses that object. Make two threads fight over a shared counter, then fix it with a mutex. Make one thread wait on a semaphore that another gives. These small tests teach you more than reading the API docs.

In our plan this stage covers Units 1 to 8, roughly the first third.

Stage 2: memory, Devicetree and real hardware

Next comes memory. Learn how Zephyr gives you heaps and fixed blocks, and why many embedded programs avoid malloc at run time.

Then spend real time on Devicetree and Kconfig. This is where most beginners get stuck. Devicetree describes the hardware: which pins, which buses, which sensors. Kconfig turns features on and off. Learn to write an overlay file for your board and use aliases so your code does not hard code pin numbers.

Once that clicks, drive real parts: GPIO, PWM, an I2C sensor, and flash storage (NVS) for something simple like a boot counter that survives a reset. In our plan this is Units 9 to 15.

Stage 3: services, networking and updates

The last stage is about the things real firmware needs around the core logic:

• logging modules, so you can turn debug output up or down per part of the code
• the Zephyr shell, so you can type commands to your board over serial
• zbus, for passing data between parts of your program
• Wi-Fi as a station, and a small web page from a soft access point
• over the air updates (OTA)

We also drive a stepper motor in this stage, because it forces you to care about timing.

End with a capstone. Do not add a new topic. Take three things you already built and make them run together in one firmware. This is harder than it sounds. You have to bring things up in the right order and stop one part from breaking another. That is very close to real product work.

Why a real board beats a simulator

Simulators and copy paste tutorials are fine for a first look. But they hide the problems you will meet on the job: wrong wiring, a sensor at the wrong I2C address, a stack that is too small, a thread that never wakes up.

A simple habit helps a lot. For every lab, make your firmware print one short, fixed line over serial when the task really worked. For example SEM:OK for a semaphore lab, DTS:OK for a Devicetree lab, or OTA:OK after an update. If the line does not show up, the lab is not done. No guessing, no "it probably works". This also makes it easy to check your work with a script later.

How to check your own progress

Write down a few outcomes for yourself, one per area. For example: "I can use kernel objects to share data safely between threads" or "I can add a new I2C sensor using only an overlay and a driver". Then, at the end of each stage, ask if you can do each one from a blank project without looking at old code. If not, go back before moving on.

Short quizzes after each topic help too. They show gaps fast.

Common mistakes

• skipping C basics and fighting syntax instead of learning Zephyr
• jumping to Wi-Fi or OTA before understanding threads and queues
• copying a Devicetree overlay without knowing what each line means
• printing from many threads with no logging setup, and then not being able to read the output
• testing features one by one but never together

The plan we use

This is the plan we follow in our 24 week course, Zephyr RTOS on ESP32-S3. If you want to see the full list of units and outcomes, it is on the course page. Either way, the order above works well on your own too.