Query: eCAL implementation for Microcontrollers

[fialhomatheus]

Hello eCAL team,

I work at a company developing products for scientific instrumentation, where low latency is a strict requirement. We are currently architecting the stack for our next generation of products and considering eCAL. It performed well in our internal benchmarks compared to alternatives, and we liked the development workflow!

Our proposed architecture consists of an Embedded Linux system (ARM) communicating with peripheral boards based on STM32 microcontrollers.

I would like to ask if there is any experimental implementation or roadmap to bring eCAL support to microcontrollers. Specifically, we are looking for a way to extend the eCAL bus to the STM32 peripherals, ideally tunneling the traffic over USB, to maintain a unified communication architecture.

If a native port isn't available, are there recommended patterns or existing gateways for bridging eCAL to embedded MCUs over serial/USB interfaces?

Best regards,
Matheus

[KerstinKeller]

Hi @fialhomatheus,

thanks for reaching out, it's always great to hear back from (potential) users and their usecases, and really glad that you like the development flow.

However, unfortunately, we do have very little experience with microcontrollers, and the workflows you are looking it.
At the moment, eCAL is designed to run on full operating systems (Linux/Windows) and relies on OS features such as shared memory, sockets, and process discovery. Because of this, there is currently no native or experimental port of eCAL targeting bare-metal or RTOS-based microcontrollers like STM32.

In general, the eCAL communication has two layers, the registration layer, and the actual data layer. On the registration layer (data sent via UDP, or if only communication locally over SHM) entities broadcast who they are, where and how they will send / receive data.
This is information is then used to establish the actual communication on a given layer (e.g. SHM file name, TCP port, ...).
One idea could be to reimplement/reuse parts of the underlying protocols.

In general, due to eCALs monitoring capabilities, it's pretty easy to write gateways to receive/forward data, and we often do that to e.g. connect sensors (think camera, radar, lidar) to eCAL Systems. We also have gateways that bridge into other systems, like for example our foxglove gateway. I see this approach to be more promising that actual eCAL support on microcontrollers.

I do not know if it's on your list, but maybe zenoh could be a better fit for you, or means to implement a gateway. They do have a zenoh-pico implementation, where they also list support for different RTOS's.

I hope this answers your question, and please reach out if there is anything else we can help with.

[fialhomatheus]

Hi @KerstinKeller,

Thank you very much for the detailed explanation regarding the microcontroller limitations.

To clarify, running eCAL natively on the MCU is not a hard requirement or a deal-breaker for us, but rather a "nice-to-have" feature we were exploring. We were curious because we see similar implementations in other ecosystems, such as microROS with ROS 2, and wondered if eCAL had something in that vein.

Regarding Zenoh, we have actually evaluated it in our initial benchmarks. However, our latency requirements are quite strict: we are aiming for an average of 50µs (or less) for IPC in our Linux ARM64. In our tests, Zenoh didn't quite meet that target, whereas eCAL performed well.

Given your advice, we will likely experiment with the gateway approach to bridge the STM32 data into the eCAL bus on the Linux host side.

Thanks again for the support!

[cvilas]

@fialhomatheus: Interesting data point about Zenoh vs eCAL. Out of interest, what was the performance difference?

[fialhomatheus]

@cvilas Actually, we didn't test Zenoh directly, since its shared memory API has been marked "unstable". As for tools that involve copy operations, we tested ZeroMQ (160 to 260 µs of avg round trip time depending on payload size) and ROS2 with multiple middlewares (260 to 600 µs). Meanwhile, eCAL managed to get us 85 to 100 µs of average RTT, with a great development flow.

All tests were simple pingpong pub/sub programs, where the publisher and the subscriber were each running on a separate Docker container in a Linux Yocto distro (ARM64).