We’re only a week a way from the release of Zephyr 3.4, and everyone (including yours truly) is busy polishing everything for the release. I am trying to put together a nice video that will highlight some of the cool new features added in this version, even if you’ve already heard about some of them in the recent weeks if you’ve been reading this weekly update!
Since there isn’t much to cover in terms of actual Zephyr code changes (dozens of bugs have been fixed though, and commit activity has only barely slowed down), I am focusing this week’s article on 3 links you may have missed.
Infineon Hacking Challenge
Infineon just launched a coding challenge in partnership with Hackster.io around all things IoT and connected devices. The rules are super open and should leave you with room to create virtually anything you want! Bonus points if you’re using Zephyr, of course (to be clear: it’s not an official rule, just a personal recommendation 😊)!
You have until June 30 to submit your application and apply for getting some free hardware to help you with implementing your idea. You will then have until Sep. 22 to fully document your project and make your resource files (diagrams, BOM, code, etc.) available.
Adding PWM sound in Zephyr
Adding PWM sound in Zephyr – Blog post by Chris Gammell
Chris Gammell from Golioth recently published a nice and detailed article that dives into PWM (Pulse-Width Modulation) and how you can use it in Zephyr to dim LEDs—fun!—or even play sound—much funnier!
A reminder to fill out the Zephyr RTOS Technical Documentation Survey
A quick reminder that we have an ongoing documentation survey that should take you just 5 minutes to complete. The goal is to understand better how you (and your organization) are using the documentation today, and what are some of the things you’d potentially like to see improved.
Take the Zephyr RTOS Technical Documentation Survey
As always please feel free to jump in with your thoughts or questions in the comments below. See you next week!
If you enjoyed this article, don’t forget to subscribe to this blog to be notified of upcoming publications! And of course, you can also always find me on Twitter and Mastodon.
Catch up on all the editions of the Zephyr Weekly Update:
Like I mentioned last week, the release of Zephyr 3.4 is approaching (currently scheduled for June, 16), and the first release candidate is already out. There are slightly less noteworthy highlights this week, since last week’s post was published only a couple hours before the actual feature freeze deadline. So, since it should be a short read, I thought I would also take some time to list 3 things you can do to help make 3.4 a success!
This week in Zephyr land
Zephyr v2.7.5 LTS is out!
Chris Friedt from Meta, our release engineer for this LTS (Long-Term Support) version, just pushed the big button yesterday, and Zephyr v2.7.5 LTS is officially out the door. I will let you go through the release notes to catch up on the issues that have been addressed, but I would like to call your attention to the changes made around mbedTLS:
Moving mbedTLS to 2.28.x series (2.28.3 precisely). This is an LTS release that will be supported with bug fixes and security fixes until the end of 2024.
This version is incompatible with TF-M and because of this TF-M is no longer supported in Zephyr LTS. If TF-M is required it can be manually added back changing the mbedTLS revision on west.yaml to the previous one (5765cb7f75a9973ae9232d438e361a9d7bbc49e7). This should be carefully assessed by a security expert to ensure that the know vulnerabilities in that version don’t affect the product.
Notable changes in the 3.4 main branch
Like I said, this one will be short (or is it?), but some nice changes nevertheless. In a slightly less structured way as usual, here goes:
Testing
Pytest is a Python framework that “makes it easy to write small, readable tests, and can scale to support complex functional testing for applications and libraries”. A new plugin has been added for allowing to leverage Pytest in Twister test suites. This allows for more “advanced” tests that e.g. communicate with the flashed application on real or simulated hardware, which is accomplished through a device abstraction (concrete implementations are available for real-hardware over serial connection, qemu, an native POSIX). This opens the door to very advanced scenarios where e.g the device under test is running some kind of client application, and a test server can be started as a subprocess to test the entire client/server interaction. An example of a Pytest test that tests basic shell behavior can be found here, and there are some pull requests opened that demonstrate even more complex scenarios. See more in the documentation here (PR #57117).
Robot Framework, a generic open source automation framework, is now also supported as a test harness! This makes it very easy to run tests on top of the Renode emulation/simulation framework. I really like how the Robot Framework makes test super easy to read for a human. See for yourself, with the test below that checks if the version shell command works as expected. More info about this feature in the documentation page here (PR #56770).
Should Read Version From Shell
Prepare Machine
Start Emulation
Wait For Prompt On Uart uart:~$
Write Line To Uart version
Wait For Line On Uart Zephyr version
Auxiliary Displays are text-based displays that have simple interfaces for displaying textual, numeric or alphanumeric data […] auxiliary displays do not support custom graphical output to displays (and and most often monochrome), the most advanced custom feature supported is generation of custom characters. These inexpensive displays are commonly found with various configurations and sizes, a common display size is 16 characters by 2 lines.
As always, a good way to get started with this new functionality is to check out to the dedicated code sample. You will certainly note that the API couldn’t be more straightforward!
snprintk(data, sizeof(data), "Hello world from %s", CONFIG_BOARD);
rc = auxdisplay_write(dev, data, strlen(data));
Performance improvements for LVGL. The various performance tuning settings added by Daniel DeGrasse allow speed improvements up to 10x (from 3fps to 34!) on e.g. i.MX RT1170 👏 (PR #39 in Zephyr’s LVGL fork, and PR #57421).
Sensors
A new asynchronous way to interact with sensors has been introduced: raw sensor data can be acquired asynchronously using RTIO, and processed by an application-controlled thread via the decoder API. A very detailed section has been added to the documentation here, and the Sensor shell example module has been updated to use this new mechanism, so don’t hesitate to refer to it (PR #57962).
New command in the Sensor shell module: sensor trig. This command helps understand the trigger mechanism. It allows to enable/disable triggers directly from the shell and, as soon as a trigger (only data_ready supported for now) happens, a moving average for the different channels gets updated, and is output to the console when SENSOR_SHELL_TRIG_PRINT_TIMEOUT_MS milliseconds have elapsed (PR #58257).
Drivers
Added board Pin controller for the Pmod and Arduino shield interface of the Synopsys ARC EMSDP (PR #56926).
New Ethernet driver for Analog Devices ADIN2111. The ADIN2111 is a low power, 2-port 10BASE-T1L transceiver designed for industrial Ethernet applications, and is compliant with the IEEE® 802.3cg-2019™ Ethernet standard for long reach, 10 Mbps single pair Ethernet (SPE). (PR #57848).
USB Full-Speed is now supported for the USB device controller on NXP LPC55S36 and LPC55S59 (PR #58095).
Miscellaneous
New asynchronous CoAP client, supporting plain UDP sockets as well as DTLS. Check out the dedicated documentation page for more information (PR #56970).
TF-MPSA (TrustedFirmware-M Platform Security Architecture) APIs usability improvements that bring more flexibility in the way to build and link the various mbedTLS library into secure and non-secure applications (PR #58023). See a very complete and well-documented code sample here.
A first-time contribution by @tkng-rivos added support for OpenTitan watchdog (PR #57501). As a reminder, OpenTitan is an open-source reference design for silicon root of trust (RoT) chips.
Help with 3.4 release
Test, test, test!
Please take 3.4 RC1 for a spin! In particular, if you already plan on moving your product development to 3.4, then now is the perfect time to start doing so. All features are essentially in, and the RC1 is essentially very similar to what the final release will be, minus perhaps some outstanding bugs or regressions that you can contribute to help catching. Please report any issue directly in the project’s GitHub issue tracker.
Review the documentation
This one can be particularly interesting if you’ve never actually contributed back to Zephyr, and were maybe scared of doing so for you never had any code to contribute. I cannot stress enough that contributing to improving the documentation (including trivial fixes such as correcting typos!), is immensely valuable too, and not every contribution has to be code!
If you end up giving some of the new (or older) features a try, make sure to send pull requests should you catch mistakes in the documentation, things that could be explained better, etc.
On that note, we have an ongoing documentation survey that should take you just 5 minutes to complete. The goal is to understand better how you (and your organization) are using the documentation today, and what are some of the things you’d potentially like to see improved.
Take the Zephyr RTOS Technical Documentation Survey
Help spread the word
Whether you’re directly involved with the project as a contributor or maintainer, or whether you’re just a user, I would really encourage you to think about what you could do to help spread the word when the release will come out.
One thing that I would really love to see is cool demos of Zephyr 3.4 in action. So, for example, if you’ve been helping get a new board added (dozens were contributed since 3.3!) in 3.4, why not work on a short video that would showcase Zephyr running on it? Bonus points if it also showcases some of the recently added features, of course 🙂 If this sounds like something that you would like to do, please feel free to ping me if you have some ideas or questions!
A big thank you to the 4 individuals who had their first pull request accepted this week 💙 🙌: Andrei, Göran, Kornel, and Tyler.
As always please feel free to jump in with your thoughts or questions in the comments below. See you next week!
If you enjoyed this article, don’t forget to subscribe to this blog to be notified of upcoming publications! And of course, you can also always find me on Twitter and Mastodon.
Catch up on all the editions of the Zephyr Weekly Update:
