Categories
IoT Zephyr

Zephyr Weekly Update – Using CLion for Zephyr development

Welcome back for another weekly update about all things that happened in Zephyr land! Without further ado, let’s dive into the highlights of the past week.

Using CLion for Zephyr development

There is always a lot of questions from people new to Zephyr on what IDE they should be using (if any), and suggestions for setting it up for Zephyr development.

It is really nice to see that the folks over at JetBrains took some time to document the instructions for using CLion to develop and debug Zephyr application, and I really encourage you to give them a try!

UART over Bluetooth LE

You may remember the Zephyr Tech Talk episode from a few weeks back where Luis Ubieda presented the work he’s been doing around making it easier to use UART over Bluetooth LE.

With PR #69881, a new implementation of Nordic UART Service (NUS) is provided. It essentially exposes to characteristics for RX/TX, allowing to mimic a UART over BLE.

A dedicated nus-console snippet makes it really easy to user UART over BLE for the Zephyr console, by allowing to redirect serial console output to a UART over NUS Devicetree instance.

MPU Support on Xtensa

MMU support was added a little while back, and it’s great to see that MPU (Memory Protection Unit) is now supported on Xtensa architectures.

PR #67938.

Boards & SoCs

  • Nuvoton NuMaker M2L31KI evaluation board is a Cortex-M23 based development board running at 72MHz and targeting IoT applications. (PR #70357)
  • Pin mappings for ST Morpho connector of supported STM32 Nucleo G0 boards have been added with PR #69693.
  • Many new peripherals have been added to the NXP RW612 SoC port, from DMA to Flash driver, counters, I2C, …. (see e.g. PR #70192)

General drivers

There were several interesting improvements around Ethernet support:

  • You can now use Ethernet drivers in “raw” mode (i.e. without building the L2 layer / MAC support). See CONFIG_ETH_DRIVER_RAW_MODE. (PR #70030)
  • It is now possible to do Ethernet MAC address filtering. (PR #69385)

And also:

  • MAX31790 is a 6-Channel PWM Fan RPM Controller. The existing PWM controller driver has been extended to now be a “multi-function device” (MFD) driver that also allows to access the “sensor” side of this IC, i.e retrieve the fan speed and fan fault information for each channel.
  • The new-ish driver for the Pixart PMW3610DM (low-power laser mouse sensor) now exposes more configuration options, ex. to set the resolution, enable “smart mode”, etc.). (PR #70248)

Miscellaneous

  • Zephyr API overview documentation page now indicates the stability level of each API. There are still many instances where the information is missing but surfacing this information will make it easier to improve and clean it up over time. (PR #61994)
  • In order to help not flood logs with log messages that are repetitive, new LOG_WARN_ONCE() macro will write a WARNING level message to the log on the first execution only. (PR #70282)
  • Ahead of the upcoming Zephyr Tech Talk about the new hardware model, some great work was done to explain the terminology inherent to SoCs and boards in the context of Zephyr. (PR #69802)
  • Percepio module has been updated to use TraceRecorder v4.8.2 and DevAlert (DFM) v2.1.0. (PR #68490)
  • POSIX:
    • Added support for pthread_attr_getscope() and pthread_attr_setscope(). (PR#68450)
    • Added support for confstr(). (PR #70274)

A big thank you to the 10 individuals who had their first pull request accepted this week, 💙 🙌: @MarinaKalashina, @Arunmanialagarsamy, @vidarbe, @SamyFrancelet, @su47flying, @grb72t3yde, @ad8sweera, @jgenssler-GiN, @ldaj00, and @eriktamlin.

As always, I very much welcome your thoughts and feedback in the comments below!

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 previous issues of the Zephyr Weekly Update:

Categories
IoT Zephyr

Zephyr Weekly Update – Bring’em new boards and SoCs!

Before diving into this week’s Zephyr updates, here’s your reminder to save the date for our next Zephyr Tech Talk, on April 3. The new hardware model introduced for Zephyr 3.7 is a huge improvement that will allow Zephyr to stay relevant for increasingly complex embedded hardware systems.

Join us to understand the rationale behind this massive overhaul of the legacy model, and bring all the questions you may have, in particular with regards to migrating existing board definitions that you might be maintaining for your own projects.

Boards & SoCs

Now that the new hardware model has been rolled out, there’s quite a few new boards and SoCs that were waiting for it that could finally get merged. See for yourself:

  • The NXP RW SoC series provides highly integrated wireless (Wi-Fi, BLE, and 802.15.4) MCUs, and PR #69943 introduced support for it in Zephyr. The board definition for RW612 has also been added. This chip is typically sold by module manufacturer such as u-blox, Murata, etc. as a standalone, ready-to-use, wireless module.
  • FRDM-MCXN947 is a compact and scalable development board for rapid prototyping of MCX N94 and N54 MCUs. It is now supported in Zephyr. (PR #69890)
  • Starfive VisionFive2 is a high-performance 64-bit RISC-V single board computer (SBC) with an integrated GPU. (PR #69814)
  • ST25DV-DISCOVERY is a demonstration kit to evaluate the features and capabilities of the ST25DV series. Eve Redero contributed support for this board and I highly encourage you to also read the detailed write-up about the whole process. (PR #70010)
  • Numaker M2L31 SoC series is based on an Arm Cortex-M23 core running at up to 72 MHz, 64 to 512 Kb of ReRAM, and 40 to 168 Kb of SRAM. Typical applications include motor control, PC peripherals, battery management systems, etc. (PR #69778)
  • Adafruit 5×5 NeoPixel Grid BFF is a small shield that can stack on top of QT Py or XIAO boards and features 25 NeoPixel LEDs. It is now supported both as a “classic” LED strip, but also as a display controller using the LED matrix driver introduced last week! (PR #67610)
  • Support for DPPIC (Distributed Programmable Peripheral Interconnect Controller) and IPCT ((Interprocessor Communication Transceiver) peripherals has been added for Nordic Semiconductor nRF54H20. (PR #69811)
  • The STM32 SDMMC driver now also supports eMMC. (PR #69836)
  • New generic driver for NXP MCUX FlexIO. (PR #53748)
  • Support for external NOR flash has been added to FANKE FK7B0M1-VBT6. (PR #68442)
  • I2C support has been enabled on STM32H5 boards. (PR #69094)

General drivers

  • HL7800 cellular modem now supports PPP and CMUX, with the Pinnacle 100 DVK and MG100 from Laird Connectivity (now Ezurio!) updated accordingly. (PR #70060)
  • Added support for minimum supported bitrates in CAN drivers. (PR #69533)
  • ESP32 Ethernet driver now supports setting the MAC address at runtime. (PR #69869)
  • Microchip XEC series KSCAN driver has been converted to use the input subsystem and common keyboard matrix library. (PR #65162)
  • STM32 HCI Bluetooth driver now supports raw mode. (PR #69623)
  • New ADC_DT_SPEC_*_BY_NAME() macros allow to get ADC io-channel information from devicetree by name. (PR #68247)

Miscellaneous

  • west flash and west debugserver commands can now be used with the native_sim board. (PR #68835)
  • The network logging (syslog) backend now supports TCP in addition to UDP. (PR #68307)
    • Since the DHCP protocol allows to provide the address of a syslog server as part of the lease (option 7), the new CONFIG_LOG_BACKEND_NET_USE_DHCPV4_OPTION option allows to automatically set the syslog server address when the Log Server option is set by the DHCP server. (PR #69328)
  • Telnet shell backend has been refactored to use the new Socket service library. (PR #69612)
  • Stereo support has been added to the Bluetooh LE audio broadcast sink sample. (PR #69341)
  • “Change Microphone Gain” procedure has been implemeted in the Bluetooth CAP commander. (PR #66748)
  • Bluetooth CAP shell module now properly supports broadcast commands. (PR #68550)
  • New sys_slist_find() method to find an item in a singly linked list without removing it. (PR #66621)
  • POSIX:
    • Added support for getmsg() and getpmsg() (PR #68516)
    • Added a “small” runtime implementation for sysconf() (PR #69882)

A big thank you to the 13 individuals who had their first pull request accepted this week, 💙 🙌: @ene-steven, @KyleKotowick, @poialex, @alpineisle, @krisnaresi, @kurtjd, @nordic-segl, @michalek-no, @GRobertZieba, @sasataku, @kica-z, @grahas, and @marwaiehm-st.

As always, I very much welcome your thoughts and feedback in the comments below!

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 previous issues of the Zephyr Weekly Update:

Categories
IoT Zephyr

Zephyr Weekly Update – New Hardware Model

Howdy! Before diving into this week’s news, I would like to extend an invitation to all of you reading this weekly update to consider submitting a talk for an upcoming Zephyr Tech Talk. As you have probably noticed if you watched previous episodes, these are very informal sessions, so you shouldn’t worry about having to prepare super polished slides (but cool demos are definitely a nice to have!).

If you are a maintainer of a Zephyr area you feel deserves more attention, or simply a Zephyr contributor or enthusiast eager to share insights about a topic you’re passionate about, please propose your idea here!

New Hardware Model

As announced in previous weeks, a new hardware model has been introduced for making it easier to support hardware configurations that were becoming difficult or impossible to describe with the legacy model.

This new model allows to better address multi-core (and sometimes multi-archictecture, too!) SoCs, as well as boards with multiple SoCs.

All the hundreds of boards supported in Zephyr have already been migrated, and what you need to do to migrate your own existing board definitions that you may be maintaining out-of-tree is descibred in the Board porting guide.

We will be having a Zephyr Tech Talk on the topic in just a few weeks, so stay tuned for that!

LED matrices as regular display controllers

I am sure some of you may have a love & hate relationship with Devicetree. It certainly takes some time to get used to the syntax and the sometimes opaque error messages in case of misconfiguration, but it is a super powerful and versatile tool.

This week, a new driver was introduced that I believe really illustrates quite well how one can really decouple their application code from the underlying hardware.

Zephyr already has a generic driver class for LED strips. You will find several drivers in the Zephyr tree (ex. for the popular WS2812 RGB LEDs) that implement the LED strip API and allow to set the colors of all the LEDs in the strip. As you can imagine, on the Devicetree side of things, the configuration of the driver includes things like how many LEDs are in the strip, or which pins/bus should be used to control the strip.

There is also a driver class for all things display controllers. Here, we’re talking about drivers exposing properties for configuring the resolution of the display, which pins to use to transmit pixel data, etc. In most cases, the application developer couldn’t care less about the specifics of the display controller, and they only use the display driver API to effectively put pixels on the screen. In fact, there’s even higher levels of abstraction, like the pre-integration with LVGL, which you’ve heard me talk about many times.

OK, so can you guess where I am going with this? Yep, a new driver now sits kind of in the middle of these two classes of drivers. It’s a display controller driver for LED matrices. Give it a phandle to an led-strip node, and you have your new display ready to rock & roll!

chosen {
    zephyr,display = &led_strip_matrix;
};

led_strip_matrix: led_strip_matrix {
    compatible = "led-strip-matrix";
    status = "okay";
    led-strips = <&led_strip>;
    chain-lengths = <256>;
    width = <16>;
    height = <16>;
    circulative;
    start-from-right;
};

(PR #68614)

Boards & SoCs

  • New MIPI DBI host controller driver for Renesas Smartbond. (PR #68426)
  • New WWDT watchdog driver for Nuvoton Numaker. (PR #68044)
  • New RTC driver for Raspberry Pi RP2040. (PR #64939)
  • nRF54 SoCs have two IP blocks that help with inter-domain signaling and IPC scenarios, namely VEVIF (VPR Event Interface) and BELLBOARD. These two peripherals now have drivers in-tree. (PR #69303).
  • Added support for Renesas Smartbond LCD controller (LCDC) display controller driver. (PR #67649)
  • If you are a user of the M5Stack Core2, you may have noticed that by default, the Grove connectors are not powered. Thanks to PR #67280 you can now control whether the Grove connectors should be powered or not using the bus_5v regulator.

General drivers

  • New cellular model driver for the Nordic nRF91 series. (PR #68981)
  • New flash driver for MRAM (Magnetic Random Access Memory) as found on the new nRF54H20. (PR #69800)
  • You may already be familiar with the regulator-boot-on Devicetree property which allows to ensures a given regulator is enabled when your application start. The new regulator-boot-off property now allows to do the opposite. (PR #69319)
  • New input driver for the Pixart PMW3610DM, a low-power laser mouse sensor. (PR #69722)
  • In the context of #69303, some work has also been done on cleaning up the mbox API (PR #69390)
  • #68776 i2c: RTIO context and some small drivers +1119 -140 (@teburd)

Miscellaneous

  • Support has been added for using QEMU on Windows in Twister. (PR #67595)
  • It’s now possible to set multiple IPv4 netmasks per network interface. (PR #68419)
  • Significant improvements were made to the State Machine Framework (SMF) to better support hierarchical state machines. (PR #66753)
  • LVGL exposes an API for rounding the coordinates of areas to redraw, as this can be needed for some display controllers. The new CONFIG_LV_Z_AREA_X_ALIGNMENT_WIDTH and LV_Z_AREA_Y_ALIGNMENT_WIDTH KConfig options allow to make use of the rounding mechanism when needed. (PR #69410)
  • DTLS sockets now allow to send multiple fragments in the same sendmsg(). (PR #69280)
  • Breaking API change for CAN controllers as part of a rework of the manual bus-off recover. (PR #69460)
  • New POSIX APIs:
    • Support for getting and setting POSIX environment variables has been introduced (environ, getenv(), setenv(), and unsetenv()). (PR #66762)

A big thank you to the 12 individuals who had their first pull request accepted this week, 💙 🙌: @Dermiste, @jthm-ot, @zhaynxp, @jonathonpenix, @cradzik, @ajf58, @Deedone, @pfarwsi, @ChangNice, @glenn-andrews, @sibertdeclercq, and @gangli02.

As always, I very much welcome your thoughts and feedback in the comments below!

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 previous issues of the Zephyr Weekly Update: