Does Zephyr have a turnkey / drop-in solution for communicating between two processors via UART?

RE: Does Zephyr have a turnkey / drop-in solution for communicating between two processors via UART?

droberson — Wed, 08 Jan 2025 15:03:59 GMT

Hey Helmut,

I am sure many people would find that useful! My concern with RPC is the overhead though since it seems to spawn a new thread for every message received / processed. See my comments and concerns about RPC above.

In the meantime, I will close those ticket since it doesn't seem a lightweight and robust solution already exists.

Thanks,

Derek

RE: Does Zephyr have a turnkey / drop-in solution for communicating between two processors via UART?

khelmutlord — Fri, 20 Dec 2024 21:58:36 GMT

I'd like to add that I have a pending PR for COBS in upstream Zephyr. https://github.com/zephyrproject-rtos/zephyr/pull/83072 I hope to use this to create a more full featured RPC method as you requested--seems like it would be useful for a lot of people.

Thanks,

Helmut Lord

RE: Does Zephyr have a turnkey / drop-in solution for communicating between two processors via UART?

droberson — Fri, 20 Dec 2024 21:56:28 GMT

Hey Edvin, after reviewing these examples, it looks like you are still required to hook everything together in software. It also looks like the ncs\zephyr\samples\bluetooth\hci_uart sample uses the H:4 HCI transport protocol which has no error checking (CRC for example).

Based on this, it doesn't look like an adequate, robust, and generic drop-in solution with error checking exists for Zephyr in regard to communication between two MCU's using a UART.

I guess I will just write my own modular solution that I can easily port to other Zephyr projects.

RE: Does Zephyr have a turnkey / drop-in solution for communicating between two processors via UART?

droberson — Fri, 20 Dec 2024 18:59:51 GMT

Hey Edvin,

Somehow I overlooked this reply, my apologies. I will take a look at this "connectivity_bridge" example to better understand what framing / transport methods are used.

[quote userid="26071" url="~/f/nordic-q-a/117268/does-zephyr-have-a-turnkey-drop-in-solution-for-communicating-between-two-processors-via-uart/514996"]So are those the two things that you want to communicate with eachother?[/quote]

Yes exactly. The use case you described is what we intend to do. The nRF91 will talk to a Nordic BLE module over UART to provide BLE connectivity for our specific application.

RE: Does Zephyr have a turnkey / drop-in solution for communicating between two processors via UART?

droberson — Thu, 19 Dec 2024 22:08:20 GMT

khelmutlord Any feedback on my additional questions above?

Thanks,

Derek

RE: Does Zephyr have a turnkey / drop-in solution for communicating between two processors via UART?

Edvin — Sat, 14 Dec 2024 22:22:17 GMT

Hello,

I may be a bit late to the party, but you mentioned:

[quote user=""]Specifically, a nRF91 modem and a nRF52 BLE module[/quote]

So are those the two things that you want to communicate with eachother? In that case, there are samples in the nRF Connect SDK (NCS) showing how to do this. I don't know exactly what you intend to do, but if you aim to have the main application running on an nRF91's application core, communicate with the modem core, and use the nRF52 as a BLE device, then we have samples doing this. One of these is the NCS\nrf\applications\connectivity_bridge (particularly meant to be running on an Thingy91). This utilizes the onboard nRF52840 as a BLE device (running the ncs\zephyr\samples\bluetooth\hci_uart sample)

Best regards,

Edvin

RE: Does Zephyr have a turnkey / drop-in solution for communicating between two processors via UART?

droberson — Fri, 13 Dec 2024 23:03:46 GMT

Hey Helmut,

The nRF RPC library looks interesting! After a bit of research, there are a couple things that concern me:

"Events always reserve a new thread from the remote thread pool. Pay special attention when sending multiple events one after another, because each event reserves a new thread. Sending events too fast might consume the entire thread pool and, as a result, block all outgoing commands and events until a thread becomes available in the thread pool."

Source: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/nrf_rpc/doc/architecture.html#threads

A new thread is allocated for each message received? This seems a bit excessive and resource intensive. It also seems like it would force rapid task switching by the OS scheduler when receiving large amounts of data, such as for firmware updates over UART.

For example, in our FreeRTOS UART protocol implementation, we update another processor and its attached OSPI flash with megabytes of firmware images. We essentially slam the UART with as much data as we can at 1 Mbps for firmware updates.

Question 1: Given the above comments, would the nRF RPC library be a good choice for large payloads while achieving relatively high throughput and while maintaining a low RAM footprint?

Question 2: Is the framing layer documented anywhere? Specifically, the synchronization bytes?

I see the RPC packet structure, but nothing about framing / synchronization / packet delimiters.

Source: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/nrf_rpc/doc/protocol_specification.html#nrf_rpc_packet_format

I ask this because we may have a future use case of communicating with an Android/Iphone, and could leverage the same protocol if possible.

Thanks,

Derek

RE: Does Zephyr have a turnkey / drop-in solution for communicating between two processors via UART?

droberson — Fri, 13 Dec 2024 22:54:07 GMT

AMarch01 COBS is interesting after taking a quick look, thanks for sharing! I agree though, it seems like a framing technique similar to SLIP, unless I missed something.

RE: Does Zephyr have a turnkey / drop-in solution for communicating between two processors via UART?

AMarch01 — Fri, 13 Dec 2024 15:58:27 GMT

hmmm, I never thought of it, but yeah, you could use the RPC to send general data arguments back and forth.
I have to keep that in mind.

RE: Does Zephyr have a turnkey / drop-in solution for communicating between two processors via UART?

khelmutlord — Fri, 13 Dec 2024 14:52:14 GMT

Good point on COBS. I used that at my last job for packet framing (is it really packet framing? haha).

We provide the nRF RPC library that may fit what you are looking to do. It is using CBOR in the background:

https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/nrf_rpc/README.html

Thanks,

Helmut Lord

RE: Does Zephyr have a turnkey / drop-in solution for communicating between two processors via UART?

AMarch01 — Fri, 13 Dec 2024 14:48:04 GMT

I don't really have an answer for you. Such a thing is sort of as needed per application. I am not aware of any ready to go serial data transports.
These days I send packets using COBS (yeah, I know ...its a transport thing). I like it because all I have to scan for is zeros in the steam to identify packets. This could easily be set up in a thread with a semaphore indicating that a packet has shown up.
Consistent Overhead Byte Stuffing - Wikipedia

Also, for common serialization of data, there are many ways to go but the nrf library has a CBOR library to help there.
GitHub - NordicSemiconductor/zcbor: Low footprint C/C++ CBOR library and Python tool providing code generation from CDDL descriptions.

No... not really an answer to your question.