1

Hi, we have successfully integrated cyphal with libcanard in several of our products (small satellite radios).

We are now looking into adding cyphal over serial (rs422) as a fallback transport, but we cannot find any working implementation of libserard or any other example.

The only repository with some code is this: GitHub - OpenCyphal-Garage/libserard: A compact implementation of the Cyphal/serial protocol in C for high-integrity real-time embedded systems , but it contains only headers without any implementation.

If a working/beta implementation of libserard is not available, could we implement that ourselves by following the specification ?

We saw that yakut already supports serial transport and we can receive and decode the generated messages, but how do we pass the received frames to the upper layer ? Does exist something like a ‘canardRxAccept’ but for serial ?

Thanks for any input/help on the issue :slight_smile:

1 Like
2

Our very own @coder_kalyan has been working on the implementation in his fork of libserard:

He asked me to provide feedback on his work to eventually merge it into upstream, but I’ve been postponing that for a lack of time – sorry about that. I will pick it up as soon as time permits, but for now, consider using his fork as-is (YMMV). If you happen to have any feedback, feel free to open tickets and send pull requests.

Sorry for the delays.

3

Thanks a lot for the quick reply :slight_smile:

We plan to integrate and test the code next week.

We are happy to try it and give feedback as soon as possible.

1 Like
4

I got it to work for my use case of bridging between an OpenCyphal Can network and yakut on my laptop using a serial connection. I had to tweak one include and add an additional test before assigning an optional parameter in serardRxAccept.

In the spirit of least surprise, I suggest to keep the different transport libraries as aligned as possible and stress differences in the documentation.

Details are documented in https://github.com/coderkalyan/libserard/issues/2

1 Like
5

That’s an interesting use case. Why not use a CAN adapter on your laptop?

6

Hey Pavel, the use case is two fold. First, I don’t have a can adapter yet for the laptop. Second, the serial connection will ultimately be replaced with a radio link.

7

Hi

I noticed that the serial link standard uses a message header of up to 24 bytes. Is this really necessary. And also does not support multi-frame transfer. Is it feasible if using processing logic similar to libcanard?

8

It is possible to shave off a few bytes, but it is believed that the benefit of using consistent headers across different transports outweighs the cost of the extra bytes.

The serial transport does not need multi-frame transfers because there is no MTU limit. One could argue that the disadvantage of this approach is a worse performance in the presence of a priority inversion, where a long low-priority transfer can occupy the channel while a higher-priority transfer is waiting — the significance of this problem scales with MTU — but for the serial transfer we assume that the great simplification offered by the omission of multi-frame transfers outweighs the cost of the priority inversion mode.