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: p...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel