CAN Options and Licensing, Testing, etc

Tue Apr 12 22:56:43 UTC 2022

Hello Joel, Prashanth and others,

On Tuesday 12 of April 2022 15:43:58 Joel Sherrill wrote:
> + LinCAN - GPL
> + SocketCAN - GPL
> + NuttX CAN - Apache
> + CANOpen - Apache
>
> The licensing alone eliminates two of the solutions.

LinCAN license is GPL with special exception which
I proposed at university to make it usable for embedded
targets withink companies and specially RTEMS

https://sourceforge.net/p/ortcan/lincan/ci/master/tree/lincan/src/can_queue.c

/* To allow use of LinCAN in the compact embedded systems firmware        */
/* and RT-executives (RTEMS for example), main authors agree with next    */
/* special exception:                                                     */
/*                                                                        */
/* Including LinCAN header files in a file, instantiating LinCAN generics */
/* or templates, or linking other files with LinCAN objects to produce    */
/* an application image/executable, does not by itself cause the          */
/* resulting application image/executable to be covered by                */
/* the GNU General Public License.                                        */
/* This exception does not however invalidate any other reasons           */
/* why the executable file might be covered by the GNU Public License.    */
/* Publication of enhanced or derived LinCAN files is required although.

Which is exactly based on RTEMS previous model, which in the fact I personally
like more than plain BSD, but I agree that it makes writing RTEMS code
even more harder because it disqualifies direct use of both BSD and GPL
sources if this kind of dual license should be kept.

But LinCAN code can be relicensed to almost any kind of license
by me. Only USB support (in separate branch) and some small part
of MPC5200 driver code is written by other people, my former studnets
during their semestral and theses work. There are traces of the original
Arnaud Westenberg and T. Motylewski code of preceding Linux CAN
driver attempts. But probably each their line has been rewritten
during my rearchitect of the code and bringing it to working state.
As the former group to which I have had belong at the time of writting
moved out of the faculty, I can relicense the code with only noticing
department head...

But it is questionable if the LinCAN code is so good start point.
On the other hand, I do not like binding RTEMS CAN drivers to BSD
stack and I do not like RTEMS to strong dependency on it in general.
It s OK for BBB, MPC5200, Zynq etc.. But for imxRT, SAME70, TMS570
an alike smaller which fit RTEMS hard RT control area well
it is blocker.

> My other concern was how you were going to test the drivers you wrote.
> Pavel mentions CAN in qemu.
> Perhaps the project should drop the ADC

Yes I would not mix that and I would not build ADC support on libbsd
at all. I can imagine advantage of SocketCAN and its combination
with libbsd and BSD networking stack, but I really diskike that
dependency for ADC

> and focus on a CAN solution using the BSP supported by Qemu along
> with whatever analysis tools Pavel recommends. I am sure Pavel
> has some driver code for the Qemu path (not sure if it is in RTEMS
> or not) This would move the project from a single driver to trying
> to provide a CAN solution. This is much more valuable to the project
> long term. 

QEMU supports SJA1000 on PCI/PCIe cards (Kavser and others) which
is supported by LinCAN and many other drivers. So it can be used with
x86 RTEMS BSPs and it has been tested with Malta MIPS (big endian)
and more ARM targets with PCI on Linux kernel.
But on the other hand BBB or Zynq are more appropriate targets
for real-time and RTEMS. QEMU support for BBB would be nice.
QEMU supports Xilinx CAN and CAN FD controllers. See

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/863043713/Using+CAN+CAN+FD+with+Xilinx+QEMU

It seems that support s available for Zynq UltraScale+ MPSoC and Versal ACAP.
Old Zynq 7000 XCAN does not seem to be supported.
So for RTEMS direct match is to use aarch64 xilinx-versal and xilinx-zynqmp
BSPs... But they would be probably harder to use than BBB
even if only the real HW test are available and BBB is more common
in community.

So ideal project would be to try setup API and add driver to test
it on real HW on BBB and then on x86 or xilinx-zynqmp in QEMU.

As for project timing, I would suggest to start real coding work
earlier, study period should be run before start of conding
period. If all goes well than there can be holiday at the end.
But to make this work well it demand lot of effort and it can be really
valuable and visible.

I am open to suggestions from others, I am adding Chris as he
is probably the best to comment Xilinx optiosn.

> And since CANOpen is an independent and long running project, I'd lean to
> it as the selection.

CANopen is layer above CAN and can be solved independently.

We have generic CANopen infrastructure which has been tested
on Linux LinCAN then SocketCAN API and I have running it even
on NuttX above its character driver API.

http://ortcan.sourceforge.net/vca/

https://cmp.felk.cvut.cz/~pisa/can/doc/ocera-canopen-ug.pdf

But the code would need to be extended with CANopen FD support.
I have been in invited academic guest position at the CANopen
FD standard SIG group meetings and even proposed some minor
tweaks. So I have some background knowledge to help there.
Our university is CiA member so we have access to all
info and I have preliminary standard copies which can be
probably shared with people cooperating with us.
But it is large amount of work which would worth more
people and better funding.

Best wishes,

Pavel