CANFD stack for STM32s + Teensy 4.1

[Roozki]

Ideally this can be used by both Teensy 4.1s and any STM32

Prioritize STM32s if you can't support both. Supporting STM32s is a lot more versatile than just Teensy 4.1 as there are countless STM32s. Also, Teensy has a library: https://github.com/pierremolinaro/acan-t4

I'm sure there are loads of STM32 libraries as well, so this task may just be grabbing a few libraries and putting them into FirmFlake.

We can break down a CANFD stack into a few layers, but this task includes defining a good architecture, so this is only an example/guideline:

1. Transport layer - This is whats dealing with sending the bytes/raw data into hardware peripherals (via registers that are mapped to hardware).

• This may also include software defined message queues, but on a good MCU there should be hardware based FIFO queues for CAN.
• This should sit above the HAL (Hardware Abstraction layer), which would make it semi-agnostic to the MCU.
• Ideally, this is also agnostic to CAN. Or at least, have a virtual transport with send and receive functions and then make a can transport off of the virtual transport.

2. Transcoder layer - This is what deals with parsing the individual can messages into usable data, and vise versa. We should be able to give it any data structure, and have it output a buffer of bytes.

• main functions would be decode() and encode()
• Agnostic of what transport we are using
• Most CAN devices will have a .dbc file, which is the industry standard way of describing the message structures, and how many messages there are. We should have support to autogenerate encode/decode functions from .dbc files.
• will likley utilize tagged unions, or templates for output types. A single transcoder should be able to transcode multiple message types.

This task can blow up into a large task depending on how well we want to handle polymorphism and support accross MCUs, as opposed to just a stack for a specific STM.

First deliverable will be a block diagram, showing how the layers interact, and how to connect to hardware. See #20