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.
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 ?
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.
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.
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.
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?
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.
