Categories
IoT Zephyr

Zephyr Weekly Update – Zephyr 2.7.5 LTS is out

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.

Detailed information can be found in: https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.3 https://github.com/zephyrproject-rtos/zephyr/issues/56071.

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

Display improvements

Example of a 20×4 character LCD display.

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-M PSA (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.

Participate in Zephyr RTOS technical documentation survey
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:

By Benjamin Cabé

Benjamin Cabé is a technology enthusiast with a passion for empowering developers to build innovative solutions. He has invented an award-winning open source and open hardware artificial nose that he likes to use as an educational platform for people interested in diving into the world of embedded development.
He is currently a Developer Advocate for the Zephyr Project at the Linux Foundation and lives near Toulouse, France, where he enjoys baking sourdough bread with the help of his artificial nose.

Leave a Reply

Your email address will not be published. Required fields are marked *