CAN Options and Licensing, Testing, etc

[Prashanth S]

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

 Ok, that will be helpful to verify the hardware test setup.

Regards,
Prashanth S

On Thu, 14 Apr 2022 at 00:52, Joel Sherrill <joel at rtems.org> wrote:

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