[RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation
Michal Lenc
michallenc at seznam.cz
Mon Apr 29 20:48:53 UTC 2024
Hello Christian,
thank you a lot for the review. In addition to Pavel Píša's reply, I
have updated the documentation to provide (hopefully) a better description.
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html
I plan to enhance it further, I write it in parallel with my diploma
thesis at the moment and sometimes I have the text already written in
one document and not in the other one. So thank you for pointing out the
parts where the description was not clear. I will address the changes in
can_chip structure later this week.
Regarding future CAN controllers, I hope we will find some time and
resources for the implementation of SJA1000 controller to our stack.
Another interesting controller from our side would be MCAN since we have
some projects with SAMv7 MCU. But those are more long term goals.
Thank you again for your input.
Best regards,
Michal Lenc
On 29. 04. 24 10:56, Christian MAUDERER wrote:
> 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
>
More information about the devel
mailing list