CAN Options and Licensing, Testing, etc

Wed Apr 13 19:37:42 UTC 2022

There's a nice tutorial at
https://www.thomas-wedemeyer.de/de/electronic/arm/beaglebone/canbus-python/
to use BBB with CAN on Linux via Python SocketCAN.

Here's a parts list for a 2-node CAN bus:
Qty 2x, BeagleBone Black Rev C - 4GB, https://www.adafruit.com/product/1996

Qty 2x, USB to TTL Serial Cable - Debug / Console Cable for Raspberry
Pi, https://www.adafruit.com/product/954 (OPTIONAL)

Qty 2x, USB Extension Cable - 3 meters / 10 ft long,
https://www.adafruit.com/product/993 (OPTIONAL but highly recommended)

Qty 2x, SD/MicroSD Memory Card (8 GB SDHC),
https://www.adafruit.com/product/1294 (1 required, 2 recommended: 1
for flashing debian and 1 for rtems)

Qty 1x, Through-Hole Resistors - 100 ohm 5% 1/4W - Pack of 25,
https://www.adafruit.com/product/4293

Qty 1x, Through-Hole Resistors - 220 ohm 5% 1/4W - Pack of 25,
https://www.adafruit.com/product/2780

Qty 1x, SEGGER J-Link EDU - JTAG/SWD Debugger,
https://www.adafruit.com/product/1369 (OPTIONAL)

Qty 1x, Inland 400 Tie-Points Breadboard - 3 Pack,
https://www.microcenter.com/product/613877/inland-400-tie-points-breadboard---3-pack

Qty 1x, Inland Dupont Jumper Wire 20cm - 3 Pack,
https://www.microcenter.com/product/613879/inland-dupont-jumper-wire-20cm---3-pack
You will need F-M and F-F wires, but good idea to have M-M jumpers around too.

Qty 1x, 4-port USB 2.0 hub,
https://www.microcenter.com/product/486384/inland-4-port-usb-20-hub
(OPTIONAL)

>From robotshop.com, Qty 2x, Waveshare CAN Board SN65HVD230
https://www.robotshop.com/en/waveshare-can-board-sn65hvd230.html

>From saleae, Qty 1x, Logic 8, request an open-source/educational
discount at https://www.saleae.com/ (OPTIONAL)

On Wed, Apr 13, 2022 at 1:22 PM 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
>>>> >
>>>> >