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: 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
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: 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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
--------------------------------------------
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
