Golioth
Webinar Date: June 13, 2024
Leveraging Zephyr to enable super-flexible IoT designs
One design, many chipset targets
This post covers Key Takeaways and Frequently Asked Questions from the Golioth Leveraging Zephyr to Enable Super-Flexible IoT Designs webinar regarding designing one product that can target many chipsets such as various microcontrollers while implementing connectivity and sensors from various manufacturers. Whether you’re a seasoned professional or a curious newcomer, you’ll find plenty of valuable information watching the webinar. Links to the Webinar, Resources, and Related Content are provided within the post. A copy of the PowerPoint presentation will be provided for customers that register to watch the recorded webinar. All Snippets and Content Compliments of Golioth.
Golioth is an IoT platform that provides cloud services for embedded devices. We think of our platform as a “universal connector”. Golioth is purpose-built for you and the hardware you develop. Golioth enables everything that your devices need from the cloud, from establishing secure connections and providing over-the-air updates, to managing data to/from your fleet and connecting that to any cloud service you may need.
What if you wanted to design a single product that could target NXP, Nordic, or ST microcontrollers? What if you wanted to add connectivity from Espressif, Infineon, or Quectel? What if you wanted to implement over 150+ sensors from vendors across the DigiKey catalog with built-in drivers?
Hardware and firmware engineers need to know how to design in a wide range of components. Zephyr is an open source RTOS and Ecosystem that makes it possible to utilize the same code to target different vendor chipsets, different connectivity types, and different sensors. Paired with Golioth’s powerful SDK and cloud capability, you’re ready to design connected (IoT) devices that are resilient to shortages and implement unique capabilities for your end customers.
Our users find that Zephyr RTOS provides maximum hardware control and flexibility for their client or company projects. After getting started quickly, users will learn how to properly set up a Zephyr project and be ready to deploy a professional project.
Golioth makes it easy to interact with your IoT devices and their data. This REST API training module will familiarize you with how devices are represented in the cloud. You’ll learn how monitor and control your fleet, and access the time-series and stateful data being collected from it.
In addition to this self-guided website, Golioth offers free Zephyr training every month! Sign up now for our next session to get up to speed on the basics of Zephyr RTOS with Golioth engineers. This live training is held via a video conference platform and offers a guided version of the training found on this website.
Key Takeaways
- The basics of Zephyr RTOS and how to get started designing quickly
- How one code base can serve designs from 3 different microcontroller vendors with 3 different types of connectivity!
- How to utilize Cloud services to deliver interesting features to a product with a single SDK install
- How Golioth’s end-to-end Reference Designs can jumpstart your own IoT designs
- Zephyr is both a Real Time Operating System (RTOS) and an Ecosystem
- Golioth cloud services offer Over-The-Air (OTA) updates, remote logging, time-series and stateful databases, device/fleet settings service, remote procedure calls, provisioning & certificates and output streams
- Access data and control devices from the Golioth Cloud, Amazon AWS, Google Cloud Platform (GCP), Microsoft Azure, REST API/WebSockets and more
Frequently Asked Questions
How well does Zephyr support deep power-saving functionality across different hardware platforms?
- Zephyr has a power management subsystem (PM) that has pretty good support. It’s up to each module (SoC, sensor driver, etc.) to implement it, so it’s good to verify that everything you’re using has it. But it works quite well.
How well does Zephyr support deep power saving functionality across different hardware platforms?
- There is a power management sub-system built into Zephyr and it works incredibly well in several different ways you can define your own levels of power savings, and you can switch them to meet the needs of your applications they are implemented onto each different module of Zephyr the SoC definition has its own power management; each sensor driver has its own power management. Everything used in Zephyr has its own power management implementation. As you move towards production make sure you look at each thing you are using and if it has it implemented, but beyond that it works well as it is holistic yet targetable.
Seeing the Golioth boards brought insta project via its manifest is great. How would you go about the same for boards or drivers that are not open source instead in a private organization repository such as GitHub for example is it fundamentally different?
- We actually maintain our own, we have a repository called Golioth Zephyr board, it’s basically some of the customer hardware you saw in the reference designs. That is just then pulled into the manifest. So, you can do the same thing as long as your build systems have access to repos so you have an SNH key or if it was open to the public such as having the HTTPS then you’d be able to pull that in and be part of the system. Even if its private repos since your GitHub user would have access to that private repo, you’d be able to do less updates and pull in private repositories like that the only sticky place is if you are doing continuous integration you may have to have a key or token in order to pull that repository. During development I’ve definitely used private repositories and doesn’t feel any different than public repositories.
How does Zephyr handle reading temperature values from various sensors located on different boards. Specifically interested in understanding the sampling of how the sampling rates for different ICs are managed within the Zephyr framework, how does Zephyr ensure synchronized and accurate sampling across different sensors with potentially varying sample rates?
- If you have two different chips and let’s say two different ADC’s that you are using on two different slaves of your product then they might have different parameters that they are using such as ADC’s are configured differently from different manufacturers, all of that is handled in the device tree layer so the driver will have certain device tree elements that it requires to be specified by the user, once you have the setup for that chip that handles everything during the initialization and API calls, the abstraction layer is more on an API level, so each driver implements an API, for instance the temperature sensors all the implement is for a sensor fetch where you can fetch all the values or target specific values and the driver level handles everything else after that so as long as you have the sample rates set up in the device tree definition for that part it should behave as it would as if you weren’t using the abstraction layer.
The demonstration was in C, do you ever use C++ when you work with Zephyr and Golioth? Is it feasible and possible to make a fully C++ application?
- Yes* with an Asterisk. Your user code can be C++ - Zephyr definitely supports that. Zephyr itself is written in C so the underlying build for the RTOS itself is going to be C but they should play together without issues I know that they both are well supported. If you start with C, it is good to dive under the hood first. Golioth client for Golioth IoT stack supports applications written in both C and C++.
How does Golioth devices server communication work bandwidth limited connections, for example an IoT device using thread and ITE6?
- We actually have a bunch of really good demo code using thread, that was one of the earliest things we do as it works really well as our backend is co-app as the end point so that is actually what thread is also using so generally in an IPB6 like thread system it may be a little bit slower and little more bandwidth constraint things like that but for example if your sending an OTA update you’re sending blocks of a kilo byte at a time so as long as that kilo byte goes through you can increment to the next one and increment to the next one, it is sort of built and setup for that sort of thing. Broadly, some of that will come down the application side code as well so one of the reference designs showed is Mike implemented caching on the device side, so that was able to capture DPS data cache it all locally and send it all at once. All of our customers have concern about bandwidth and also things like battery life and cellular data usage and so the underlying Golioth platform itself is that stuff is always in our mind that we are sending the leanest most bandwidth friendly package as possible and also built into it the ability to change how often to keep a live signal is sent just through simple configuration. As far as at the application level its really up to you as far as how many things you want to be built in, how often the radio is on, but all of that is configurable, hopefully that helps answer.
How much does this flexibility cost in terms of RAM and flash?
- It is hard to be objective in answering that, as RAM and flash vs. what exactly? As far as how much flexibility costs, the flexibility is all there as you have the ability to turn on or off libraries as you build and that will save both flash and RAM. For instance, if I turn off a library it’s not going to allocate a stack and it’s not going to build the function calls into that. Chris and I recently ran out of flash on one of our designs and we started looking at it and there was a lot of stuff turned on by default that were not even used. We use the shells all the time for prototyping but certainly don’t need to be in a production device. The bigger thing is being aware of whats going into the build and really looking at the K config files that shows each library that has gone into it that is pretty important. You are able to print out both ROM and a RAM report. Zephyr docs are fantastic, we highly recommend those and there is an optimization page there when you are trying to get your memory down. ROM report basically does a tree level view of all the things compiled, it provides the visibility to not only visualize what is there but also the ability to turn things on and off.
Webinar Links and Resources
Webinar Registration Link:
DigiKey Webinar Center:
DigiKey TechForum Webinar Posts:
Supplier Center & Service Offerings:
Resources:
Example Webinar Slides
-Much more in-depth slides and a copy of the PowerPoint presentation will be provided for customers that register to watch the recorded webinar.
