What we’re building here is not an operating system.
One of the main reasons why I wanted to separate the libuavcan platform drivers from the libuavcan repo is to prevent the misunderstanding that libuavcan can only be used with platforms it has been “ported” to; that is not true, and I would avoid using the word “porting” in public because of the risk of misunderstanding. What we describe as “porting” here in this thread (assuming we’re talking about libuavcan in the first order) amounts to writing implementations of three C++ interfaces: uavcan::ICanDriver, uavcan::ICanIface, uavcan::ISystemClock. I suppose that when a regular developer (like myself) who is not familiar with UAVCAN hears the word “porting” they imagine something like this instead: https://docs.rtems.org/releases/rtemsdoc-4.7.3/share/rtems/pdf/porting.pdf.
In the case of libcanard there is no place where the concept of porting can be applied to, since the library doesn’t even have a dedicated driver layer (the hardware-specific parts should be moved into dedicated repositories as well, too).
As what we are building is quite agnostic of the hardware it is running on, we can cover the entirety of the logic with automatic tests where the actual driver is replaced with mocks. What should be relegated to testing on-hardware is probably just the hardware-specific logic: in the case of libuavcan that would be the implementation of the three interfaces mentioned above, in the case of libcanard that would be just a collection of functions for working with the CAN hardware.
So, in the view of the above, we should apply the Scott’s proposal not to the reference implementations of the specification, but to their small hardware-specific parts only. Here is a summary of the current situation:
For libuavcan:
| Platform | OS | Quality | Testing target |
|---|---|---|---|
| STM32 bxCAN | ChibiOS | okay | none |
| STM32 bxCAN | FreeRTOS | okay | none |
| STM32 bxCAN | NuttX | poor | none |
| STM32 bxCAN | none | very poor | none |
| Kinetis FlexCAN | NuttX | ? | none |
| NXP LPC11C24 C_CAN | none | okay | Olimex LPC P11C24 dev board |
| SocketCAN | GNU/Linux | okay | GNU/Linux |
Nice to have:
- STM32 FDCAN (available on STM32H7 only AFAIK)
- FlexCAN FD (the current Kinetis driver requires either a heavy update or a rewrite since it’s NuttX-only)
- Refactoring the existing STM32 support into several independent versions per operating system (should be discussed). Support for ChibiOS can probably be made hardware-agnostic since Jonathan Challinger made an effort to fix their stock CAN driver (not sure of the results of this effort though).
For libcanard:
| Platform | OS | Quality | Testing target |
|---|---|---|---|
| STM32 bxCAN | any | okay | none |
| any | NuttX | okay | none |
| AVR | none | ? | none |
| SocketCAN | GNU/Linux | okay | GNU/Linux |
Nice to have:
- STM32 FDCAN (available on STM32H7 only AFAIK)
- NXP LPC11C24
- FlexCAN FD
I am not sure how valuable Atmel platforms are. By the way, I should correct a minor unfairness here towards STM32H7: it is more computationally powerful than V71 being a Cortex M7-based MCU with double-precision FPU clocked at 400 MHz. To my knowledge, this seems to be the most powerful M7-based MCU as of today. Can I get a job in the ST Microelectronics sales department now?
So, considering the above, I don’t think it is that important to have a testing platform that everybody agrees upon, unless several geographically distributed developers collaborate on the same driver. I personally have a Nucleo here in the lab with separate CAN FD transceivers which should work well for testing. If automated on-hardware testing is desired (it’s certainly nice to have), it should be discussed on a per-driver level.