RTEMS CAN/CAN FD project - start and initial progress report

Fri Nov 17 23:57:31 UTC 2023

Dear RTEMS community,

as I have already pre-announced, we are opening the project
to implement/port CAN/CAN FD framework to RTEMS. Our
wiki to form ideas, locate new and old code, and document
knowledge sources

   https://gitlab.fel.cvut.cz/otrees/rtems/work-and-ideas/-/wikis/can_fd

We do not have external funding for it now/yet. It is driven
by my long-term interest in RTEMS and CAN. Even that
it is more in enthusiast form now; there is some track
record of other viable activities pushed by me and my students,
LinCAN for Linux has been used for about 15 years by industry
(but mostly replaced by SocketCAN now), contribution to Linux
mainline SocketCAN (bit timing, priority filters, some drivers),
QEMU CAN/CAN FD subsystem, CTU CAN FD IP core with drivers
in Linux kernel mainline, used in space scientific payload
already and there are ongoing efforts to integrate it into
mass-produced silicons, etc.

The main developer of the actual project is Michal Lenc
who works on the project in the frame of his diploma thesis
work which is due by May 2024. He has a good track
record of CAN/CAN FD and other related RTOS work
mainly on the NuttX side from 2020

  https://github.com/apache/nuttx/commits?author=michallenc

but even tester RTEMS on Zynq 7000 to implement DC motor
steer-by-wire over UDP with TCP http server already in
a frame of real time systems course.

So I hope that we have a chance to provide something functional
even alone and with review, feedback, and cooperation from
the community and companies there are even better foresight. 

Our actual target hardware for RTEMS development and testing
is the MZ_APO educational kit based on MicroZed Xilinx Zynq 7000.
We plan to target our CTU CAN FD IP core in the first go, but
we have the FPGA design where we can combine XCANs, OpenCores
SJA1000 cores with our modification for CAN FD tolerance
in addition to CTU CAN FD. But work on other drivers probably
does not fit into this thesis's time budget. I try to find
other students or somebody else, even in the GSoC frame,
for example, who can contribute additional drivers.
SJA1000, CTU CAN FD, and Xilinx CAN FD on Versal
and UltraScale have QEMU functional models implemented,
so even that is a viable development environment.
But QEMU CAN supports SJA1000, and CTU CAN FD only
as PCI/PCIe integration for now...
It can be extended to platform mapping, or x86 or some
ARM with PCIe can be used for RTEMS development
as alternative.

The aim is to design the RTEMS CAN/CAN FD subsystem, which
can be/would be integrated into RTEMS mainline cpukit
if it passes RTEMS core developers review. But for now,
it is developed in a separate repository with OMK build
setup against standard RTEMS development kit in /opt/rtems.

The actual project zygote repository is on our GitLab

  https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd

but we can move it to another site or set up access
for others to contribute there. The actual main goal is to
collect sources and form/port infrastructure to use native
RTEMS score APIs. There are located in separate project
subdirectories some our sources to reuse. I.e. the rough port
of fragments of our CTU CAN FD Linux driver sources which
successfully transferred CAN frames between two CTU CAN FD
interfaces when compiled for RTEMS, no interrupts, queues,
etc., for now. Even communication with another USB
and MCU hardware has been tested from RTEMS.

The actual main focus is to adapt LinCAN FIFOs and infrastructure
for chip side and filesystem side nodes to use RTEMS score APIs.
This part is located in the lib/candrv subdirectory of the project.
Actual core files that are under current development

  https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/blob/master/lib/candrv/dev/can/can-frame.h
  https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/blob/master/lib/candrv/dev/can/can-queue.h
  https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/blob/master/lib/candrv/can-queue.c

LinCAN queues are documented in section 1.4. LinCAN Driver
Architecture of the LinCAN manual

  https://cmp.felk.cvut.cz/~pisa/can/doc/lincandoc-0.3.5.pdf

The actual architectural decision (based even on the previous discussion
on the rtems-devel list) is not to port/use RTEMS message queues
but to use original LinCAN FIFOs. That has some advantages.
When the chip message object is required for higher-priority Tx frames,
a pending message can be pushed back on the tail of the FIFO.

rtems_interrupt_lock and score atomic operations are used
for locking and SMP operation, which allows to implement chip
side (ends, low-level driver) even as the state automaton
that pushes messages into FIFOs from interrupt context.
Even that we plan to implement CTU CAN FD support as a regular driver
worker thread, there exist chips with short Rx hardware FIFOs
which could need direct passing of frames from interrupts
to prevent the message drops. If the FIFOs use from interrupts
is not required, then switch of the locking to regular mutexes
is possible. The locking is fine-grained, and all functions that
manipulate with FIFOs and edges in the graph of delivery and filtering
between character driver interfaces and controller chips
are locked only during the iterator transition to the
next option/filter/edge, during frame slot allocation, release, etc.
But never during the actual copy of data or other frames processing
and chip registers accesses.

The actual ported code is only the core part, and there are still some
omissions to fix. But the code compiles under RTEMS. The following steps
are implementing the character driver interface and porting a LinCAN
virtual/dummy chip for local echo testing with queues. Then CTU CAN FD
driver implementation and multiple priority queues support will follow.

I will visit my friend in the Netherlands who works at ESA ESTEC
from Sunday to Wednesday. I even plan to visit ESTEC with him
to see some of our motion control units at work etc. If there
is somebody interested in meeting and discussing CAN/CAN FD/CANopen
use in space as well as RTEMS, Linux, NuttX related tasks, you
can contact me, and we can meet at ESTEC.

Best wishes,

                Pavel

                Pavel Pisa
    phone:      +420 603531357
    e-mail:     pisa at cmp.felk.cvut.cz
    Department of Control Engineering FEE CVUT
    Karlovo namesti 13, 121 35, Prague 2
    university: http://control.fel.cvut.cz/
    personal:   http://cmp.felk.cvut.cz/~pisa
    social:     https://social.kernel.org/ppisa
    projects:   https://www.openhub.net/accounts/ppisa
    CAN related:http://canbus.pages.fel.cvut.cz/
    RISC-V education: https://comparch.edu.cvut.cz/
    Open Technologies Research Education and Exchange Services
    https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home