Dear Carlo and others, On Friday 03 of March 2023 16:03:52 Gedare Bloom wrote: > On Wed, Mar 1, 2023 at 3:14 AM <carlo.broker...@dlr.de> wrote: > > As part of an internship at the German Aerospace Center, I am currently > > working on the implementation of a CAN driver for a Xilinx Zynq SoC. For > > this I used the existing CAN framework /dev/can/can.h. A merge request > > will follow soon. > > > > > > Here's what I'd like to add to the framework if it hasn't already been > > done: > > > > * RxFIFO. Currently can_bus_read only stores the latest CAN message in > > can_bus->can_rx_msg. There is a FIXME note on this in can.c, line 188, > > but I couldn't find an implementation of it. > > This will be great. Other issues to address in this code base are the > lack of integration with existing RTEMS functionality. Especially > helpful would be to add message queue abstraction layer along with > making a more proper device driver structure. Message queue has the > advantage that it can take care of handling multiple priorities and > synchronization, and reduces the code size and maintenance burden. > > You can see an interface/implementation like this in: > https://git.rtems.org/rtems/tree/bsps/powerpc/gen5200/mscan
or look at https://sourceforge.net/p/ortcan/lincan/ci/master/tree/ and related documentation https://cmp.felk.cvut.cz/~pisa/can/doc/lincandoc-0.3.5.pdf The actual RTEMS can-msg.h has updated version which is prepared for CAN FD for future and has been confirmed by me and Oliver Hartkopp (Linux SocketCAN author) as fitting well to RTEMS https://git.rtems.org/rtems/tree/cpukit/include/dev/can/can-msg.h I think that concept of queues in LinCAN is right for char driver CAN drivers and it worth and could be ported to RTEMS easily. Important question is, if to use CAN specific FIFOs implementation https://sourceforge.net/p/ortcan/lincan/ci/master/tree/lincan/include/can_queue.h or change it to some RTEMS or POSIX queue. That is main point to decide. Then porting of LinCAN code to RTEMS is easy a as main contributor, architecture and mechanism architects etc. I can change license to BSD 2 clauses for RTEMS. Even actual LinCAN license is GPL2 with linking exception to be compatible with RTEMS from the project beginning. By the way, I we have lot of experience with Zynq Zynq 7000 SoCs, its XCAN and even own CTU CAN FD on it under GNU/Linux https://canbus.pages.fel.cvut.cz/ I have tested RTEMS on it in 2017 and with Michal Lenc, my studnet, we have tested actual RTEMS on it at end of 2022 year for motion control with TCP/IP. I can help with advice or even some contributions but important is decision what should be right implementation and how much effort and skills would be invested. I have kept my push at low level during last summer due to my load by other projects and fear, that if I will demand to high level, then it would be hard to implement it and may be full LinCAN like solution with multiple open supported, filtering etc is too complex. But is we can agree on some level I can help to get to that. I think that porting of LinCAN queues to RTEMS is easy task and I can try that in my spare time... I would really to see future-proof CAN/CAN FD support in RTEMS. But on the other hand, I have limited resources, no RTEMS active product at moment, and I understand that others resources are limited too. But on Zynq, I have easy way to test. We have designed and delivered 42 education kits using MicroZed to the university and I have some more produced for myself https://cw.fel.cvut.cz/wiki/courses/b35apo/en/documentation/mz_apo/start 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/ company: https://pikron.com/ personal: http://cmp.felk.cvut.cz/~pisa 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel