Category: IoT

Hi everyone! In case you missed it, the Eclipse Foundation just released the results of their 2023 IoT Developer Survey. It is always a challenge to understand the trends in adoption of open source software as there is no obligation on the adopters’ side to tell when and where they are using open source projects 🙂

This survey is very helpful in shedding some light on the technology stacks people are using in their IoT solutions, and it’s nice to see Zephyr is on their radar.

In other news, here are some of the things that have kept the Zephyr community busy this week!

CoAP “servlets”

When building an IoT device, one typically wants to spend time writing their actual application logic, not reinventing the wheel regarding how they should implement the “Internet” aspect of their “Thing”

A merged pull request from this week, PR #64265, is introducing a CoAP server API that allows to easily register CoAP resources against a CoAP “service”, effectively getting rid of most of the boilerplate one would have to come up with if building on lower layer APIs.

In a nutshell, and in a slightly simplified way, a minimal CoAP server + /hello resource would not require much more code than:

COAP_SERVICE_DEFINE(coap_server, 
			"0.0.0.0",
			&coap_port, 
			COAP_SERVICE_AUTOSTART);

static int my_get(struct coap_resource *resource, struct coap_packet *request,
                  struct sockaddr *addr, socklen_t addr_len)
{
    static const char *msg = "Hello, world!";
    uint8_t data[CONFIG_COAP_SERVER_MESSAGE_SIZE];
    struct coap_packet response;
    
    /** ... **/
    
    coap_packet_append_payload(&response, (uint8_t *)msg, sizeof(msg));

    return coap_resource_send(resource, &response, addr, addr_len);
}


static const char * const my_resource_path[] = { "hello", NULL };
COAP_RESOURCE_DEFINE(my_resource, coap_server, {
    .path = my_resource_path,
    .get = my_get
});

The CoAP service can then be started/stopped using coap_service_start()/coap_service_stop() (in the example above it’s set to start automatically) or using shell commands, and things like the magic ./well-known/core endpoint, retransmissions, etc. are automatically taken care of by the service.

I love it when Zephyr gets new features like this. This new service feels very much like what you would expect to find in a full-blown operating system, and yet we’re still talking about super constrained devices here.

You should definitely check out the code sample to get more familiar with this new API.

Boards & SoCs

