Status of CAN API?

Tue Aug 22 13:35:02 UTC 2023

Hello Philip, Gedare and others interested in RTEMS CAN/CAN FD API,

On Tuesday 22 of August 2023 14:11:22 Philip Kirkpatrick wrote:
> Thank you for your input on this.  I'm still digesting LinCAN, but it looks
> like a good way to go.  On our end, we will likely have some resources to
> throw at this in a few weeks.

LinCAN has been designed as full featured, vendor neutral character driver
API based CAN stack for Linux and RTOS RT Linux kernel with ability
to be accessed from Linux user-land and RT Linux modules in the second case.

  https://ortcan.sourceforge.net/lincan/

But SocketCAN is the choice for Linux kernel CAN support today.
It has nicer API but has it problems on real-time side etc...
Even from our experience with NuttX CAN drivers development
I tend to stay with character driver API for RTEMS in the current
iteration...

Potability of LinCAN to RTEMS and even bare metal HW without scheduler
has been taken in mind. There is a branch can-usb1 which used slightly
modified SJA1000 LinCAN chip driver together with LinCAN infrastructure
to provide low level API (only FIFOs, no POSIX read/write call) in system
less mode to implement USB to CAN converter on old NXP LPC21xx and SJA1000
or newer LPC17xx targets

 https://sourceforge.net/p/ortcan/lincan/ci/can-usb1/tree/embedded/app/usbcan/

We have implemented the companion Linux kernel LinCAN and SocketCAN drivers
which allowed to use even USB converter in addition to ISA and PCI
bus connected CAN controllers... 

> On Thu, Aug 17, 2023 at 4:26 PM Gedare Bloom <gedare at rtems.org> wrote:
> > Hi Phil,
> >
> > On Wed, Aug 9, 2023 at 6:38 AM Philip Kirkpatrick
> >
> > <p.kirkpatrick at reflexaerospace.com> wrote:
> > > Hello,
> > >
> > > Some people on our team here at Reflex are preparing to implement some
> >
> > CAN drivers.  Specifically for TMS570 and for ZynqMP-RPU (side note my
> > latest patch for that on Jun 29th is still sitting there unreviewed).  I
> > was wondering what the current status of the CAN API is.
> > Feel free to ping the patch. At the moment, this email based system is
> > all we have, and sometimes patches may not get a lot of attention
> > especially if no one "owns" it -- such as new BSPs.
> >
> > > I saw in August of last year and API was added and then last month was
> >
> > reverted with this patch:
> > > https://lists.rtems.org/pipermail/devel/2023-July/076013.html
> > > The comment on the patch says the API isn't mature enough for release.
> >
> > What deficiencies need to be resolved in the API, is this being actively
> > worked on, and should we design against this API or is there a different
> > API we should target?

We plan keeping CAN/CAN FD structure (discussed and agreed upon with
Oliver Hartkopp) and keep barely the same read/write code as is in already
included CAN solution. I consider deep redesign of the rest as a must.

> > The implementation of that API was deficient. It did not support
> > multiple read/write transactions, it had a custom-built ring buffer
> > that was not fully vetted, and some other problems related to
> > threads+priorities. I expect to have some time to look at how to
> > provide better CAN support inside of RTEMS. This has been an ongoing
> > discussion I've been having with Pavel Pisa and others for many years
> > now (a decade?). The direction that I will prefer to go is to port
> > LinCAN
> > https://cmp.felk.cvut.cz/~pisa/can/doc/lincandoc-0.3.5.pdf
> >
> > Both Pavel and I are interested in seeing this come through. So far,
> > we mostly do it on volunteer time or as side pieces of other work.
> > Pavel's group has good experience with CAN and CAN FD, and with both
> > TMS570 and the Zynq (non-MP) boards, with Linux, RTEMS, and NuttX. We
> > would be open to collaborating, subject to whatever time or resource
> > constraints everyone has :) Michal Lenc has been working on this topic
> > as a thesis, "CAN FD Support for Space Grade Real-Time RTEMS
> > Executive"

