[RFC] CAN and CAN FD stack

[RICCIARDI-Adrien]

Hi Trampoline team,

I would like to use CAN and CAN FD with Trampoline for a project. I would like to do that in a way that can also benefit other Trampoline users, so I'm asking for your point of view.

The idea is to integrate an already existing CAN/CAN FD stack to Trampoline and write the microcontroller low level CAN driver that is compatible with such stack. This way, other platforms wanting to use CAN would only require a CAN driver able to read and write the bits on the wires, and all the CAN and CAN FD protocol logic would be reused from the stack.

Where could I put the CAN stack in the source tree for it to be reusable by all machines ? I would suggest something like a net/can directory in the root directory, like the Linux organization. However, I'm lacking a lot of AUTOSAR knowledge, so maybe there is a better location that is compliant with AUTOSAR Network Management.

How can I create a library that could be shared with all machines (a library in the meaning of OIL) ? In each machine OIL configuration template (for instance goil/templates/config/avr/arduino/config.oil), is it possible to create a LIBRARY that references the C file for the low-level CAN driver and also the CAN stack (maybe as another library) ? It would be nice to use a single statement like LIBRARY = can; in the machine exemples to enable the CAN support.

After some researchs I think that the most complete stack, featuring CAN and CAN FD, is the one from Zephyr : https://github.com/zephyrproject-rtos/canopennode. Would you be OK to use it, maybe as a git submodule ?

Best regards, Adrien

[jlbirccyn]

Hi Adrien

I check with my team mates.

Best regards

[RICCIARDI-Adrien]

Hi Jean-Luc,

Thank you for your interest.

After further investigation, the CAN stack I proposed might be too complex to be integrated here. I'm thinking now at a very little "framework" for the CAN/CAN FD protocol (a single C file). Its purpose would be to provide an unified API (for instance tpl_can_init(), tpl_can_send() and stuff like that). Internally, it would do some work (for instance adjusting the size of a CAN FD frame) then call callback functions from the MCU CAN driver.

[jlbirccyn]

IMHO, There are two main angles of attack:

1. For OSEK, the standard does not define how a CAN driver has to be designed and the main problem is the integration with OSEK external communication as defined in http://osek.triskell.org/OSEKCOM303.pdf There is a lot of (interesting) work to do.
2. For AUTOSAR, the CAN driver specification is available: https://www.autosar.org/search?tx_solr%5Bfilter%5D%5B0%5D=category%3AR22-11&tx_solr%5Bfilter%5D%5B1%5D=platform%3ACP&tx_solr%5Bq%5D=

[RICCIARDI-Adrien]

The AUTOSAR spec may be a good choice to follow as everything is already specified, and this also improves the Trampoline AUTOSAR compliance. I think that the CAN interface (https://www.autosar.org/fileadmin/standards/R21-11/CP/AUTOSAR_SWS_CANInterface.pdf) and the CAN driver (https://www.autosar.org/fileadmin/standards/R22-11/CP/AUTOSAR_SWS_CANDriver.pdf) should be enough for now. If I start implementing part of both specs (in an extendable way so more features can be added later), are you OK if I try to stick to the AUTOSAR names in the code (for instance, calling the function Can_Init() like in the standard or naming the header files like Can.h ? Do I put the source files in the already existing Trampoline autosar directory or do I create a dedicated directory for the CAN ?

[RICCIARDI-Adrien]

Hi, The new pull request https://github.com/TrampolineRTOS/trampoline/pull/137 adds support for CAN-FD to the CAN stack. The CAN stack is tested against the POSIX machine can_demo example and also against an internal driver for real hardware. Any comment is welcome !