Compatibility with extremely resource-constrained baremetal environments starting from ca. 32K ROM, 4…8K RAM.
Implemented in less than 1500 logical lines of code.
API stabilization is expected by 2020Q4 or earlier. Starting now, it is expected to be safe to commence a new project reliant on UAVCAN v1.0 based on Libcanard and/or PyUAVCAN. Libuavcan v1 (a major C++11 implementation) and Yukon (the new GUI tool) are expected to become available before the end of 2020.
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.
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:
canardRxAccept
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.
rxSessionUpdate
canard.c:835 if (correct_transport && correct_toggle && correct_tid)
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:
The demo given in the Libcanard README (it’s not a complete example but it’s better than nothing).
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.
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.
Great work 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.
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.
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.
Here is the migration guide from Libcanard v0.100 to the stable v1.0.0. It is super short:
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.
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.
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 shall proceed to add a suitable post immediately.