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
