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 <j...@rtems.org> wrote: > > > > On Tue, Apr 12, 2022 at 9:32 PM Prashanth S <fishesprasha...@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 <j...@rtems.org> wrote: >>> >>> >>> >>> On Tue, Apr 12, 2022 at 12:39 PM Oliver Hartkopp <socket...@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 <j...@rtems.org >>>> > <mailto:j...@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 >>>> > >>>> > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
