It is finally here! After 4 months of development, the first release of ZigRouille is out. The following post will go through what we have done so far, and what still has to be done.
Overview
ZigRouille’s goal is to create a safe Rust interface to the ZBOSS stack on nRF52840 chips. ZBOSS is a proprietary library that integrates a ZigBee communications API. The ZigRouille Rust library has to be split in two parts to connect to this API:
zboss-sys, which links the ZBOSS binary and provides bindings to the API entry points.zboss-rs, a higher-level abstraction library to wrap the raw bindings into a new safe API, as well as a Rust implementation of the ZBOSS hardware interface.
To test those libraries, we use a binary crate test-env that also provides a quick-start configuration and several examples using ZigRouille.
Features
The main part of the project resides in zboss-rs: it has a duty to enforce Rust safety rules on the unsafe C API.
Initialization
We enforce at compile time that we have a unique initialization of the ZBOSS stack, and that this stack is configured and started before any other ZBOSS-related code runs.
Memory
The ZBOSS stack holds a buffer pool to perform all ZigBee operations that require memory storage. Those buffers can be requested by the user, or given as a function returns. The buffers do not have an explicit structure in ZBOSS, so we had to structure them explicitly when we use them in the Rust world. Also, the buffers are sometimes required to be explicitly freed by the user, so we enforce that too.
Scheduler
ZBOSS uses serialized callbacks to implement an internal multitasking. We wanted to allow the user to have more variety in the callback types they can use, so we added an extra level of indirection to keep track of the callback requests and responses in the Rust world.
Signals
ZBOSS uses a system of signals to inform the user of some events and allow them to react accordingly. We structured it so that they only have to register individual signal handlers, and implemented a default signal handler (similar to the one Nordic uses).
ZigBee Procedures
Each ZigBee procedure implemented in ZBOSS has its own entry point, so we have to implement them one by one. Therefore, only a small subset off all procedures are currently implemented. We wanted to achieve at least simple light automation for the first release, the other procedures can be added later.
OSIF
The OSIF contains entry points to hardware or OS functions from ZBOSS. For example, the OSIF provides hardware initialization functions called during ZBOSS initialization, or even the code needed to put the device into sleep mode. This OSIF also relies on the radio driver provided by Nordic for the nRF52840 (everything else is written in Rust), that should be linked when building zboss-rs.
What’s next?
The 0.1.0 release is fully functional. However, there still are a lot of features present in ZBOSS that are not yet interfaced with our implementation. In particular, we cannot keep track of some (optional) callbacks given to ZBOSS through special entry points, and we do not handle ZCL callbacks yet. Therefore, it is currently not possible to implement server ZCL clusters e.g. Level Control for a light bulb. Also, ZDO information cannot be retrieved by the user in signal callbacks, a wrapper has to be implemented for that. We would gladly welcome any upcoming contribution! ?