NuttX: Add UAVCANv1 support for STM32H7 MCUs via SocketCAN

[JacobCrabill]

DRAFT
This will require a PR against PX4 NuttX to backport apache/nuttx#6057, but I'd like some eyes on this first for a quick sanity check before going further (please!).

Requires one of the following PRs against PX4 NuttX first:
PX4/NuttX#185 or PX4/NuttX#186
DRAFT

Describe problem solved by this pull request

This pull request adds SocketCAN support for STM32H7 MCUs, and in particular, adds SocketCAN + UAVCANv1 support for the Orange Cube (an H7-based autopilot I happen to have lying around). The build target make cubepilot_cubeorange_socketcan points to a NuttX config including CONFIG_NET_CAN and associated config vars to enable SocketCAN

(I can't remember off the top of my head whether CAN_FD gets enabled by default or not right now; be sure to check on CONFIG_NET_CAN_CANFD).

Describe your solution

This pull request updates the NuttX submodule to a WIP branch on my personal fork of upstream. As stated above, for this to leave the DRAFT phase, the changes from apache/nuttx#6057 (among others) need to be backported.

Describe possible alternatives

There are only a couple alternatives to enabling UAVCANv1 support on STM32H7 MCUs:

1. Finish the WIP STM32H7 character-device driver (STM32H7: Add new FDCAN driver apache/nuttx#2987)
2. Port libuavcan (and its tightly coupled drivers) to UAVCANv1

The downside of using a character-device driver is that that only one task can use the CAN interface at a time (not a shareable resource). SocketCAN, via the socket API, allows multiple tasks to access the CAN interface, independently and concurrently. I have a feeling this will become super useful for sharing a bus between DroneCAN and UAVCAN(v1).

The downside of using a tightly-coupled libuavcan driver is that the driver is tied to libuavcan and is hard to use for other protocols (e.g. Tattu CAN, KDE CAN, random sensors that just publish a single message, any engine ECU with a CAN interface...)

An additional benefit of the SocketCAN interface is that software using it can run on both embedded targets and your local development machine.

Test data / coverage

Testing is limited, but I have done the following so far:

1. Interact with both can0 and can1 using a PEAK USB CAN-FD dongle
   • Use the cansend / candump utils, to / from the Cube / my desktop (both directions)
   • Both std ID frames, ext ID frames
   • Both CAN2.0 and CAN-FD, nominal bitrate 1000000, data bitrate 4000000 for FD
2. Use Yakut to interact with uavcan_v1 on can0 (I don't think can1 is used by uavcan_v1 right now), both CAN-FD and non-CAN-FD. yakut monitor shows the expected outputs, but I haven't really stressed the system yet.

Areas not tested, or not completed:

1. Message timeout and cancellation
2. SW-level message filtering (network stack Rx filters)
3. HW-level message filtering (configure filter elements in message RAM)
4. Filter usage at the libCanard layer

Additional context

I'm still doing additional bench testing for a bit longer; I'll be doing code cleanup in parallel. Once I get things cleaned up, I'll create board configs for other STM32H7-equipped autopilots and add those to this PR.

There is also some work to be done at the uavcan_v1 layer -- specifically, latency between calls to canardTxPush() and UavcanNode::transmit(). I've added a quick "hack" fix here to all Publishers to remove this unwanted latency, but a cleaner solution may be desired.

Looking for assistance with testing, finding bugs, and any feedback on the topic.

[dagar]

Waiting on the NuttX upgrade.