So I decided to move platform-specific code away from the Libcanard repository, as was planned since long ago. I cast my gaze upon our GitHub organization and saw much clutter. Of the 22 repositories, 5 are dedicated to the platform-specific components of Libuavcan. If we are to continue the same policy with Libcanard, the number of hardware-specific items would be unwieldy. Ideally, I would like to avoid maintaining low-level hardware-specific code completely, and yet here we are.
Having dedicated repositories for each combination of platform+library won’t do so we need a grouping policy. How about we keep one repository per target platform? That might allow us to share platform-specific logic between library-specific components, and, most importantly, that might simplify testing since it would be sufficient to set up the HITL hardware or a simulator once and reuse it.
The other obvious alternative is to move platform-specific parts back with their libraries but it is worse than what we have now because 1. our libraries are platform-agnostic and 2. we can’t maintain every platform-specific component to the same quality standard as the library core.
If the per-platform grouping policy is implemented, we’d end up with the following repositories:
-
stm32
for the Libuavcan and Libcanard platform adapters. Later it will be expanded with a new adapter for STM32H7’s CAN FD macrocell. -
nxp_s32k
for @noxuz’s Libuavcan adapter. nxp_kinetis
-
nxp_lpc11c24
(come to think of it, we have a great deal of NXP in here) -
nuttx
– for Libcanard’s generic NuttX interface (actually I’m thinking we don’t need it at all because it is trivial). -
socketcan
– ideally, this one should be compatible with every flavor of SocketCAN: GNU/Linux, Zephyr, and the upcoming NuttX.