[WIP] Implemented support for CAN-FD with dynamically sized allocator blocks.

kjetilkjeka commented 5 years ago

Not all done, please leave initial feedback. Look at todo to see what you can refrain from commenting.

Design:

The design is based around adding a notion of protocol to the interface that will only affect the maximum data size of transmitted frames (output from libcanard).

The received frames (input to libcanard) has been changed to accept an array of variable size to allow receiving from all kinds of interfaces in all kinds of modes (to support bootloaders etc, ref prior discussion).

Convinient types (with data size corresponding to CAN 2B and CAN FD) for reception of CAN frames is provided in canard.h. This is not strictly necessary but avoids the hassle of making sure your type is compatible with the CanardCANframe type.

Constraints:

Transmitted frames != received frames

Due to C being quite awfull I'm not allowed to create the following type

struct CanardTxItem
{
    CanardTxItem* next;
    CanardCANFrame * frame;
};

This forces me to unroll the fields of CanardCANFrame into CanardTxItem like the following

struct CanardTxItem
{
    CanardTxItem* next;
    uint32_t id;
    uint8_t data_len;
    uint8_t data[];
};

After reading the C specification on type compatibility i see no way to safely return a CanardCANFrame* from this type. Which unfortunately means that the whole CanardTxItem must be returned or data must be copied. I don't think this is great, but not terrible either (this being C). We are only returning const pointers of this block so messing up the next field should be considered misuse.

Todos:

[ ] Add FD equivalent tests to what exists for 2B
[ ] Write tests for functionality that is touched and previously did not have tests
[ ] Update the .md files
[ ] Try to massage the FD block size down to 80 bytes
[ ] Attempt to write assert on all properties required to be compatible types for can frame types.

Kreolis commented 4 years ago

Hello, how far is this? Would like to use it on a payload for the ISS? CANFD would be nice there. You are doing great work so far! Sincerely Kreolis

pavel-kirienko commented 4 years ago

Thanks, @Kreolis484. I am supposed to have this finished soon, but there are only 24 hours in a day and my todo list for some reason is not getting shorter. I will get to this (and also the other urgent PR here) as soon as I can; per the roadmap, we are aiming to have this released by Q1 2020.

ISS

Could you share any details? Maybe even on the forum, perhaps? Thanks in advance!

pavel-kirienko commented 4 years ago

As discussed with Kjetil in November, I am taking this over so I am going to close this PR and cherry-pick relevant things into my own branch.

OpenCyphal / libcanard