Status of CAN API?

[Philip Kirkpatrick]

Gedare,

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.

-Phil

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?
> >
> 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"
>
> 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)
>
> Gedare
>
> > Thank you,
> > Phil
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230822/12911580/attachment.htm>