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