On Mon, Feb 12, 2024 at 8:03 AM Pavel Pisa <p...@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: 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