Libcanard for UAVCAN/CAN v1 is released

That’s great news! Congratulations for the awesome work.

I have noticed that the drivers have disappeared, do you plan to move them to a separate repo?


Yeah. I just updated the README to make it clearer. The new place is here:

As of right now, it is quite empty, so please navigate to the branch legacy-v0 – the code there is intended for the old version of the library but the changes necessary for its adaptation for the new Libcanard are quite minimal. I am going to migrate the driver for STM32 and SocketCAN in the short order. Speaking of SocketCAN, it’s going to be available for NuttX soon as well: SocketCAN API on a RTOS.

1 Like

11 posts were split to a new topic: Libcanard usage questions

Is there a particular reason why canardRxAccept and rxSessionUpdate does not return the error codes which are the cause of the problem while in the code the cause is clear?

For example:

canard.c:1054 out = 0;  // No matching subscription.
canard.c:1059 out = 0;  // Mis-addressed frame (normally it should be filtered out by the hardware).
canard.c:1064 out = 0;  // A non-UAVCAN/CAN input frame.
canard.c:835 if (correct_transport && correct_toggle && correct_tid)

Because the states you mentioned are not errors.

You can use any CAN hardware. Our libraries are platform-agnostic.

There used to be a demo that with some effort could be compiled and executed. Is an akin demo that will work with v1? Will it be included as part of the socketcan tests?

Hi Hugo! There is no such thing at the moment, but we would welcome it emphatically if one created it independently (in a separate repo). At the moment all we have to offer in this sense is:

hey… I have created two example node repos (url upon request since the url might change). One node just listens to the heartbeat while another only produces a heatbeat. Next step for me is to create a template repo of a basic node project for vscode with the idea of slowly adding code to implement different sections of Chapter 5 of the UAVCAN Specification. I would like to petition that the code be part of the UAVCAN repo? If not I will be happy to host it at github. Please advise.

Great stuff, Hugo. I’ve looked at and and it seems promising.

Our general unspoken policy was to keep only the core software components under the UAVCAN repo: implementation libraries, DSDL, the spec, core tools, the website, and such. We cut down even on the platform-specific drivers, removing the multiple repos and dumping everything into one place to keep the organization well-focused on the things of primary importance instead of some hardware-specific nuance. The story of examples is identical to that: we have separate v0 demos maintained by third parties (if you search the Web you will find many) but none by the dev team. I am inclined to keep it this way.

However, this is suboptimal in the sense of discoverability: unless you advertise your examples feverishly, people may fail to find them, and nobody would benefit. So I suggest that we set up a sticked wiki-post on this forum (in this very category because your demos are libcanard-based) that any regular visitor could edit to keep it up-to-date with links to existing demos, unofficial tutorials, and similar useful things out there. If you are okay with that, please go ahead and kickstart that wiki post here.

I think @aentinger and @TSC21 should be aware of this discussion.

1 Like

Good morning :wave: :coffee:

Great work :rocket: Easy compilable and executable examples will make it easier for any novice to tip their toes into UAVCAN development. Therefore I heartily endorse Pavel’s suggestion of setting up a sticky post gathering relevant code examples.

I believe 107-Arduino-UAVCAN, an Arduino library providing an abstract and simple to use UAVCAN interface, might also be a relevant entry to that example page. I’m not sure if you got to open such a page yet, since @pavel.kirienko is most familiar with this forum and it’s configuration I’d ask him to setup the page which then we can fill with content.

Cheers, Alex


Here is the new topic to help us learn and teach:

1 Like

Thank you :wink: I shall proceed to add a suitable post immediately.

Thanks Hugo. I took the liberty to rename the topic into “Libcanard: Examples, Starters, Tutorials”, otherwise it looks ambiguous on the front page.

Are you going to add your examples there soon?

I will add them by the end of the week. Currently working on the platform-specific component(PSC) for Arduino AVR. I already have an .ino sending a heartbeat (turning on the LED too) using a timer interrupt on an Arduino Mega. . Going to use the " MCP_CAN Library for Arduino" by Corey Fowler (unless someone has a better suggestion?) in combination with code from the libcanard/socketcan PSC to produce a basic libcanard/avrcan PSC. I will also look at the avr driver from v0.

Thus having a C template project for Linux and a C template project for Arduino AVR.

1 Like

Libcanard v1.0.0 is now (finally) available. The road from the first commit to the first stable release took about five years, so this is a major milestone for us.

You can see the diffs from the previous release (announced in the OP post half a year ago) here: Comparing 0.100...1.0.0 · OpenCyphal/libcanard · GitHub


Here is the migration guide from Libcanard v0.100 to the stable v1.0.0. It is super short:

  1. Update your subject-ID idenfiers by clearing the two most significant bits. The maximum subject-ID was 32767 (15 bits), it was contracted down to 8191 (13 bits) in the Specification v1.0-beta. For example, the subject-ID of 32085 (0x7d55) would become 7509 (0x1d55). Notice that in many cases, this change does not really affect wire compatiblity between v0.100 and v1.0.0 (unless low subject-ID values are used) because the two removed bits are set to 1 when transmitting and ignored when receiving. This is now stabilized in Specification.

  2. When creating new subscriptions, the parameter extent should contain the extent of the data type, not just the maximum size of the object. Here is the explanation from the docs:

    The “extent” refers to the minimum amount of memory required to hold any serialized representation of any compatible version of the data type; or, in other words, it is the maximum possible size of received objects. This parameter is determined by the data type author at the data type definition time. It is typically larger than the maximum object size in order to allow the data type author to introduce more fields in the future versions of the type; for example, MyMessage.1.0 may have the maximum size of 100 bytes and the extent 200 bytes; a revised version MyMessage.1.1 may have the maximum size anywhere between 0 and 200 bytes. It is always safe to pick a larger value if not sure. You will find a more rigorous description in the UAVCAN Specification.

1 Like

That great!
but libuavcan v1.0 has not been released.

why libcanard v1.0 protocol not backward compatibility?

Yes. This may (or may not? only @scottdixon knows) happen next year, though.

Here, read this:

1 Like