CAN Options and Licensing, Testing, etc

[Prashanth S]

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.

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
>> >
>> >
>>
>