[RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - Embedded World

[Pavel Pisa]

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:     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





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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel