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