Re: CAN driver implementation for Xilinx Zynq
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 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
Re: CAN driver implementation for Xilinx Zynq
On Wed, Mar 1, 2023 at 3:14 AM wrote: > > Hello, > > 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 > * ioctl functionality. can_bus_ioctl does not forward the commands and > arguments to can_dev_ops->dev_ioctl. > Is there a reason for that? I propose a command enum that would provide > consistency. > > > @Prashanth S (fishesprasha...@gmail.com) have you already worked on these > points? > > Thanks everyone for your feedback! > > Best regards > Carlo Brokering > > > > ___ > 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
Re: CAN driver implementation for Xilinx Zynq
Hi @carlo.broker...@dlr.de , Once the commands are defined the corresponding command and buffer should be passed as arguments. As the commands are not defined Null and zero are passed as buffer and command respectively. Regards Prashanth S On Thu, 2 Mar, 2023, 2:22 pm , wrote: > Hello @Prashanth S > > > > > I saw in discord there was a discussion for the rework of CAN framework, > so you could start a discussion in this mailing list or in discord. > > Good to know. I’ll have a look there. > > > > > The ioctl commands are not defined for the CAN framework, so NULL and 0 > are passed to dev_ioctl. > > Ok but i don't quite understand how commands are otherwise sent to the bsp > driver. > > Should that only work once defined commands have been discussed and > implemented? > > > > > > Best regards > > Carlo Brokering > > > > > > *Von:* Prashanth S > *Gesendet:* Donnerstag, 2. März 2023 07:25 > *An:* Brokering, Carlo > *Cc:* devel@rtems.org > *Betreff:* Re: CAN driver implementation for Xilinx Zynq > > > > Hi @carlo.broker...@dlr.de , > > > > > the design for the rx data path including the RxFIFO looks promising. If > nobody is working on it yet, I would try to implement it. You said it still > needs to be approved - > > > who do I have to contact for this? > > I saw in discord there was a discussion for the rework of CAN framework, > so you could start a discussion in this mailing list or in discord. > > > > > > I think you misunderstood me about the ioctl api. My main question was > why command and buffer are not passed to the dev_ioctl here: > > > > > > bus->can_dev_ops->dev_ioctl(bus->priv, NULL, 0); > > The ioctl commands are not defined for the CAN framework, so NULL and 0 > are passed to dev_ioctl. > > > > Regards > > Prashanth S > > > > On Wed, 1 Mar 2023 at 21:08, wrote: > > Hello Prashanth S, > > > > the design for the rx data path including the RxFIFO looks promising. If > nobody is working on it yet, I would try to implement it. You said it still > needs to be approved - who do I have to contact for this? > > > > I think you misunderstood me about the ioctl api. My main question was why > command and buffer are not passed to the dev_ioctl here: > > > > bus->can_dev_ops->dev_ioctl(bus->priv, NULL, 0); > > > > Regards > > Carlo Brokering > > > > *Von:* Prashanth S > *Gesendet:* Mittwoch, 1. März 2023 11:53 > *An:* Brokering, Carlo > *Cc:* devel@rtems.org > *Betreff:* Re: CAN driver implementation for Xilinx Zynq > > > > Hello @Carlo Brokering, > > > > > 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. > > All the best for your Internship. > > > > > > > > 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. > > Currently, the CAN framework has minimal rx support. The design of the rx > data path in the CAN Framework is ready (You could use that design if > approved or you can have your own design). > > > > Note: The tx data path has been implemented, it supports multiple open > among different tasks, configurable buffers. > > > > > * ioctl functionality. can_bus_ioctl does not forward the commands and > arguments to can_dev_ops->dev_ioctl. > > > Is there a reason for that? I propose a command enum that would provide > consistency. > > The bsp CAN driver should register the ioctl api with the CAN Framework > for device specific commands (To add commands for hardware independent > functionality the commands can be added before "if (bus == NULL || > bus->can_dev_ops->dev_ioctl == NULL)" statement. > > > > struct can_dev_ops dev_ops (.dev_ioctl member should be registered). > > > > > > > > @Prashanth S (fishesprasha...@gmail.com) have you already worked on > these points? > > > > For the overview of the CAN framework, tx, rx, data paths you can refer > the docs files in the gitlab link (.puml version of the docs are also > available if you needed ( > https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/f42e192afefdd94a66456181f9d169f0728d5b4f) > ). > > > > You can use the gitlab > https://gitlab.com/slpp95prashanth/gsoc-2022/-/tree/can-bsp-docs/can-docs > link for the design documents. > > > > Regards > > Prashanth S > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
AW: CAN driver implementation for Xilinx Zynq
Hello <mailto:fishesprasha...@gmail.com> @Prashanth S > I saw in discord there was a discussion for the rework of CAN framework, so > you could start a discussion in this mailing list or in discord. Good to know. I’ll have a look there. > The ioctl commands are not defined for the CAN framework, so NULL and 0 are > passed to dev_ioctl. Ok but i don't quite understand how commands are otherwise sent to the bsp driver. Should that only work once defined commands have been discussed and implemented? Best regards Carlo Brokering Von: Prashanth S Gesendet: Donnerstag, 2. März 2023 07:25 An: Brokering, Carlo Cc: devel@rtems.org Betreff: Re: CAN driver implementation for Xilinx Zynq Hi @carlo.broker...@dlr.de <mailto:carlo.broker...@dlr.de> , > the design for the rx data path including the RxFIFO looks promising. If > nobody is working on it yet, I would try to implement it. You said it still > needs to be approved - > who do I have to contact for this? I saw in discord there was a discussion for the rework of CAN framework, so you could start a discussion in this mailing list or in discord. > > I think you misunderstood me about the ioctl api. My main question was why > command and buffer are not passed to the dev_ioctl here: > > bus->can_dev_ops->dev_ioctl(bus->priv, NULL, 0); The ioctl commands are not defined for the CAN framework, so NULL and 0 are passed to dev_ioctl. Regards Prashanth S On Wed, 1 Mar 2023 at 21:08, mailto:carlo.broker...@dlr.de> > wrote: Hello Prashanth S, the design for the rx data path including the RxFIFO looks promising. If nobody is working on it yet, I would try to implement it. You said it still needs to be approved - who do I have to contact for this? I think you misunderstood me about the ioctl api. My main question was why command and buffer are not passed to the dev_ioctl here: bus->can_dev_ops->dev_ioctl(bus->priv, NULL, 0); Regards Carlo Brokering Von: Prashanth S mailto:fishesprasha...@gmail.com> > Gesendet: Mittwoch, 1. März 2023 11:53 An: Brokering, Carlo mailto:carlo.broker...@dlr.de> > Cc: devel@rtems.org <mailto:devel@rtems.org> Betreff: Re: CAN driver implementation for Xilinx Zynq Hello @Carlo Brokering, > 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. All the best for your Internship. > > > 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. Currently, the CAN framework has minimal rx support. The design of the rx data path in the CAN Framework is ready (You could use that design if approved or you can have your own design). Note: The tx data path has been implemented, it supports multiple open among different tasks, configurable buffers. > > * ioctl functionality. can_bus_ioctl does not forward the commands and > arguments to can_dev_ops->dev_ioctl. > Is there a reason for that? I propose a command enum that would provide > consistency. The bsp CAN driver should register the ioctl api with the CAN Framework for device specific commands (To add commands for hardware independent functionality the commands can be added before "if (bus == NULL || bus->can_dev_ops->dev_ioctl == NULL)" statement. struct can_dev_ops dev_ops (.dev_ioctl member should be registered). > > > @Prashanth S (fishesprasha...@gmail.com <mailto:fishesprasha...@gmail.com> ) > have you already worked on these points? For the overview of the CAN framework, tx, rx, data paths you can refer the docs files in the gitlab link (.puml version of the docs are also available if you needed (https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/f42e192afefdd94a66456181f9d169f0728d5b4f)). You can use the gitlab https://gitlab.com/slpp95prashanth/gsoc-2022/-/tree/can-bsp-docs/can-docs link for the design documents. Regards Prashanth S smime.p7s Description: S/MIME cryptographic signature ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: CAN driver implementation for Xilinx Zynq
Hi @carlo.broker...@dlr.de , > the design for the rx data path including the RxFIFO looks promising. If nobody is working on it yet, I would try to implement it. You said it still needs to be approved - > who do I have to contact for this? I saw in discord there was a discussion for the rework of CAN framework, so you could start a discussion in this mailing list or in discord. > > I think you misunderstood me about the ioctl api. My main question was why command and buffer are not passed to the dev_ioctl here: > > bus->can_dev_ops->dev_ioctl(bus->priv, NULL, 0); The ioctl commands are not defined for the CAN framework, so NULL and 0 are passed to dev_ioctl. Regards Prashanth S On Wed, 1 Mar 2023 at 21:08, wrote: > Hello Prashanth S, > > > > the design for the rx data path including the RxFIFO looks promising. If > nobody is working on it yet, I would try to implement it. You said it still > needs to be approved - who do I have to contact for this? > > > > I think you misunderstood me about the ioctl api. My main question was why > command and buffer are not passed to the dev_ioctl here: > > > > bus->can_dev_ops->dev_ioctl(bus->priv, NULL, 0); > > > > Regards > > Carlo Brokering > > > > *Von:* Prashanth S > *Gesendet:* Mittwoch, 1. März 2023 11:53 > *An:* Brokering, Carlo > *Cc:* devel@rtems.org > *Betreff:* Re: CAN driver implementation for Xilinx Zynq > > > > Hello @Carlo Brokering, > > > > > 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. > > All the best for your Internship. > > > > > > > > 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. > > Currently, the CAN framework has minimal rx support. The design of the rx > data path in the CAN Framework is ready (You could use that design if > approved or you can have your own design). > > > > Note: The tx data path has been implemented, it supports multiple open > among different tasks, configurable buffers. > > > > > * ioctl functionality. can_bus_ioctl does not forward the commands and > arguments to can_dev_ops->dev_ioctl. > > > Is there a reason for that? I propose a command enum that would provide > consistency. > > The bsp CAN driver should register the ioctl api with the CAN Framework > for device specific commands (To add commands for hardware independent > functionality the commands can be added before "if (bus == NULL || > bus->can_dev_ops->dev_ioctl == NULL)" statement. > > > > struct can_dev_ops dev_ops (.dev_ioctl member should be registered). > > > > > > > > @Prashanth S (fishesprasha...@gmail.com) have you already worked on > these points? > > > > For the overview of the CAN framework, tx, rx, data paths you can refer > the docs files in the gitlab link (.puml version of the docs are also > available if you needed ( > https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/f42e192afefdd94a66456181f9d169f0728d5b4f) > ). > > > > You can use the gitlab > https://gitlab.com/slpp95prashanth/gsoc-2022/-/tree/can-bsp-docs/can-docs > link for the design documents. > > > > Regards > > Prashanth S > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
AW: CAN driver implementation for Xilinx Zynq
Hello Prashanth S, the design for the rx data path including the RxFIFO looks promising. If nobody is working on it yet, I would try to implement it. You said it still needs to be approved - who do I have to contact for this? I think you misunderstood me about the ioctl api. My main question was why command and buffer are not passed to the dev_ioctl here: bus->can_dev_ops->dev_ioctl(bus->priv, NULL, 0); Regards Carlo Brokering Von: Prashanth S Gesendet: Mittwoch, 1. März 2023 11:53 An: Brokering, Carlo Cc: devel@rtems.org Betreff: Re: CAN driver implementation for Xilinx Zynq Hello @Carlo Brokering, > 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. All the best for your Internship. > > > 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. Currently, the CAN framework has minimal rx support. The design of the rx data path in the CAN Framework is ready (You could use that design if approved or you can have your own design). Note: The tx data path has been implemented, it supports multiple open among different tasks, configurable buffers. > > * ioctl functionality. can_bus_ioctl does not forward the commands and > arguments to can_dev_ops->dev_ioctl. > Is there a reason for that? I propose a command enum that would provide > consistency. The bsp CAN driver should register the ioctl api with the CAN Framework for device specific commands (To add commands for hardware independent functionality the commands can be added before "if (bus == NULL || bus->can_dev_ops->dev_ioctl == NULL)" statement. struct can_dev_ops dev_ops (.dev_ioctl member should be registered). > > > @Prashanth S (fishesprasha...@gmail.com <mailto:fishesprasha...@gmail.com> ) > have you already worked on these points? For the overview of the CAN framework, tx, rx, data paths you can refer the docs files in the gitlab link (.puml version of the docs are also available if you needed (https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/f42e192afefdd94a66456181f9d169f0728d5b4f)). You can use the gitlab https://gitlab.com/slpp95prashanth/gsoc-2022/-/tree/can-bsp-docs/can-docs link for the design documents. Regards Prashanth S smime.p7s Description: S/MIME cryptographic signature ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: CAN driver implementation for Xilinx Zynq
Hello @Carlo Brokering, > 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. All the best for your Internship. > > > 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. Currently, the CAN framework has minimal rx support. The design of the rx data path in the CAN Framework is ready (You could use that design if approved or you can have your own design). Note: The tx data path has been implemented, it supports multiple open among different tasks, configurable buffers. > > * ioctl functionality. can_bus_ioctl does not forward the commands and arguments to can_dev_ops->dev_ioctl. > Is there a reason for that? I propose a command enum that would provide consistency. The bsp CAN driver should register the ioctl api with the CAN Framework for device specific commands (To add commands for hardware independent functionality the commands can be added before "if (bus == NULL || bus->can_dev_ops->dev_ioctl == NULL)" statement. struct can_dev_ops dev_ops (.dev_ioctl member should be registered). > > > @Prashanth S (fishesprasha...@gmail.com) have you already worked on these points? For the overview of the CAN framework, tx, rx, data paths you can refer the docs files in the gitlab link (.puml version of the docs are also available if you needed ( https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/f42e192afefdd94a66456181f9d169f0728d5b4f) ). You can use the gitlab https://gitlab.com/slpp95prashanth/gsoc-2022/-/tree/can-bsp-docs/can-docs link for the design documents. Regards Prashanth S ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
CAN driver implementation for Xilinx Zynq
Hello, 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. * ioctl functionality. can_bus_ioctl does not forward the commands and arguments to can_dev_ops->dev_ioctl. Is there a reason for that? I propose a command enum that would provide consistency. @Prashanth S (fishesprasha...@gmail.com) have you already worked on these points? Thanks everyone for your feedback! Best regards Carlo Brokering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
