Dear RTEMS and CAN community, I want to report another update in Michal Lenc work on the generic CAN/CAN FD RTEMS stack. The Sphinx and Doxygen documentation is generated by CI on our faculty GitLab server. Links to RTEMS CAN resources in the section
CAN/CAN FD Subsystem and Drivers for RTEMS https://canbus.pages.fel.cvut.cz/#cancan-fd-subsystem-and-drivers-for-rtems Repository https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd Manual https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html Doxygen https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/index.html CAN/CAN FD frame and header described there https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/structcan__frame.html Feedback from everybody is welcomed. It would be especially welcomed if Oliver has some remarks to can_frame_header and can_frame field names because changes of these start to be more painfull when/if project is accepted into RTEMS mainline. Oliver is not probably on RTEMS list, but I would forward reply there if it will not pass. I have done initial update of our CAN/CANopen framework from2003 year to be prepared to work with new RTEMS solution. Only classic CAN frames for now, FD is ignored https://ortcan.sourceforge.net/ https://sourceforge.net/p/ortcan/ortcan-vca/commit_browser 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 company: https://pikron.com/ PiKRON s.r.o. Kankovskeho 1235, 182 00 Praha 8, Czech Republic projects: https://www.openhub.net/accounts/ppisa social: https://social.kernel.org/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 On Friday 05 of April 2024 12:38:28 Pavel Pisa wrote: > Hello everybody, > > Michal Lenc has updated the project to switch from RTEMS > semaphores allocated with object ID to self-contained > ones according to the previous response that self-contained > objects are preferred. Se actual state in the repo > > https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd > > The both cases of switching to self-contained objects > (interrupt_lock -> rtems_lock ) > (rtems_semaphore_create -> rtems_binary_semaphore_init) > seems to cause measurable increase of overhead in the > performace testing of the virtual CAN interface > on Zynq platform. The real communication performance > does not changed significantly when actual frame sending > time on the wire is in the loop. But that is the first > glimpse result only, we may find time for more evaluation > and even integration of RTEMS to our continuous tests > setup some day. > > Michal Lenc's thesis submission deadline is approaching > and we would like to have some feedback to start preparation > of proposal to integrate code into official RTEMS cpukit. > > We will be both available at Embedded World Exhibition > and I will even present the article about CAN/CAN FD > latency in Linux kernel at the ewC conference > > April 9, 4:00 PM - 5:45 PM > Session 2.3 CONNECTIVITY SOLUTIONS > Continuous CAN Bus Subsystem Latency Evaluation and Stress Testing > on GNU/Linux-Based Systems > https://canbus.pages.fel.cvut.cz/#can-bus-channels-mutual-latency-testing > > We will take some species from our hardware ZOO and will > show them on https://www.osadl.org/ booth OSADL booth in hall 4, booth > 4-168 so if you want to contact us, you can stop there. We will have > Linux, RTEMS booted MZ_APO kits there and some other > Linux, NuttX ARM and RISC-V boards. Even if we are > not presnet at the moment on the booth, OSADL colleagues will have > contact to us. If there is some RTEMS meeting, we will try > to reserve time. > > 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 > > On Wednesday 13 of March 2024 17:01:30 Michal Lenc wrote: > > Dear RTEMS developers, > > > > we have made a progress with our CAN stack and virtual/CTU CAN FD > > controller tests using standard x86-64 QEMU. We can now provide scripts > > that build the stack and our applications on i386-pc686 target and run > > RTEMS in QEMU. The actual CAN stack can still be found in our university > > GitLab > > > > https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd > > > > and following steps build and run RTEMS in QEMU: > > > > $ export PATH=$PATH:/opt/rtems/6/bin > > > > $ cd targets/i386_pc686 > > > > $ ./setup-host-socketcan > > > > $ ./qemu-i386-pc686-2x-ctu-pci-build > > > > $ ./qemu-i386-pc686-2x-ctu-pci-run > > > > Support for i386_pc686 BSP is located in /opt/rtems/6 in this case. You > > can use following script to compile the BSP with required configuration > > setting. > > > > $ ./i386-rtems-sys.cfg (you might need to change RTEMS_DIR variable > > based on your location of RTEMS source code directory) > > > > RTEMS terminal in QEMU should come up after executing run command. You > > can try applications for both virtual controller and CTU CAN FD > > controller. The controllers have to be initialized and register which is > > done by > > > > can_register -t [target] > > > > command (target is either virtual or ctucanfd). Registered devices are > > assigned to test applications with can_set_test_dev [dev0] [dev1] > > command, where dev0 and dev1 are paths to character devices. Then test > > applications are can_1w (one way) and can_2w (two way). For example for > > CTU CAN FD > > > > # this registers two CTU CAN FD controllers under dev/can0 and dev/can1 > > > > SHLL [/] # can_register -t ctucanfd > > > > # assign dev/can0 and dev/can1 to test applications > > > > SHLL [/] # can_set_test_dev /dev/can0 /dev/can1 > > > > # run test applications > > > > SHLL [/] # can_1w > > > > SHLL [/] # can_2w > > > > All those steps are also described in project README or you can use help > > app command in RTEMS terminal to get further description of commands and > > their arguments. > > > > We want to rewrite some other controllers for our CAN stack to provide > > further tests and widen the support (SJA1000 would probably be the first > > one on our list), but currently the priority is the full completion of > > the stack itself (error reports, all required IOCTLs, etc.). > > > > Best wishes, > > > > Michal Lenc > > > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel