CAN driver implementation for Xilinx Zynq

Pavel Pisa ppisa4lists at
Sun Mar 5 16:39:59 UTC 2023

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.Brokering at> 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:

or look at

and related documentation

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

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

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

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

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

Best wishes,

                Pavel Pisa
    phone:      +420 603531357
    e-mail:     pisa at
    Department of Control Engineering FEE CVUT
    Karlovo namesti 13, 121 35, Prague 2
    CAN related:
    RISC-V education:
    Open Technologies Research Education and Exchange Services

More information about the devel mailing list