CAN Options and Licensing, Testing, etc

[Joel Sherrill]

On Tue, Apr 12, 2022 at 9:32 PM Prashanth S <fishesprashanth at gmail.com>
wrote:

> Hi Joel,
>
> Have you determined how you will test CAN on BBB?
>
> I planned to test the CAN driver with another BBB running linux. And if
> CAN analyzer is economical then I would use that.
>

OK. I assume you have accounted for all the cables, transceivers, etc.

And should be able to demonstrate CAN Linux <-> on the same hardware to
verify your test setup.

I'm deferring to others for the hardware needed. I just know there has to
be a shopping list.

--joel

>
> Regards
> Prashanth S
>
> On Wed, 13 Apr 2022 at 00:38, Joel Sherrill <joel at rtems.org> wrote:
>
>>
>>
>> On Tue, Apr 12, 2022 at 12:39 PM Oliver Hartkopp <socketcan at hartkopp.net>
>> wrote:
>>
>>> Hi Joel,
>>>
>>> at least for the SocketCAN network layer part the license is a dual
>>> license BSD3/GPLv2
>>>
>>> // SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
>>>
>>> https://elixir.bootlin.com/linux/v5.17.2/source/net/can/af_can.c#L1
>>>
>>> The reason was that we (at Volkswagen) intended the idea, the API, (CAN)
>>> data structures and code could be easily ported to BSD/MacOS/Windows.
>>>
>>> In fact we created a working Windows PoC but CAN hardware vendors had no
>>> interest to unify a open CAN driver API - to maintain their Lock-In :-/
>>>
>>> Today only a few CAN network drivers in linux/drivers/net/can follow
>>> this dual license approach. As they are 'Linux-specific' they are mostly
>>> GPLv2.
>>>
>>
>> Thanks for clarifying that.
>>
>> The PowerPC qoriq network drivers in libbsd are dual licensed and there
>> is some framework included to support Linux drivers in libbsd. That's the
>> extent of my knowledge but it at least means this could be possible to
>> integrate without knowingly diving into a deep pit.
>>
>> It has the disadvantage that CAN support would be tied to using libbsd.
>> That's likely  too heavy for some environments. But might be a good
>> solution if portability of applications is a goal.
>>
>>
>>> Best regards,
>>> Oliver
>>>
>>>
>>> On 12.04.22 19:13, Prashanth S wrote:
>>> > Hi All,
>>> >
>>> > This is to ask for suggestions on implementing the CAN driver for BBB.
>>> >
>>> > Can I proceed with defining driver specific structures for the CAN
>>> > driver or go with adding a generic API layer for ADC and GPIO.
>>>
>>
>> Have you determined how you will test CAN on BBB?
>>
>> I imagine you can use libdebugger to debug CAN.
>>
>> A big part of the community part of GSoC is making sure you are
>> in a good position to succeed. That means knowing how you will
>> test.
>>
>> --joel
>>
>> --joel
>>
>>
>>> >
>>> > Regards
>>> > Prashanth S
>>> >
>>> >
>>> > On Tue, 12 Apr 2022 at 19:14, Joel Sherrill <joel at rtems.org
>>> > <mailto:joel at rtems.org>> wrote:
>>> >
>>> >     Hi
>>> >
>>> >     I didn't want to post this in the other thread and turn it from a
>>> >     technical into licensing discussion but that must be the first
>>> >     filter for a CAN solution for RTEMS if it uses third-party code. If
>>> >     I have extracted the options correctly, we have:
>>> >
>>> >     + LinCAN - GPL
>>> >     + SocketCAN - GPL
>>> >     + NuttX CAN - Apache
>>> >     + CANOpen - Apache
>>> >
>>> >     The licensing alone eliminates two of the solutions.
>>> >
>>> >     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 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.
>>> >
>>> >     And since CANOpen is an independent and long running project, I'd
>>> >     lean to it as the selection.
>>> >
>>> >     Just my thoughts
>>> >
>>> >     --joel
>>> >
>>> >
>>>
>>