-
Notifications
You must be signed in to change notification settings - Fork 140
Zenoh For Microcontrollers
You are reading the old and no longer maintained zenoh wiki.
More recent information can be found on the zenoh website.
When we started the design of zenoh, one of the goal that we had set for us was to come up with a protocol that could run essentially on anything. Where by anything we meant that we wanted to be able to run this protocol to interconnect anything ranging from a server to an extremely constrained devices, such as an 8 bit micro-controller connected over low bandwidth/power network. Thus the first step was to design a protocol with a minimal wire-overhead -- zenoh has 4 bytes minimal wire overhead -- that would scale nicely without putting pressure on small devices. Once designed the protocol clearly we wanted to see how far we could get -- so we wrote zenoh-helium (zhe).
zhe showed that we could get the full peer-to-peer protocol running on a 8-bit Atmel micro controller. The code still works so you can try it out to see it with your eyes. That said, zhe does not implement certain of the later features that were added in zenoh such as queriables. Thus if you want to run the current version of zenoh on a constrained environment the suggested path is to use zenoh-c.
zenoh-c provides access to the full set of zenoh primitives and is easy to port to embedded OS since it nicely isolates the use of OS-specific primitives.
Change is the only constant in life. Not sure if you realise, technically we change at every single breath, incredible isn't it. Thus change has been the natural course of action in zenoh. In the last year we have learned a lot from early deployments, tests and industrial collaborations and as a consequence our protocol has also evolved.
As we are close to finalise the new version or zenoh, which beside to some nice improvements at a protocol level includes a full rewrite in Rust we are also about to evolve our approach to embedded targets.
The new version of zenoh is written in Rust and exposes C-APIs through the zenoh-ffi crate. As a consequence this already allows to support all embedded platforms that support Rust-std see here for both C and Rust programmers -- all of this without doing anything special
The question is now what to do for platforms that do not support Rust std, in other terms what to do for those environment that either support Rust no_std or that do not support Rust at all?
To target these environments, we have decided to keep zenoh-c and evolve it to support the new version of the protocol along with a few more aspects relevant for extremely constrained environments, such as the ability to reference resource mapping while opening a session. This allows a small client to avoid any resource, publisher or subscriber declaration, thus further reducing the bandwidth and battery usage.
To make it clear that zenoh-c is no more just the C client for zenoh, we'll rename it into zenoh-pico