search

eclipse-zenoh / zenoh

zenoh unifies data in motion, data in-use, data at rest and computations. It carefully blends traditional pub/sub with geo-distributed storages, queries and computations, while retaining a level of time and space efficiency that is well beyond any of the mainstream stacks.
https://zenoh.io
Other
1.51k stars 160 forks source link

Zenoh in a SoC #67

Open expploitt opened 3 years ago

expploitt commented 3 years ago

Hello! I discovered Zenoh days ago and I have some questions about it.

I want to use Zenoh in a nRF BLE boards, but I really don't now how to do it. I have to compile Zenoh and use it as a simple library or I have to integrated in some RTO like Zephyr...?

Also, Zenoh works over BLE or it is needed a custom layer to have IP over BLE?

Thanks!

Mallets commented 3 years ago

Hello @expploitt !

For what concerns Zenoh on microcontroller I suggest you to have a look at zenoh-pico here: https://github.com/eclipse-zenoh/zenoh-pico. Zenoh-pico is written in pure C and as such it should be easier to integrate in existing RTO like Zephyr.

Regarding the BLE support, this is not yet implemented in Zenoh but is on our roadmap.

jerry73204 commented 3 years ago

Let me open another topic. Perhaps the zenoh could be moved to no_std? Currently lots of deps need std. Maybe we can gradually replace the types by Vec -> SmallVec, String -> SmallStr and switch to embedded friendly runtime?

Mallets commented 3 years ago

Hello @jerry73204 ,

zenoh is heavily based on async-std to support at best multi-core CPUs and high-throughput traffic. As far as I know, async-std requires a proper std environment to work. Moreover, zenoh comes shipped with some plugins (e.g. to provide a REST API, database backends for storing data, etc.) that leverage external dependencies that do not support no_std. Normally all these features are not expected to run on embedded systems.

For targeting those kind of environments, which mostly have already-available building system for C code, we have created zenoh-pico. zenoh-pico is a pure-C implementation of the zenoh protocol without all the bells and whistles that are not supposed to go into embedded systems. This allows to have a very minimal code surface leading to a compact library.

In any case, the above summarises the situation as of today. Said that, targeting no_std is always a better option because it increases the portability of the code to a wider set of target platforms. Should the future will allow us to provide the same level of features (both in terms of APIs, functionalities, and performance) with no_std, we will be happy to do so.

Mallets commented 3 years ago

I'm gonna close this issue.

As stated above, support for constrained devices is provided by zenoh-pico. The support for Zephyr has been recently added to zenoh-pico via this pull request.

For what concerns BLE support, I've opened a dedicated issue: #79.

asasine commented 5 months ago

With async being significantly more stable in Rust as of 2024 than when this issue was first created, I wonder how much of the original reasons for not supporting no_std remain true. The Rust embedded ecosystem is leaning into async with the introduction of embedded-hal-async, embedded-nal-async (network abstraction layer), and popular projects like embassy. Is it time to reevaluate support for no_std so embedded systems can utilize zenoh directly, without relying on binding to C via zenoh-pico?

Mallets commented 5 months ago

Some part of zenoh already moved to be no_std like protocol definition, buffers, and collections. However, once async comes into play it's very hard, if not unpractical, to write code that is completely agnostic to the async executor. At the moment Zenoh is based on Tokio with an internal architecture that makes use of multiple multi-threaded executors. Having the same behaviour on embassy would require a significant rework of internals.

Long story short, no_std in some part of the Zenoh code has already happened. Unfortunately in Rust, everything related to actual task management and networking is very much dependent on the actual async framework being used.

An embassy-based Zenoh could be potentially implemented by reusing some basic building blocks of no_std Zenoh but not all Zenoh.