Or initial panned target is our own CTU CAN FD IP Core

  https://canbus.pages.fel.cvut.cz/

which we can test on our MZ_APO Zynq 7k based kits
and have emulation for it in QEMU mainline etc...

There has been James Holley working on Zynq 7k XCAN support
during his intern under Noviumdesigns company funding,
if I remember well. But I am not sure if there has been
some final version released to public. It has been based
on actual RTEMS CAN FIFOs stub and they planned to somehow
fix it but if it. If it is offered under RTEMS mainline
compatible license then it can be updated to CAN API
and FIFOS after rewrite and used for RTEMS XCAN support
in the next step. By the way Zynq-MP and Versal have
advantage that Xilinx included corresponding CAN FD
controllers model into mainline QEMU in CAN subsystem
which we have introduced.

As for TMS570, it is long time on my interrests list
and some models are used in https://www.elektroline.cz
company for which I provide consultations.
Even when I have been forced to use FreeRTOS for Matlab
Rapid Prototyping Platform by former head of the group,
I have lead unpaid parallel project which resulted
in RTEMS GSoC and integration of TMS570LS3137 BSP into
RTEMS mainline. We have not got to work on TMS570LS3137
CAN support for RTEMS, but we have lot of experience with
TMS570 CAN in the frame of our HW and SW TMS570 projects
for Porsche and EATON including N2HET and DMA full offload
of periodic time triggered CAN communication with clock
skew and timing automatic adjustment in N2HET code

https://dspace.cvut.cz/bitstream/handle/10467/70108/F3-DP-2017-Hofman-Martin-Implementace_casem_rizeneho_planovace_v_distribuovanem_bezpecnostne_kritickem_ridicim_systemu.pdf 

Unfortunately my attempt to publish this solution as application
note has been undermined and even usesfull code attachment
to the thesis has been forbidden but people in charge are no
longer part of our faculty so even that code could be reused
for RTEMS now.

> > Regarding LinCAN itself, there is one design challenge to port it,
> > which has to do with the use of internal FIFOs already in LinCAN code
> > base, or to use RTEMS/POSIX message queue style to interface the CAN
> > drivers and userspace. I actually see there are good reasons to
> > support both ways, and may explore exactly that. We have had quite
> > some discussions here on the topic:
> > * https://lists.rtems.org/pipermail/devel/2023-March/074537.html
> > * https://lists.rtems.org/pipermail/devel/2022-April/071235.html
> > * https://lists.rtems.org/pipermail/devel/2013-April/030761.html (for
> > historical good measure)

To move project forward, we have decided to start with LinCAN based
FIFOs design. It is result/confirmation even from our parallel discussion
with Gedare. We can try alternatives later, but use of LinCAN concept
as it has been used for many years by more real-time applications
in GNU/Linux ecosystems is better to start with.

Even that keeping LinCAN as module outside RTEMS would
reduce code duplication, I tend to full integration into RTEMS
mainline and cleaning code out of all compatibility layers.
I.e.: use the LinCAN code as the model for RTEMS native stack.
It would make future reuse in other possible environments
more difficult, but is the best for RTEMS.

We will be happy to cooperate with others on the project
and discuss the options and implementation.
I expect that we will need to start with initial port/
implementation coding ourselves (planned in the frame
of Michal Lenc's theses) and then there will be lot
of space to join for others to review, enhance common
code and work on individual CAN controllers drivers.

There is our local Wiki sandbox for links etc...

  https://gitlab.fel.cvut.cz/otrees/rtems/work-and-ideas/-/wikis/can_fd

but if there is interrest we can move it to 

  https://devel.rtems.org/

even in this stub/initial phase...

Best wishes,

                Pavel

                Pavel Pisa
    phone:      +420 603531357
    e-mail:     pisa at 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