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

[droberson]

Hello,

I am currently working through the nRF Connect SDK Intermediate training in preparation for an upcoming project. Said project will require communication between two physically separate processors over UART. Specifically, a nRF91 modem and a nRF52 BLE module.

From my research, it doesn't seem that Zephyr has a drop-in driver to facilitate communication between processors via UART, unless I am overlooking it?

Ideally, it would be as simple as enabling the driver, defining your UART pins, and defining the maximum payload size. The low level hardware and protocol framing would be handled by the driver. The message types and corresponding message payloads would be defined by the developer on the application layer. A callback function would return a pointer to the received payload (message) and payload size. Parsing and processing the message would be left to the application developer.

Does something like this not already exist? I would be surprised if not since it is such a common use case and given that Zephyr is meant to be a plug-and-play OS it seems. For reference, I have created my own version of this on FreeRTOS for the nRF52840.

I have seen SLIP, but this seems to only handle the framing layer.

Edit: If an existing solution does exist , it doesn't necessarily have to be UART based, but could be transport agnostic.

Thanks,

Derek

[AMarch01]

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.

[khelmutlord]

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

[AMarch01]

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.

[droberson]

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.

[droberson]

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

[droberson]

khelmutlord  Any feedback on my additional questions above?

Thanks,

Derek