In the Arduino IDE (2.3.7) Board Manager, what is the difference between the Arduino Mbed OS Boards and the Arduino Zephyr Boards (BETA) packages?
The GIGA WiFi R1 appears in both.
Hi @ahdavidson. The Arduino Mbed OS Giga Boards platform has an Arduino core that is built on the Mbed OS operating system:
The Arduino Zephyr Boards (BETA) platform has an Arduino core that is built on the Zephyr operating system:
The goal is for there to not be any significant differences between the two for Arduino sketch code utilizing the standardized Arduino core API (e.g., digitalWrite). As with any platform, one will not be compatible with code that uses lower level code provided by the other. Since the average Arduino user doesn't often use such code in their own sketch code, they will mostly encounter these incompatibilities when trying to use libraries written specifically for the other platform.
As the "(BETA)" suffix indicates, the Arduino Zephyr Boards (BETA) platform is currently in a beta phase of development. In the current phase, the platform is only recommended for use under one of the following scenarios:
- You want to contribute to the development of the platform by doing beta testing and reporting any bugs you find to the developers
- You are participating in the development of the platform
- You require some capability that is not provided by the Arduino Mbed OS Giga Boards platform
- You are an "early adopter" who is willing to put up with some instability and bugs in order to get started on the future of development for the GIGA R1 WiFi right away
Arduino will continue to maintain the Arduino Mbed OS Giga Boards platform, but the Zephyr-based platforms will be the primary focus of development from here onward. Zephyr OS is very nice, so I think this will be a good new direction once the platform reaches its stable development phase and becomes well established in the Arduino ecosystem.
Thanks for the clarification.
You are welcome. I'm glad if I was able to be of assistance.
Regards, Per
Hi Per, when roughly are you expecting Zephyr to come out of Beta?
How easy will it be for library developers to change their code over to work in Zephyr? (i.e. how long do we think it might be before there are a good range of libraries for Zephyr)
I’m working on various projects that could well benefit from Zephyr and I’m trying to work out when to start thinking of moving towards using it. I’m very much looking forward to the compile time improvements as some of my current projects take quite a few minutes to compile, despite a dedicated M3 Pro Mac.
Hope all going well with you! cheers, Giles
The Zephyr OS-based Arduino boards platform for the GIGA R1 WiFi and various other Arduino boards has now been promoted from the former "beta" development status to a production ready "stable" status:
Thanks, @ptillisch,
Over the last many months, Arduino has greatly improved it's usage of Zephyr and its functionality.
But maybe it is just me, but I feel like there are still some pieces missing or incomplete.
M4 cores
For example the Giga, Portenta H7, Nicla Vision and others have two cores, the M7 and the M4. Currently only the M7 cores are being utilized in these boards. What are the plans to allow user sketches on these boards to be able to utilize both the M7 and M4?
Note, both cores are defined within Zephyr, that is:
D:\zephyrproject\zephyr\boards\arduino\giga_r1>dir
Volume in drive D is DATA
Volume Serial Number is 5C92-8524
Directory of D:\zephyrproject\zephyr\boards\arduino\giga_r1
07/08/2026 01:05 PM <DIR> .
05/31/2026 07:08 AM <DIR> ..
05/31/2026 07:08 AM 1,480 arduino_giga_r1.dtsi
04/13/2025 06:50 AM 665 arduino_giga_r1_stm32h747xx_m4.dts
04/13/2025 06:50 AM 277 arduino_giga_r1_stm32h747xx_m4.yaml
05/31/2026 07:08 AM 404 arduino_giga_r1_stm32h747xx_m4_defconfig
07/08/2026 01:05 PM 6,199 arduino_giga_r1_stm32h747xx_m7.dts
05/31/2026 06:30 AM 273 arduino_giga_r1_stm32h747xx_m7.yaml
05/31/2026 07:08 AM 430 arduino_giga_r1_stm32h747xx_m7_defconfig
05/31/2026 06:30 AM 1,392 arduino_r3_connector.dtsi
04/13/2025 06:50 AM 950 board.cmake
04/13/2025 06:50 AM 121 board.yml
05/31/2026 06:30 AM <DIR> doc
04/13/2025 06:50 AM 236 Kconfig.arduino_giga_r1
07/08/2026 01:05 PM 481 Kconfig.defconfig
05/31/2026 06:30 AM <DIR> support
12 File(s) 12,908 bytes
4 Dir(s) 627,844,128,768 bytes free
Those files with _m4 within their names are setup to build for the M4. I have run some
test sketches using them, by building natively within Zephyr.
Pin Numbers / Pin Names:
The Portenta H7 and maybe others, have a lot of pins on them, that are on the high
density connectors and used and/or exposed on different carrier boards and shields
Many of these pins are not currently defined.
On MBed and I believe MicroPython use Pin Names, which is currently not implemented
in current Zephyr builds. Many of the online documents for the shields and the like
only show Pin names for the different Carrier boards. So most of these pins
I have PRs or Issues defined on most of this and I have my own helper library that supports Pin names. But as an example, I have Spreadsheet that maps the pin numbers/names that
are exposed on the Mid Carrier. The data was extracted from one of the documents, and
I added column mapping Pin Names to Pin Numbers,
The table below is for one side of the board. Those pins that actually exist on the H7 board are shown in the Pin number column, however those in Green are ones that currently are not defined within the Zephyr Arduino Pin number table, currently no access to them:
Sorry, I have probably beaten this issue to death.
Other less major issues
Like Cameras:
Zephyr has support for several different cameras, like OV767x, HM01b0, HM0260, GC2145, OV2640, OV5640, etc. Which a few of including @Merlin513 have fixed, extended and tested on several of the Arduino boards.
However the Camera definitions are defined within the Device Tree and built within the
"Boot Loader" So currently the only way to change cameras, is to build ArduinoCore-zephyr from sources and use your own private install. Is there a better way? There have been a
few discussions on the Zephyr side about this, but most were rejected as not needed within
Zephyr, you would simply define an overlay and config file for your sketch...
Other options like can/should we define a generic camera object for zephyr and some forms of plugins for the different cameras? Should we bypass (ie. not use) the Zephyr code for the cameras/DCMI and drive them external from Zephyr?
Note: This is not unique to Cameras! For example Zephyr has some TFT displays defined within it. Currently not using them but instead using external libraries.
And for what is worth, this is not the first time that many of these questions have been asked. For example: