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