• Arm Cortex-A and Cortex-R now support SMP! It is worth noting that FPU_SHARING and USERSPACE are not supported yet. (PR #61206)
• It is now possible to have a custom interrupt control interface implementation on Cortex-M, using the CONFIG_ARM_CUSTOM_INTERRUPT_CONTROLLER option.
  While all Cortex-M platforms have an NVIC controller,custom SoCs may have additional IRQ controllers, or require custom handling. This option allows to indicate that these SoCs are using custom interrupt control interface implementation
• The Firefly ROC-RK3568 mini computer is an ARM64 board with a quad-core Cortex-A55 @ 2GHz, 4GB of LPDDR, 32GB of eMMC, M.2 PCI Express slots, dual Gigabit Ethernet ports, and more. It is now supported in Zephyr! (PR #64217)

• Support has been added for the Lolin S2 Mini (also known as Wemos S2 Mini …and I am realizing as I am typing this that I have one sitting on my desk, and one connected to my electricity meter monitoring the consumption of my house! Guess I need to do some hacking and porting soon!). This small devkit features an ESP32-S2 with 4MB of Flash, 2MB of PSRAM, and can be used with a variety of shields.
• On STM32, the ADC driver now supports power management. A code sample has been added to demonstrate the improvements (spoiler alert: consumption can be almost 20x less now). (PR #64191)
• Clock control driver is now available for Ambiq SoCs. (PR #63097)
• Added support for NXP Multirate Timer peripheral. (PR #64801)

Drivers

• A new Wi-Fi driver is available for the Infineon AIROC, as found in CYW4343W, CYW4373, CYW43012, CYW43012, CYW43439. It is pretty exciting since among other things, it means we should soon see Wi-Fi support added to the Rasperry Pi Pico W. (PR #63721)
  • The already supported CY8CPROTO-062-4343W board now has Wi-Fi functionality enabled.
• The aforementioned Wi-Fi module supports both SPI and SDIO interfaces, and it’s the latter that’s used by the driver for now.
  SDIO is an extension of the SD specification covering I/O functions, and it turns out support for it was also just added to Zephyr. (PR #56869)
• The Analog AD5592 is a versatile multifunction IC that has 8 I/O pins that can be independently configured to act as DAC output, ADC inputs, or regular GPIOs.
  A new “multi-function” driver is now available to leverage all these different options easily from the Devicetree. (PR #64592)
• New Ethernet driver for Microchip LAN8651. (PR #63614)
• New driver for the TSL2561 light sensor. (PR #56869)

Miscellaneous

• A new spinlock mechanism, ticket spinlocks, has been introduced. It is meant to help in situations where traditional locking would be “unfair” across multiple CPUs due to how the implementation only relies on a single atomic variable. Ticket spinlocks provide true FIFO ordering at the cost of slightly increased memory footprint. (PR #61541)
• Some awesome work to implement the official LwM2M interoperability tests, in particular the ones related to bootstrapping, registration, device management and service enablement interface, and information reporting interface. I highly encourage you to have a look as this is also a great way to get up to speed with using Pytest for Zephyr testing 🙂 (PR #64013)
  
  I wonder if the Open Mobile Alliance still organizes PlugFests, but I would live to see Zephyr participate in the future.
• CMSIS version has been updated to 5.9.0 in the Zephyr manifest. (PR #64851)
• API for Bluetooth CAP Commander has been introduced. (PR #64645)

A big thank you to the 7 individuals who had their first pull request accepted this week, 💙 🙌: @cocoeoli, @mgolu, @topisani, @samueltardieu, @p9n, @BenjaminDeuter, and @raffi-g.

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:

Happy Friday! Zephyr now supports GNSS modems, and this is definitely one of the main highlights of this week. I can’t wait to see what kind of applications people will build now that there is a standard, out-of-the-box, way to feed location/navigation info into Zephyr applications.

GNSS Support

The recently introduced modem subsystem added a chat module that allows to pretty much “script” the interactions with a modem.

In the context of cellular modems, it would typically mean dealing with AT commands. This week, a new massive pull request was merged that adds support for GNSS (Global Navigation Satellite System) modems. And, guess what, it too builds on top of the modem subsytem and chat module in particular.

The NMEA 0183 specification standardizes the way GNSS devices output data. Whether it is actual location data, information about the satellites in sight, date/time, … there is a well-defined ASCII representation for it. Below is an example of what you would see if you were to listen to the UART of a GNSS modem:

$GPGSV,8,1,25,21,44,141,47,15,14,049,44,6,31,255,46,3,25,280,44*75

$GPGSV,8,2,25,18,61,057,48,22,68,320,52,27,34,268,47,24,32,076,45*76

$GPGSV,8,3,25,14,51,214,49,19,23,308,46*7E

$GPGSV,8,4,25,51,44,183,49,46,41,169,43,48,36,220,45*47

$GLGSV,8,5,25,82,49,219,52,76,22,051,41,83,37,316,51,67,57,010,51*6C

$GLGSV,8,6,25,77,24,108,44,81,10,181,46,78,1,152,34,66,18,060,45*50

$GLGSV,8,7,25,68,37,284,50*5C

$GBGSV,8,8,25,111,35,221,47,112,4,179,39,114,48,290,48*11

The chat module is therefore a perfect fit to easily hook up the appropriate parsers for each type of NMEA 0183 frame a GNSS module may spit out.

One thing that I really like with this new feature, is that it’s providing much more than the raw infrastructure to “talk” to the GNSS modem. It can effectively–and optionally, should you be too resource-constrained!–parse all the collected data into proper data structures that you can use in your code.

/** GNSS info data structure */
struct gnss_info {
	/** Number of satellites being tracked */
	uint16_t satellites_cnt;
	/** Horizontal dilution of precision in 1/1000 */
	uint16_t hdop;
	/** The fix status */
	enum gnss_fix_status fix_status;
	/** The fix quality */
	enum gnss_fix_quality fix_quality;
};

/** GNSS time data structure */
struct gnss_time {
	/** Hour [0, 23] */
	uint8_t hour;
	/** Minute [0, 59] */
	uint8_t minute;
	/** Millisecond [0, 59999] */
	uint16_t millisecond;
	/** Day of month [1, 31] */
	uint8_t month_day;
	/** Month [1, 12] */
	uint8_t month;
	/** Year [0, 99] */
	uint8_t century_year;
};


/** Navigation data structure */
struct navigation_data {
	/** Latitudal position in nanodegrees (0 to +-180E9) */
	int64_t latitude;
	/** Longitudal position in nanodegrees (0 to +-180E9) */
	int64_t longitude;
	/** Bearing angle in millidegrees (0 to 360E3) */
	uint32_t bearing;
	/** Speed in millimeters per second */
	uint32_t speed;
	/** Altitude in millimeters */
	int32_t altitude;
};

See PR #61073, documentation page, and code sample for more details on this very neat new feature 🙂

Boards & SoCs

It is hard to believe that the first release of the Arduino Uno dates back to 2010! In June of this year, Arduino released the fourth release of the Uno, the Arduino Uno R4.

Where the original Uno was using an 8-bit AVR ATmega328P microcontroller with 32 KB of Flash and a whopping 2 KB of RAM, the Uno R4 is using a 32-bit Arm Cortex-M4 from Renesas (RA4M1) running at 48 MHz, with 256KB of Flash and 32 KB of RAM.

This week, PR #60760 was merged, adding support for the Arduino Uno R4 Minima in Zephyr.

Other boards added this week include:

• The SensorTile.box PRO is to ST Microelectronics what Thingy is to Nordic: a feature-packed devkit built around an impressive amount of sensors: temperature, IMUs, humidity, microphone, etc. It is a great starting point for a wide variety of applications, from wearables to environment sensing. It’s nice to see a dedicated code sample to directly exercise all the sensors. (PR #64039)
• STM32L4R9I-DISCO Discovery kit, which features a Cortex-M4, 640Kb of RAM and 2Mb of Flash, as well as a round 390×390 pixels OLED panel with touch interface. (PR #64514)

Drivers

• Telit ME910G1 Cat M1/NB2 modem is now supported thanks to a first contribution from Jeff Welder! (PR #63711)
• Maxim MAX20335 PMIC is now supported. This PMIC targets low-power wearable applications. (PR #64555)
• New watchdog driver for Infineon XMC4xxx (PR #62954)
• A new GPIO monitor driver is available. It allows to link the on/off status of a power domain to the state of a GPIO (PR #61166)

Miscellaneous

• New shell commands have been added to start, stop and set properties of an Audio Codec device. (PR #57580)
• Regulator API now allows to access the list of current limits supported by a given regulator. It’s also made available through the newly added regulator clist command. (PR #64516)

uart:~$ regulator clist BUCK1
50.000 mA
75.000 mA
100.000 mA
0.125 A
0.150 A
0.175 A
0.200 A
0.225 A
0.250 A
0.275 A
0.300 A
0.325 A
0.350 A
0.375 A

• Ongoing work to refactor keyboard scanning drivers so that common code and configuration can be better shared. (PR #64456)

A big thank you to the 10 individuals who had their first pull request accepted this week, 💙 🙌: @Ayush1325, @LuckeTech, @majunkier, @TomKeddie, @ddeshat, @yangnin, @jeffwelder-ellenbytech, @jrversteegh, @pin-zephyr, and @gbarkadiusz.

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:

Zephyr 3.5 has been out for a week (here’s the announcement blog post if you missed it!), and earlier this week we celebrated the release by having a live stream where many maintainers as well as our release managers Fabio and Johan joined me to discuss some of the additions to 3.5.

Catch up with the recording on YouTube, and consider subscribing to the channel if you haven’t already to be notified of upcoming videos and live streams.

The main development branch is now open again, so it’s time for for this week’s update!

Documentation improvements

• I have said it many times and will say it again: you don’t have to contribute code to help make Zephyr better! Helping us improve our documentation is also highly appreciated 🙂
  
  When browsing docs.zephyrproject.org you now have the opportunity to directly open an issue regarding the documentation page you are currently browsing.
  
  Furthermore, the page footer now indicates the last time someone updated the contents of a page. This can give you a hint about how up-to-date the information you are reading is.

• In an effort to better document all the APIs in Zephyr, a new CI task is generating a documentation coverage report for all the public headers.
  
  All contributors and maintainers are encouraged to look at the report to see if there’s areas where Doxygen comments might be missing. Reports are generated for each pull request (e.g. https://builds.zephyrproject.io/zephyr/pr/12345/api-coverage/) and are also available for main here: https://docs.zephyrproject.org/api-coverage/latest/.

New configdefault Kconfig keyword

In order to make it easier for developers to define custom default values downstream without needing to re-specify dependencies of the symbols they which to “override”, a new configdefault extension to Kconfig allows to do just that.

Jordan Yates, who contributed this extension, shared the following example which I think is pretty self-explanatory:

config MY_COMPANY_APPS
    bool "Apply defaults for internal applications"

configdefault BT
     default y if MY_COMPANY_APPS
configdefault MCUMGR
    default y if MY_COMPANY_APPS && BT

See PR #51316 for more background and details, as well as Zephyr documentation.

west 1.2.0

A new 1.2.0 version of west was released ahead of Zephyr 3.5.0, and I wanted to call out a welcome addition to the list of commands.

west grep allows you to… well… grep for content across your entire workspace. This can be really useful when you want to look for something both in the Zephyr codebase and in the various HALs (or any other module really).

More at https://github.com/zephyrproject-rtos/west/releases/tag/v1.2.0

Boards & SoCs

• The DA14695 Development Kit USB is a low cost development board for DA14695 MCU from Renesas. (PR #60086)
• The DSP core of NXP MIMXRT595-EVK is now supported. (PR #61356)
• The Panasonic PAN1783 evaluation board is a development board for the nRF5340 from Nordic Semiconductor. (PR #63104)

• The MikroElektronika ACCEL 13 Click shield is now supported. It features an IIS2DLPC ultra-low power 3-axis accelerometer sensor in a mikroBUS form factor. (PR #63297)
• Added RTC driver for Atmel SAM series. (PR #63962)
• Added CAN controller driver added for Nuvoton numaker series. (PR #64018)
• Added crypto and RTC drivers for Renesas Smartbond. (PR #60238, #63983)

Drivers

• Several LCD displays from SparkFun expose a so-called SerLCD interface, and there is now an auxiliary display driver available for them. (PR #61445)
• Driver added for MEMSIC MC3419 3-axis accelerometer sensor. (PR #62095)
• Some AMD SoCs feature a temperature sensor that can be accessed using a “Sideband Temperature Sensor Interface” (SB-TSI in short). A new driver has been added with PR #60818.
• The ADXL367 is an ultra-low power, 3-axis accelerometer that consumes only 0.89 μA at a 100 Hz output data rate and 180 nA when in motion-triggered wake-up mode! You will have guessed that it now has a driver, added with PR #63800. 🙂 Note that both SPI and I2C are available.
• Introduced new battery charging properties (ex. “health”, precharge current”, …) and support for the BQ24190 from Texas Instruments. (PR #62551)

Miscellaneous

• In Devicetree, a parent node now “inherits” all dependencies from its child nodes. (PR #62417)
• CoAP library now supports echo and request-tag from RFC9175. (PR #63913)
• The handling of unexpected TCP packets within Zephyr’s TCP stack has been improved. A reset (RST) packet is now sent in response to unexpected TCP packets. (PR #64029)
• Network sockets now leverage the recently introduced “object cores”. You may use the net sockets shell command to access socket information and statistics. (PR #63339)
• IPv4-to-IPv6 mapping is now supported. (PR #63579)

A big thank you to the 24 individuals who had their first pull request accepted since my last post, 💙 🙌: @TomzBench, @karthi012, @marnold-b, @davedesro, @mimbriani, @dennisgr102, @pkoscik, @augustozanellato, @yf13, @Spice-Weasel, @jpmur, @martincalsyn, @nandogalliard, @yeweizy, @mgritz, @pres2300, @photonthunder, @sousapedro596, @FranciszekPin, @Alex-T-Stark, @quic-lingutla, @hlukasz, @arun-mani-tech, and @akaiserUS.

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: