[RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation
Pavel Pisa
ppisa4lists at pikron.com
Sat Apr 27 09:53:54 UTC 2024
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: 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
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: 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
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
More information about the devel
mailing list