Local, regional and national
government municipalities are introducing stricter environmental laws in order
to fight pollution and global warming.
Waste disposal in particular, has been a top priority for governments
worldwide, with new regulations regarding tracking and proper disposal.
In general,
garbage waste needs to be dumped in a designated disposal site. The common procedure is that dump trucks
arrive at a disposal site such a landfill and are charged per weight and/or
type of waste being dumped. This
conventional way has been the norm for many years.
The above procedure presents a major loophole which is abused to break the law and ends up hurting the environment and increasing pollution. In many cases, a dump-truck driver will dispose of some or all the waste meant for the landfill, in order to save the disposal fee, which they pocket to themselves.
Worldwide
estimates range from 15%-50% (!) of all waste being dumped outside the intended
landfill and ends up in a nature reserve or other illegal sites. This causes extra pollution which increases
environmental cleanup costs and worse, can even be deadly if the waste makes
its way to a water reserve.
The high
cost of enforcement and environmental clean-up have driven governments and
industry to seek out advanced solutions using sensors, location and
communication technologies to fight this trend.
This is a challenge the IoT industry is poised to address.
Two main
challenges of the waste disposal tracking project:
Power management – a standalone,
battery powered device that does not need charging for at least 1 year.
Disposal detection – the unit must
report with close to 100% accuracy that garbage is being disposed in the proper
location in order to not wrongly fine the truck driver.
How
Zephyr RTOS makes this happen:
Processor
power management:
The power
management power state “SYS_PM_LOW_POWER_STATE” proved to be the right
selection for this use case. In this
power state, the device stays on, keeping only the minimum set of needed
components active (shutting down power hungry components such as cellular
modem, GPS, BLE and all sensors) except for the gyroscope.
Driver
power management
Zephyr’s
driver power management structure enables a robust guideline for adding new
drivers, it is relatively easy to add new drivers that follow the basic power
management guidelines. This is critical
for IoT systems since efficient power management plays a key role in many
project go/no-go decisions and the likelihood to get to market quickly and be
commercially successful.
Dual processor support
The mailbox IPC between cores which is a key Zephyr capability, proved to be the project go factor. The small core was used as a DSP, processing the measurements from gyroscope and accelerometer, only when recognizing that garbage disposal is taking place and turning on the more processing-hungrycore which handled the cellular modem, MQTT based data publish, etc.
hereO Core Box
FOTA
support
Zephyr offers great
“out-of-the-box” FOTA support.
On many
embedded projects this task proves to be the most complicated part and is
usually neglected until the end of development and proves to be difficult
introducing additional delays to the project.
With Zephyr
a stable FOTA solution enabled a dependent and secure update mechanism.
Summary
Choosing to
work with the Zephyr solution allowed us to have a stable and flexible design
and development process avoiding development issue associated with typical
embedded development. Zephyr’s many
optional frameworks, work methods, etc., helped speed up time-to-prototype and
time-to-market, especially with customers in the garbage-disposal industry,
which have ever evolving needs. For this
industry, Zephyr is a great enabler.
Today’s rapidly evolving IoT and embedded ecosystem developers have the ability to choose from a variety of platforms and tools to design and build solutions that meet their unique needs and use cases. Zephyr Project is proud to provide developers and product makers with the freedom and flexibility of a full featured, customizable open source RTOS for resource constrained devices. That freedom includes empowering developers by providing a growing and diverse selection of supported architectures, boards and configurations. As of Zephyr 1.14 LTS, the RTOS had more than 160 supported board configurations on 8 architectures, including RISC-V.
Guided by the same ethos, the RISC-V Foundation and its members have built a thriving ecosystem and helped to spur a new generation of innovative tools, software and hardware built around a free and open Instruction Set Architecture. The shared vision and deep commitment to open source has led to fruitful collaborations across the two projects. In the years since collaboration began, both projects have grown and reached important milestones.
Today, we are excited to share a new resource intended to help members of both communities quickly get started using Zephyr OS on the RISC-V architecture. Created by Zephyr Project and RISC-V Foundation member Antmicro, The RISC-V Getting Started Guide showcases the strength of both platforms used together to create end to end open source solutions.
“Confirming our commitment to bringing open source into ever new technology areas, Antmicro has led the efforts to produce a RISC-V Getting Started Guide that is primarily addressed to software developers. Choosing Linux and Zephyr RTOS is crucial as their community-driven and vendor-neutral nature corresponds well with that of RISC-V,” said Michael Gielda, VP Business Development at Antmicro.
”Having clear concise reference documentation makes it easier for newcomers to the RISC-V and Zephyr communities to create products faster. We’re excited to see what developers create using this guide and look forward to continued close collaboration between our organizations,” said Kate Stewart, Senior Director of Strategic Program at the Linux Foundation.
The RISC-V Getting Started Guide shows users how to get started developing for the free and open RISC-V ISA, both in simulation and on physical implementations. The Guide focuses on running standard operating systems – Zephyr and Linux – on popular RISC-V platforms with minimum effort. The Zephyr-enabled platforms currently described in the Getting Started Guide include the SiFive HiFive1 and RISC-V SoftCPU Contest winner LiteX SoC with VexRiscv CPU running on the Future Electronics Avalanche board with a Microsemi PolarFire FPGA or in Antmicro’s open source Renode simulation framework. The Guide also provides a generic QEMU simulation target supporting RISC-V.
Thanks to Antmicro and the RISC-V Foundation, the Guide is now available to serve as a starting-point for the global RISC-V and Zephyr communities, as well as anyone interested in switching to a fully open design approach – from open ISA through open tooling, software, hardware and FPGA.
This guide is an open source collaboration and contributions are welcome via GitHub. If you have questions about using the Guide or Zephyr OS, please contact us via the Zephyr Project Slack channel. What’s more, Antmicro, SiFive and Microchip are sponsoring the upcoming RISC-V Workshop in Zurich – you can find them on the showfloor to receive more information on getting started with Zephyr on RISC-V.
Written by Marti Bolivar, Zephyr Project contributor and Senior SW Engineer at Nordic Semiconductor
This newsletter tracks the latest Zephyr development merged into the mainline tree on GitHub. In particular, we’re covering the first 1,001 patches merged since the v1.14.0 release last month. Buckle up.
Highlights
This newsletter covers the following inclusive commit range:
f90acbf2 release: Post-release patch level update, merged 16 April 2019
ba4eae14 tests: test_sched_timeslice_reset: Fix slice time measurement, merged 23 May 2019
Architecture-specific
New SoC support:
LiteX: VexRiscV
Microchip: MEC1501
Nordic: nRF52811
NXP: i.MX RT1015, Kinetis KE1xF
ST: STM32F415RG, STM32MP1, STM32WB, STM32L1
TI: CC13x2 / CC26x2
The ARC architecture can now be configured to dump human-readable exception information on faults.
On Arm:
Multiple threads can now share floating point peripherals, as FP registers can be saved and restored on context switch.
The presence of the SysTick timer peripheral has been decoupled from the peripheral which is configured as the system timer. This allows Arm SoCs to use other peripherals as their system timers. This involved adding a new CONFIG_CORTEX_M_SYSTICK to request that SysTick be used, and renaming the macro which merely signals the presence of a SysTick peripheral from CONFIG_CPU_HAS_SYSTICK to CONFIG_CPU_CORTEX_M_HAS_SYSTICK.
Support was added for the varying number of MPU regions on some Cortex-M7 SoCs. As part of these changes, the device tree now declares the number of regions.
Device tree support was added for some Armv8-M SoCs.
Support for various peripherals was added at SoC level; see the patch list below for details.
The contents of the .rodata sections were made read-only on x86.
Bluetooth
The majority of changes (approximately half by patch count) are at the controller level, including:
Support for out of tree vendor-defined HCI commands, vendor-specific events, and proprietary RX demuxing.
Increasing feature parity between the new ULL/LLL “split” link layer architecture and the existing default L2, and continued efforts making the new code vendor-agnostic by moving Nordic-specific code into vendor LLLs.
The Bluetooth shell now has gatt get and gatt set commands for reading and writing local attributes.
There is now a CONFIG_BT_GATT_DYNAMIC_DB option, which can be used to decrease memory usage by disabling runtime service updates.
Wistron WNC-M14A2A modem: see boards/shields/wnc_m14a2a
SparkFun u-blox SARA-R4: see boards/shields//sparkfun_sara_r4
Various boards gained new software support for peripherals; see the patch list below for details.
Other miscellaneous feature enablement: pyocd flash and debug support for mimxrt1060_evk and mimxrt1064_evk, JLink flash and debug support for STM32 boards and efr32_slwstk6061a.
Build System
Efforts continue to generalize the build system to support non-GCC toolchains:
The native_posix build configuration now supports LLVM.
GCC-specific compiler and linker flags continue to be replaced with toolchain-agnostic “Intents”. These intents are CMake functions or macros beginning with toolchain_ which express a desire for a toolchain to be configured in a certain way, e.g. to configure a certain level of warnings. Search the source code for @Intent for examples.
A new LINKER CMake variable was added to decouple the linker from the compiler. The initial purpose appears to be adding lld support, but for now, GNU ld remains the only supported in-tree linker.
The ultimate goal remains not only supporting LLVM and other non-GCC based toolchains in-tree, but providing first-class support for out of tree toolchains.
Support for out of tree device tree source files and bindings was added via a new DTS_ROOT CMake variable. This is analogous to the existing BOARD_ROOT and SOC_ROOT variables, which allow defining out of tree boards and SoCs.
The giant SoC level linker scripts (in subdirectories of include/arch/ and named linker.ld) are being cleaned up and refactored with the help of a new zephyr_linker_sources() and related set of CMake functions. As a result, some Kconfig options, like CONFIG_SOC_RODATA_LD, CONFIG_SOC_NOINIT_LD, and others are now deprecated in favor of using that routine to manage what content is added to the final linker script.
An application’s build version can now be set via the BUILD_VERSION environment variable.
Zephyr can now be compiled with the newlib-nano C library shipped with the GNU Arm Embedded toolchain (which was already supported by Zephyr).
STM32-based boards can now produce Intel HEX files as build artifacts.
Continuous Integration
An indomitable effort to clean up and clarify the sanitycheck script’s output, help strings, and other UI related improvements is underway.
Documentation
Among the usual stream of improvements, new docs have been added covering:
Zephyr has imported the Linux kernel’s list of device tree vendor prefixes as dts/bindings/vendor-prefixes.txt. Developers are encouraged to respect (and maintain) its contents when adding compatible properties.
New and shiny:
AMS ENS210 temperature and relative humidity sensor, indoor air quality sensor drivers
Atmel SAM0 ADC, hwinfo, I2C, and DMAC drivers, along with asynchronous DMA support for the SPI driver and interrupt support in the GPIO driver
Holtek HT16K33 LED and GPIO drivers
Microchip MEC GPIO and I2C drivers
MCP2515 CAN controller support
nRF RTC drivers now support error-free wrapping via PPI; see CONFIG_COUNTER_RTC{0,1,2}_PPI_WRAP
NS16550 UART driver support for PCIe
NXP EHCI USB driver
RV32M1: I2C support
STM32L1: clock, interrupt, pinmux, GPIO, I2C
STM32L4: SPI2 on port B support
STM32WB: clock, interrupt, pinmux, LPUSART
STM32 ADC drivers support pin remapping and ADC1 instances
STM32’s serial driver now supports RTS/CTS hardware flow control and 9 bit data frames
STM32’s usb_dc_stm32 driver now supports pin remap via device tree; search for the enable-pin-remap property binding documentation for details
Stereo support in the mpxxdtyy audio driver, whose name reminds the author of calculus class
TI CC13xx / CC26xx I2C driver
TI SimpleLink WiFi now supports static IP address configuration
The CAN API grew user data pointers on callbacks, along with other rework and loopback driver support. The driver file names themselves were all prefixed with can_.
The flash_map.h API now has a flash_area_foreach() routine for visiting each flash area. It also has a shell command using it, which currently supports a list command. There’s also a new flash_simulator driver, which implements the flash API but backed by RAM. This is useful for testing, and is now enabled on the qemu_x86 target.
The IEEE 802.15.4 driver API in include/net/ieee802154_radio.h has a new struct ieee802154_config defined, which can be passed to a new configure callback in the driver API. The initial use case is ACK configuration on nRF5 SoCs.
The UART API now supports 9-bit data; apparently, 8 wasn’t enough for everyone. The only initial user is STM32, as described above.
Firmware Update
Various potentially breaking changes are getting merged for firmware update support on Arm v8-M SoCs with secure and non-secure application images. Stay frosty out there, DFUsers.
Kernel
A handful of fixes, new APIs, and refactorings were merged.
However, a debate is quietly taking place behind the scenes which may result in a significant refactoring of the kernel’s system timer APIs. Stay tuned for more.
Miscellaneous
The logging subsystem can now be used from C++ files.
The “minimal” C library included with zephyr continues to grow, adding definitions for bsearch(), exit(), _exit(),time_t,suseconds_t, and a <sys/_timeval.h>.
Numerous additions were made to the CODEOWNERS file now that pull requests which add new files not covered there are rejected by CI. However, the Technical Steering Committee has ruled that this file does not, despite its name, define which developers are the maintainers of any given subsystem or area of the tree. More documentation and discussion on this is ongoing.
The shell subsystem now has a generic hexdump routine, shell_hexdump(), declared in <shell/shell.h>. It also gained a variety of new macros for conditionally defining and initializing commands; see Creating commands in the documentation for details. There’s a new set of config options beginning with CONFIG_SHELL_PROMPT_ which allow different shell backends to proudly declare themselves as uart:~$, rtt:~$, etc.
Rather than relying on GCC builtins, there is now a <misc/math_extras.h> header which provides portable arithmetic and bit manipulation routines. Naturally, existing users have been moved over, and there is a GCC implementation.
The statistics API can now track more than 256 individual statistics. This sounds like a silly thing to say, but it makes sense; believe us.
Modules
Now that the west tool has been merged and integrated into the core workflow, a series of pull requests is up extracting third-party code from the main zephyr repository into separate Git repositories. The first one merged extracted the Intel QMSI library. Make sure to run west update to fetch this separate repository after pulling zephyr, and to keep doing so whenever you pull.
Networking
A variety of fixes are flowing in from testing with the Maxwell Pro suite and other testing efforts.
The <net/net_if.h> API gained accessors for manipulating network interface flags: net_if_flag_set(), net_if_flag_test_and_set(), net_if_flag_clear(), and net_if_flag_is_set(). A new flag, NET_IF_NO_AUTO_START, was also added which disables automatically bringing the interface up if set. There’s also a newnet_if_ipv4_get_global_addr() routine, which is used to return an interface’s global address if nothing else can be found. The existing but unused net_if_ipv6_get_global_addr() was altered to match the signature for the IPv4 version as well; out of tree users will need updates.
The <net/sntp.h> header now has a query function with fractional seconds precision, sntp_query(). The older sntp_request() routine is now deprecated. A new sntp_simple() routine for one-shot SNTP queries was also added to this header.
ICMP echo packets can now contain arbitrary payload data, and the net shell’s ping can now report RTT, TTL, and RSSI.
Ethernet controllers which wish to strip the VLAN tag from received frames can now do so; see the ETHERNET_HW_VLAN_TAG_STRIP flag. This capability is now printed in the ethernet shell.
The OpenThread frame pending API is now implemented.
Bluetooth IPSP devices now support multiple connections. CONFIG_NET_IF_MAX_IPV6_COUNT now defaults to CONFIG_BT_MAX_CONN in that case.
A new routine, mqtt_read_publish_payload_blocking(), was added. It allows reading the payload of a publish message.
It’s now possible to compile out Zephyr’s IP stacks when only offloaded socket support is required, saving memory.
A new <net/socketutils.h> header was added, providing address manipulation functions.
It’s now possible to register new socket families with the core networking APIs. See struct net_socket_register, NET_SOCKET_GET_NAME(), andNET_SOCKET_REGISTER() in <net/socket.h>. The TLS, AF_PACKET, and AF_CAN socket address families now use this mechanism.
Zephyr’s getaddrinfo() implementation now supports a null host argument. A userspace-aware getsockname()implementation was also added.
A new CONFIG_NET_IPV4_ACCEPT_ZERO_BROADCAST allows Zephyr to accept UDP packets destined for the all-zero multicast address.
Storage
The settings subsystem for nonvolatile storage now supports custom backends. This is a significant improvement, which allows customized abstractions for the representation of data at rest. See the documentation for the new settings_backend_init()routine for details. FCB and file system backends are supported, along with other changes in <settings/settings.h>.
Tools and Scripts
The menuconfig build system target saw various usability improvements by pulling in a new Kconfiglib.
The west build command now supports:
a build.board configuration variable, which can be used to set the default board to target
a build.pristine configuration variable and --pristine option, for controlling when the build directory is cleared out before a new build is started
a --cmake-only option, to generate a build system but not build anything
verbose builds (i.e. builds which print the compile commands) at level 1 verbosity (i.e. when called as west -v build)
a build.generator option for setting the default CMake generator
a --dry-run flag for printing what it would have run, without actually executing cmake or running any build system targets
a --build-opt option for passing tools to the underlying build tool (such as ninja)
There is a new west boards command, which can print information about supported boards.
This blog post is written by Giuliano Franchetto, CTO of Intellinium and was originally featured on the Intellinium website.
Today, everything gets more and more complicated. This is of course true for embedded electronics design, both on software and hardware side. More complex boards will be more likely to fail at some point, and a more complex firmware will be more prone to bugs and side effects.
We’ve all had a “I added a simple line of code at the start of my code, and it now fails at the most random place” moment (and let’s be honest, this is not the funniest part of being an embedded engineer). Even if it costs more at the first place, dividing software and hardware functionalities is one of the most effective ways to tackle this problem, and save money in the long run.
So, let’s talk how Zephyr OS can be very efficient on this subject, and use multiple Zephyrs to create a hurricane and to build the best connected worker smart PPE!
Zephyr 1.12 and onwards now supports Asymmetric MultiProcessing (AMP), helping designers to remotely call functions running on another core. In that way, the designer can now choose to divide its code, and host only some parts of the functionality in a single core and use AMP to call the other set of functionalities remotely. The code becomes lighter, faster, predictable and way easier to upgrade later. Another very interesting part is that we can now port software principles easily using multiple core + AMP.
Let’s take our use case at INTELLINIUM, where we have been developing a safety pod (plug-in) to transform traditional leather-based safety shoes into smart and connected safety shoes, a life-saving product that shall work at all time and in all conditions.
The multiple cores + AMP architecture enables the use of the “SOLID” software principle, very famous among Java developers. The SOLID principle is a “Single Responsibility Principle”, or more trivially “just do what you are meant to do and do it well”. In our case, we must manage critical messages, answer a user’s distress call, but also read various sensors or manage a LED. The priority of all functionalities is of course very different, and even if Zephyr manages thread priority, we are polluting life critical processes with “cosmetic” ones. Aware of this potential problem, we chose to add a small M0 MCU from ST, whose job is to manage all the sensors and actuators of our product. That way, our main MCU (a nRF52840 from Nordic Semiconductors) can focus on its “Single Responsibility”, taking care of its user.
Another very powerful possibility is to separate the communication processing power from the main core. That’s why we chose the new nRF9160 from Nordic Semiconductor as our LTE modem, as they were brilliant enough to embed an independent Cortex M33core inside their own component, hosting all our communication related code. No more AT commands parsing with huge static buffers in our main program, no more SIM management nor HTTP packets building. Everything is done is the M33 core, dedicated to communicating with the base modem. And of course, AMP is used between the nRF52840 and the nRF9160 to send or receive messages from example.
I hope that this small talk showed you how powerful can multi-processor be, and not only for pure computing power, but to make firmware development easier, more scalable, and safer. It may cost you a few bucks more when producing your own board, but trust me, you will save dozens if not more on the long run. I’m out of time right now, but I’d just to mention that adding multiple cores can also save energy, thus increasing your product life time. But that will be another talk. Happy coding!
You can join the conversation or ask questions about Zephyr on the Zephyr Slack channel or Mailing List.
