[RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

Mon Apr 29 08:56:29 UTC 2024

Hello Pavel,

it's quite a big work. So I've started to read through the
documentation to get an overview. Some questions:

Do I understand that correctly, that the only user-facing interface is
via the "/dev/can*" files. There is no separate interface for special
operations, right? That's completely OK for me. I just want to make
sure that I understand it correctly.

Chapter "1.1.1.1: Managing Queues": I assume the limitation that
RTEMS_CAN_DISCARD_QUEUES removes all queues and not only selected ones
is a limitation due to the nature of the ioctl interface or the driver
capabilities? It could be a bit of an annoying limitation in an
application that dynamically wants to register or unregister queues.

Chapter "1.1.1.3: Setting Mode": These look quite controller specific.
If I want to add a controller that has a new mode: Would I just add a
new flag? What happens if we reach 33 flags? Would an array or maybe a
structure with a single uint32_t field be a better choice? I assume
that if a controller doesn't support a mode, (like setting FD on a
non-FD controller), the IOCTL will just return an error?

Chapter "1.1.3: Frame Transmission" and "1.1.4: Frame Reception": The
last argument of "write" is a count. If I see a write, my first guess
is that I have to call it like:

   struct can_frame frames[10] = {... /* some values */ ...};
   ssize_t rv = write( fd, frames, sizeof(frames) );

But from taking a look at the tests in the repository, the count
is calculated by can_framelen(). Is it possible to send or receive
multiple CAN frames using write or read? Or is it always a single
frame? What happens if I pass a wrong length? Do I send wrong data,
crash the system or the whole CAN bus or do I just get an error? Can
you make that more clear in the documentation?

Some details regarding "struct can_chip":

* There is a pointer called "type". I would use a "const char *" for
   that. I expect that stuff like names will never change and having
   them constant allows to use a pointer to a flash memory area.

* You have an "int irq". That's not fully compatible to the
   rtems_vector_number which is an uint32_t (at the moment).

Regarding the CAN drivers: Do I see it correctly, that currently only
a single (real) device is supported (ctucanfd)? Did you check with
some other hardware controller, whether the whole structures / defines
/ flags close to the hardware do work well for other controllers too?
Like the mode flags from 1.1.1.3. It doesn't really matter which other
controller. From my own attempts to write a driver stack, I just know
that sometimes you make assumptions based on one controller that are
hard to implement on another one. Usually it's not even necessary to
really add a second controller. Just skimming through the manual can
be really helpful. On the other hand, the Doxygen documentation
mentions, that the concept is based on LinCAN. So maybe that already
helps to avoid that trap?

Regarding the device names "/dev/can0" and similar: Currently that
seems to be a fixed scheme, correct? In my experience, sometimes it
can be useful to use longer names instead. For example
"/dev/can_ctufd0". That's especially interesting if a system is
initialized dynamically. For example if you have a USB to CAN adapter
that is enumerated more or less randomly during startup. Is that
supported or are there some fixed assumptions that a can device is
always called "/dev/canX"?

Best regards

Christian

On 2024-04-27 11:53, Pavel Pisa wrote:
> 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
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
--------------------------------------------
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email:  christian.mauderer at embedded-brains.de
phone:  +49-89-18 94 741 - 18
mobile: +49-176-152 206 08

Registergericht: Amtsgericht München
Registernummer: HRA 117265
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/