[RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch (LinCAN inspired)

Tue Feb 27 21:27:43 UTC 2024

On Mon, Feb 12, 2024 at 8:03 AM Pavel Pisa <pisa at fel.cvut.cz> wrote:
>
> Dear RTEMS community, the core developers team,
>
> Michal Lenc works on a new generic CAN/CAN FD subsystem for RTEMS under my
> supervision. The project has reached a phase where we will be very grateful
> for the review and pointing to required changes to start a discussion of
> possible inclusion into the RTEMS mainline. The project is currently being
> developed as a separate RTEMS application based on the OMK build
>
>  https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
>
> But long-term intention is to move
>
>  https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/tree/master/lib/candrv
>
> directory into RTEMS cpukit/dev/can directory and corresponding include files
> into cpukit/include/dev/can directory.
>
Thanks. I will review this design and code, but it will be a few weeks
before I can do that. The directory location is a suitable choice.

> We have reached a state where the virtual interface has been tested on an
> MZ_APO Xilinx/AMD Zynq-based board and an LX_CPU/LX_RoCoN NXP LPC4088-based
> board. The communication with a complete CAN interface has been successfully
> tested on the MZ_APO Xilinx/AMD Zynq board with CTU CAN FD IP cores
> implemented in FPGA.
>
> Building on other RTEMS BSP should be possible by changing a single definition
> in the config.target file
>
>   RTEMS_MAKEFILE_PATH=/opt/rtems/6/arm-rtems6/xilinx_zynq_zedboard
>
When ported to cpukit, this would become part of the spec/build opts.

> To test with the controller, we can provide FPGA bitstream, which should fit
> Zed/MicroZed or other XilinX Zynq 7Z010  based boards, and thanks to the
> source availability of CTU CAN FD core, it can be ported to other FPGA+SoC
> platforms. We have QEMU CTU CAN FD PCI integration emulation so that
> can be other target for continuous integration testing even on x86, but
> PCI/PCIe mapping has to be added to the RTEMS driver code.
>
> The API to the driver is provided in the form of the POSIX character device.
> Each CAN controller (chip) is registered as a node into the "/dev" namespace
> by name (i.e., "can0", "can1", ... ). It can be opened multiple times, and
> each instance of the open can be accessed from multiple threads. Written CAN
> frames are posted into the input end of the queue (FIFO), which is connected
> to the CAN controller (chip) or other frame processor on the output side. The
> processor takes frames from FIFOs according to their priority class and
> transmits them to the network. When the frame is successfully sent, it is
> echoed back to all queues back to open file instances except the sending one
> (that filtering is configurable). The filtering is implemented in
> canque_filter_frame2edges() function. Received frames are filtered to all
> queues to applications ends of the queues, which filter matches the CAN
> identifier and frame type.
>
> The design is based on FIFOs designed closely to support needs to provide
> service optimal to CAN frames delivery. On the controller side,
> multiple slots, each with one CAN frame, can be taken from FIFO and kept
> until the transmission is finished. Then, the frame from the slot is
> distributed to inform even local clients about the frame that was sent.
> The framework has a unique feature to allow pushback slots (frames) when some
> later scheduled low-priority frame occupies the hardware Tx buffer, which is
> urgently demanded for a higher priority pending frame to be sent. Then the
> frame push back to the FIFO head is delivered for Tx processing again.
>
> We present (in the prepared article) how our design resolves bus arbitration
> priority inversion, which is often a problem for generic CAN drivers and
> subsystems, which allows access from more applications than is the fixed
> Tx buffers count. With a well-behaved controller, we are able to keep
> all available Tx hardware buffers filled by the right frames instantly.
> When higher priority class frame is released by the application into
> queues, the controller replaces the latest lower priority frames
> with higher priority one and places it in the sequence after all
> frames with the same priority class but before all with lower priority.
>
> We will present the idea in the prepared article at the
> international CAN Conference in May
>   https://www.can-cia.org/icc/
>
Thanks, I will read the article to see if I still have questions.

> The design implementation choice is to use CAN-specific FIFOS queues.
> The consistency is protected by rtems_interrupt_lock_acquire /
> rtems_interrupt_lock_release, and thanks to reference counting
> of users iterating with given queue from both its ends, the locks
> are released during most of the operations and are held
> for a really short time. We consider rtems_interrupt_lock
> appropriate thanks to low overhead when we keep it
> for limited code sequences. But switching to semaphores
> or some POSIX mutexes is possible. But we also want to keep
> code usable on RTEMS build even without POSIX API enabled,
> and classical API semaphores have significant size and execution
> time overhead.
>
> We have switched to BSD Tail Queues (TAILQ) to keep lists
> of the queues (FIFOs) coming to/from a given frame processor node
> because they are provided even by NewLib and make code portable
>   #include <sys/queue.h>
> The API is much harder to use than Linux struct list_head
> and supporting functions. My preferred alternative is my uLUt
> solution, which we use on bare metal embedded systems, Linux
> RTEMS and NuttX, but it would require introducing lot of
> code and complex macros into RTEMS cpukit.
>
> We are looking for feedback and cooperation. If the solution
> passes the demands of the RTEMS core community, then it would
> worth to port support for other controllers on this base.
> We can open a GSoC project for it.
>
> If the solution is acceptable, we should set up a page on RTEMS devel.
> The preliminary wiki is at our faculty GitLab. But it is hard to
> enable for general editing access. We can move even on GitHub.
>
> Michal Lenc will submit work as his Master's Thesis this May
> so I hope that Gedare would be willing to take the thesis
> reviewer role as we have already discussed.
>
Indeed I will. I think this work is exciting and needed.

> We will present our CAN latency testing project at the embedded world
> Conference 2024 as well as on OSADL booth https://www.osadl.org/
> in Nuremberg from April 9 to 11. There is an option to meet and discuss
> RTEMS CAN and other projects in person. Our latency testing
> focuses on Linux SocketCAN, but long ago, we tested LinCAN
> on Linux and even original MSM CAN on RTEMS. I plan to add RTEMS
> to our actual latency tester project in the frame of some another
> future student project.
>
> 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