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. Regards Prashanth S On Tue, 12 Apr 2022 at 19:14, Joel Sherrill <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
