Workshop

Zephyr RTOS Programming with the BBC Microbit v2

Watch Now

01:53:02

EOC 2024

Login to Watch

Andrew Eliasz

Dr. Andrew Eliasz is the founder of First Technology Transfer (FTT), which he established in the early 1990s with a view to providing specialist, innovative, and highly tailored technical training and consultancy to organizations developing both traditional IT and embedded systems applications. Since then, FTT has built a network of consultants and technologists who collectively provide access to extensive expertise across the complete spectrum of IT and software engineering disciplines. Dr. Eliasz has over 30 years of experience developing and delivering training courses for companies such as Cap Gemini and gbDirect on topics ranging from C, C++, Unix, Networking, and Perl to advanced databases and systems analysis and design. In that time, he has also been involved in various consultancy projects, including work on the implementation of industrial protocols such as the HART protocol and on the implementation of firmware for fuel cell sensors. Dr. Eliasz has also written technical articles for hobbyist and trade magazines such as Elektor and Embedded Systems Europe and written papers on Medical Informatics and Expert Systems applied to Medicine. For several years, Dr. Eliasz held an associate professorship in computer science at the University of Maryland (UMUC). Several years ago, Dr. Eliasz founded Croydon Tutorial College, a community interest company based in south London offering tuition and mentoring in STEM subjects with special interests in Computer Science and Maths. Croydon Tutorial College provides teaching in these subjects to Neurodiverse Students as well as students with dyslexia and dyspraxia problems.

View full profile

Topics Covered

C Microcontroller RTOS Open Source

Workshop

Zephyr RTOS Programming with the BBC Microbit v2

Andrew Eliasz

01:53:02 EOC 2024

Andrew Eliasz

01:53:02

When logged in, you should be able to find and download, in the left column and under 'Files Provided by the Speaker', the 'Slides and Code' zip file.

Introducing Zephyr RTOS IoT programming and embedded C Programming using the BBC Microbit. A practical workshop suitable for makers, artists, and inventors.

Requirements to “follow along” and try out the examples.

1. Have nRF Connect SDK installed and also the required toolchains, Python and python packages required by West and Zephyr, and CMake, and, also Cmake.

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/installation/install_ncs.html

2. Download the BBC Microbit examples from Frank Duigan’s github site

https://github.com/fduignan/zephyr_bbc_microbit_v2

3. Setup a CLI (Command Line Interface) Zephyr development (build) environment using Chocolatey on Windows.

Useful guide : https://zafersn.medium.com/quick-zephyr-os-setup-guide-for-stm32-mcus-on-windows-4f11a8074632

[ The Zephyr BBC Microbit examples do not (currently) play nicely with the nRF Connect SDK plugin for VSCode ]

4. Get hold of a BBC Microbit v2 (v2.2) board and a USB cable e.g. from adafruit

https://www.adafruit.com/product/4834

1 / 6

Please log in or create an account to test your knowledge and see the answers.

According to Andrew, what is the recommended way to begin learning Zephyr on the BBC Micro:bit v2?

A Start with complex examples like BLE mesh and multitasking to learn advanced features first.

B Begin with simple peripheral examples (LEDs, GPIO), learn polling and interrupts, then progress to sensors and threads.

C Only use block programming (MakeCode) because C/C++ is too difficult for beginners.

D Focus exclusively on high-level libraries and avoid studying device drivers or hardware details.

E Skip hardware examples and practise only with native_posix simulations to learn Zephyr concepts.

Why did Andrew recommend building Micro:bit Zephyr examples from the command line with West rather than relying on the nRF Connect SDK VS Code plugin?

A Because the nRF Connect SDK plugin is officially deprecated and no longer supported by Nordic.

B Because the Micro:bit examples do not (currently) play nicely with the nRF Connect SDK plugin for VS Code, and the CLI is quicker and more reliable.

C Because West builds produce smaller binaries than using VS Code.

D Because building with VS Code always requires a paid license.

E Because the speaker believes graphical IDEs are inherently insecure for embedded development.

What did Andrew emphasize about Zephyr's Device Tree and the generated code?

A Zephyr avoids any use of device trees to keep builds simple and manual device setup is preferred.

B Zephyr uses the Linux Device Tree syntax and generates headers; heavy use of C preprocessor macros ('macrobatics') is involved.

C Device tree files are optional and only used for Linux targets, not microcontrollers like the Micro:bit.

D Zephyr's device tree is identical to Arduino board definitions and requires no preprocessing.

E You must hand-write all driver header files because Zephyr won't generate them from hardware descriptions.

Why are board overlays / manifest tweaks required when building some examples for BBC Micro:bit v2?

A Because overlays are only needed to turn off debugging output and are not related to hardware differences.

B Because the Micro:bit v2 has different onboard hardware (e.g. speaker) than v1, so configuration entries in YAML/overlays enable the correct drivers or the build will fail or produce errors.

C Because v2 requires a proprietary binary blob that must be referenced in the manifest to build.

D Because overlays convert C code into MakeCode blocks for compatibility.

E Because overlays are only useful for changing the LED matrix patterns at runtime, not for build-time hardware configuration.

What key difference between semaphores and mutexes did Andrew highlight when discussing synchronization examples (e.g., Dining Philosophers)?

A Semaphores enforce strict ownership (only the owning thread can release), while mutexes are free-for-all and can be released by any thread.

B Semaphores are counting and do not have ownership semantics, whereas mutexes have ownership and can only be released by the thread that acquired them (and are recursive).

C Mutexes are only usable on single-core systems, while semaphores require SMP to work correctly.

D Semaphores are limited to binary values and cannot be used as counting semaphores in Zephyr.

E Mutexes automatically detect deadlocks and resolve them, so they are preferred for all synchronization tasks.

What did Andrew point out as a distinctive Zephyr capability when creating threads?

A Zephyr only allows threads to be created at runtime via API calls; compile-time thread creation is not supported.

B Zephyr supports creating threads at compile time using macros like K_THREAD_DEFINE, which embeds thread definitions into the binary instead of creating them dynamically.

C Zephyr requires threads to be written in assembly language for deterministic scheduling.

D Zephyr uses POSIX pthreads exclusively and does not provide its own thread-defining macros.

E Zephyr threads cannot be stopped or started after creation; they run once and then exit permanently.

Formatting help

italics	surround text with asterisks
bold	surround text with two asterisks
hyperlink	[hyperlink](https://example.com) or just a bare URL
inline code	surround text with single `backticks`
code block (multi-line)	wrap on its own lines with three backticks: ``` your code here ```
~~strikethrough~~	surround text with ~~two tilde characters~~
quote	prefix with >

Upvotes Newest Oldest

Dflyer

Score: 0 | 2 years ago | no reply

Great job, very informative and an excellent introduction to getting started with Zephyr!

Partners & Sponsors

STMicroelectronics

Memfault

NXP

Micro Digital, Inc.

MySQL

Become a Sponsor