Announcing WIP: Go port of libcanard

soypat · September 10, 2022, 8:58pm

Hello there! I’ve been working towards creating a port of libcanard for Go.
It aims to be portable and lightweight like the reference with slightly different API to that of libcanard. Notable differences:

Make use of Go’s error type for errors
Uses standard library’s memory allocator
Use methods to simplify working with data types such as Tail byte, CRC, NodeID, etc.

This project readily compiles with tinygo to over 80 micro-controller targets as well as your favorite OS and architecture.

pavel.kirienko · September 12, 2022, 6:40am

Sounds awesome. Is your work open source? If so, are you planning to share a link to it? I would love to have a look.

One thing that is missing in libcanard by design is the set of higher-level capabilities that used to be provided in the original libuavcan v0, such as high-level pub/sub API, register interface, and so on. We’ve been planning to create a higher-level libcyphal that would be put on top of libcanard, libudpard, and possibly other transport implementations to provide these missing higher-level protocol capabilities and reduce the adoption barriers. This matters because the capabilities offered by libcanard/libudpard are so bare-bones that one has to learn quite a bit of the protocol to get it to work correctly. Hence, I have two questions:

Do you have plans to provide higher-level protocol capabilities in your library?
Do you intend to support other transports, most importantly Cyphal/UDP?

soypat · September 12, 2022, 12:37pm

How could I have missed that! Heres the repo: https://github.com/soypat/go-canard

My plan with go-canard is to have a bare-bones working cyphal implementation so that it can be used with Go. Usage will bring out pain points. It will also help me understand how Cyphal really works. Porting the library has given me a much better understanding than I initially had though I’m still hazy on the details.

To answer your questions:

Do you have plans to provide higher-level protocol capabilities in your library?

No plans. I guess time will tell, maybe using this library as-is is hard enough to warrant a higher-level API. In this case I’d certainly want to have a higher level API. Though since I still have not used this library I have no need for it and so no idea of what shape or form it would have!

Do you intend to support other transports, most importantly Cyphal/UDP?

If I do it’d be conforming to the standard library API implementation of UDP. This is a goal of the library since I do plan on working with UDP with this. Supporting UDP would then also support TCP by extension.

What I like about this implementation is the error handling. One could already used go-canard to build a packet/bus analyzer, if I’m not mistaken.

pavel.kirienko · September 12, 2022, 3:35pm

I think it’s not really about the API of your library but rather about the capabilities implemented. For instance, if I wanted to implement the register interface (a very core capability that is required for basically any node), I would have to write tedious stuff like this:

github.com

OpenCyphal-Garage/demos/blob/598be7aad85bc5b73381077a37b32d4ea5f48e81/differential_pressure_sensor/src/main.c#L454-L497

      
        
            /// Performance notice: the register storage may be slow to access depending on its implementation (e.g., if it is
            /// backed by an uncached filesystem). If your register storage implementation is slow, this may disrupt real-time
            /// activities of the device. To avoid this, you can employ these measures:
            /// - Access registers asynchronously.
            /// - Run a separate Cyphal processing task for soft-real-time blocking operations (this approach is used in PX4).
            /// - Cache register states in RAM and synchronize them with the storage asynchronously.
            /// - Document an operational limitation that the register interface should not be accessed while ENGAGED (armed).
            static uavcan_register_Access_Response_1_0 processRequestRegisterAccess(const uavcan_register_Access_Request_1_0* req)
            {
                char name[uavcan_register_Name_1_0_name_ARRAY_CAPACITY_ + 1] = {0};
                assert(req->name.name.count < sizeof(name));
                memcpy(&name[0], req->name.name.elements, req->name.name.count);
                name[req->name.name.count] = '\0';
            
            
    uavcan_register_Access_Response_1_0 resp = {0};
            
            
    // If we're asked to write a new value, do it now:
                if (!uavcan_register_Value_1_0_is_empty_(&req->value))
                {
                    uavcan_register_Value_1_0_select_empty_(&resp.value);

This file has been truncated. show original

github.com

OpenCyphal-Garage/demos/blob/598be7aad85bc5b73381077a37b32d4ea5f48e81/differential_pressure_sensor/src/register.c

/// This software is distributed under the terms of the MIT License.
/// Copyright (C) 2021 OpenCyphal <maintainers@opencyphal.org>
/// Author: Pavel Kirienko <pavel@opencyphal.org>

#include "register.h"
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <stdbool.h>
#include <sys/stat.h>
#include <dirent.h>
#include <unistd.h>

#define PASTE3_IMPL(x, y, z) x##y##z
#define PASTE3(x, y, z) PASTE3_IMPL(x, y, z)

static const char RegistryDirName[] = "registry";

static inline FILE* registerOpen(const char* const register_name, const bool write)
{

This file has been truncated. show original

There are better ways to spend developer’s time.

I guess it makes sense for a Go library. Are UDP sockets supported in Tiny Go though? WIth libudpard the plan is to go low-level, incorporating a minimal UDP/IP stack with IGMP support. Is IGMP supported in Tiny Go?

I don’t think so. Cyphal/UDP and Cyphal/serial do not really have much in common, but I suppose it’s not very important right now.

soypat · September 12, 2022, 4:05pm

write tedious stuff like this […] There are better ways to spend developer’s time.

Which leads me to believe: yes, there is a need for a higher level API.

Are UDP sockets supported in Tiny Go though?

Not today. The plan is to implement it someday. I’ve written a few really bad micro Ethernet/IP/TCP stacks back in the day. Plan is to write an actual good one next time.

I don’t think so. Cyphal/UDP and Cyphal/serial do not really have much in common

Hmm. I’m probably misunderstanding something about how the Cyphal works? My thinking is based on how the Go standard library works: the API for TCP and UDP packet sending is nearly identical, minimal modification would be necessary to convert a UDP packet protocol to TCP packet protocol. But that is a ways off, like you say: not of most importance right now.