On Wed, Mar 1, 2023 at 3:14 AM <carlo.broker...@dlr.de> 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
