Re: GSoC - CAN driver for BBB Was: CAN Options and Licensing, Testing, etc

[Pavel Pisa]

Hello Prashanth,

On Thursday 14 of April 2022 20:20:45 Prashanth S wrote:
> This is to summarize the things suggested from the discussions and clarify
> on CAN generic APIs.
>
> Things on the plate:
>
>- CAN driver for BBB.
OK
>- CAN driver for any one of the QEMU supported SoC (SJA1000 on PCI/e on
>x86, Zynq UltraScale+ MPSo on QEMU).
usesfull for testing
>- Generic CAN APIs
yes
>- ADC driver (not using libbsd) for BBB.

it is my opinion, may it be somebody else should express his/her
from other perspective.

> Please correct me if I missed out anything.

> Query on CAN generic APIs:
> With my understanding on the discussions, Should I use the mentioned stacks
> (LinCAN, CANOpen) as reference
CANopen is higher layer, not relevant for the low level code and should
be possible to build above any of the drivers.
LinCAN not strict, may be only some inspiration
> and define the data structures (CAN message header and CAN message
> structures) or port one of the stacks (In case port one of the stacks is
> the right option:
I would suggest to go through CAN message structures of the existing
projects and use one of them or define one which is easy to use
and port. I would help. I do not suggest unsigned long for ID as it is
in LiNCAN for example. I suggest uint32_t. 
> From the suggestions given in the discussions, I could not conclude which
> stack to choose, Considering the future Scalability (both software stack
> and CAN protocol features) and portability) to RTEMS.
The minimal driver can be directly based on MPC5200 direct use
of rtems_message_queue(s), one for Rx and one for Tx

  https://git.rtems.org/rtems/tree/bsps/powerpc/gen5200/mscan

Its message format there

  https://git.rtems.org/rtems/tree/bsps/powerpc/gen5200/include/bsp/mscan.h

Again problematic uint16_t mess_id; which prevents compatability
with extended message format.

I suggest some single bigger unsigned type used with masks for RTR,
EXT and futire BRS and CAN FD flags, flags.

uint8_t  mess_rtr; is not extensible.

It would be great to find if somebody is actually using MPC5200 RTEMS BSP
still and in such case negotiate changes with them. May it be GrLib
unification could be usesfull as well.

I look at

https://git.rtems.org/rtems/tree/bsps/include/grlib/grcan.h#n133

/* CAN-FD MESSAGE */
typedef struct {
uint8_t extended; /* 1= Extended Frame (29-bit id), 0= STD Frame 
(11-bit id) */
uint8_t rtr;  /* RTR - Remote Transmission Request */
uint8_t fdopts;   /* Bit1: 1=Switch bit rate. bit2: 1=FD frame. */
uint8_t len;  /* 0-8, 12, 16, 20, 24, 32, 48 or 64 bytes */
uint32_t id;
union {
uint64_t dwords[8]; /* up to 64 bytes if FD=1 and len>8 */
uint8_t  bytes[64]; /* up to 64 bytes if FD=1 and len>8 */
} data;
} CANFDMsg;

This messageformat look acceptable. The first uint8_t forms in the fact
aligned unit32_t. I would personally put extended, rtr and fdopts
into single masked integer, but this is acceptable. Missing is space
for 16-bit or better at least 32-bit timestamp.

As for the infrastructure/stack, I would prefer to prepare code
for multiple prioritized queues and LinCAN and SocketCAN
provides. But as I have mentioned simple RTEMS queues can be used
for initial proof and change later to something with more
functions would not be problem if API is designed such way,
that it does not need to be changed. 

I offer co-mentor role or possibly even mentor but I would not have
time over whole summer and I have quite lot to do till semester end,
so I can have week or two delay... not ideal for main mentor.

Best wishes,
Pavel
--
Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
company:https://www.pikron.com/
personal:   http://cmp.felk.cvut.cz/~pisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CAN Options and Licensing, Testing, etc

[Prashanth S]

Hi All,

This is to summarize the things suggested from the discussions and clarify
on CAN generic APIs.

Things on the plate:

   - CAN driver for BBB.
   - CAN driver for any one of the QEMU supported SoC (SJA1000 on PCI/e on
   x86, Zynq UltraScale+ MPSo on QEMU).
   - Generic CAN APIs.
   - ADC driver (not using libbsd) for BBB.

Please correct me if I missed out anything.

Query on CAN generic APIs:
With my understanding on the discussions, Should I use the mentioned stacks
(LinCAN, CANOpen) as reference
and define the data structures (CAN message header and CAN message
structures) or port one of the stacks (In case port one of the stacks is
the right option:
>From the suggestions given in the discussions, I could not conclude which
stack to choose, Considering the future Scalability (both software stack
and CAN protocol features)
and portability) to RTEMS.

Please correct me if I am wrong with my understanding.

Regards
Prashanth S


On Thu, 14 Apr 2022 at 18:33, Joel Sherrill  wrote:

>
>
> On Wed, Apr 13, 2022, 10:46 PM Prashanth S 
> wrote:
>
>> Hi Pavel,
>>
>> But if you would fit with writing/porting driver
>>> for some other CAN interface which is available
>>> under QEMU it would be great. I.e. SJA1000 on PCI/e
>>> on x86 and may be some other target or  Zynq UltraScale+
>>> MPSo on QEMU it would be nice to have ability to test
>>> driver by everybody and writing at least one other to BBB
>>> would help to define API which would fit more targets better
>>> even in future.
>>>
>>
>> Yes, Adding a CAN driver in QEMU would be more accessible for everyone to
>> test the APIs. I will try to do that.
>>
>
> Depends on your goal. If porting a CAN stack, it doesn't matter which
> architecture or bsp you are using. You just need an easy way to test it.
> Qemu is that easy way.
>
> If CAN on BBB, then you need to be on hardware and plan for that.
>
>
>> Other option is to add writing BBB CAn controller support
>>> for QEMU, but I think that it would be too much load.
>>>
>>
>> I think QEMU does not have Am335x support (
>> https://wiki.qemu.org/Documentation/Platforms/ARM).
>>
>> Regards
>> Prashanth S
>>
>> On Thu, 14 Apr 2022 at 00:29, Pavel Pisa  wrote:
>>
>>> Dear Prashanth,
>>>
>>> On Wednesday 13 of April 2022 04:32:45 Prashanth S wrote:
>>> > 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.
>>>
>>> I think that testing against Linux kernel is good
>>> option. AM3358 has to CAN controllers so if you can
>>> find pin mux combination to connect CAN transceivers
>>> to both then you can test and load/flood them directly
>>> by the board. So I agree with this as a good environment
>>> for development.
>>>
>>> The BBB is probably relatively accessible for others too.
>>>
>>> But if you would fit with writing/porting driver
>>> for some other CAN interface which is available
>>> under QEMU it would be great. I.e. SJA1000 on PCI/e
>>> on x86 and may be some other target or  Zynq UltraScale+
>>> MPSo on QEMU it would be nice to have ability to test
>>> driver by everybody and writing at least one other to BBB
>>> would help to define API which would fit more targets better
>>> even in future.
>>>
>>> Other option is to add writing BBB CAn controller support
>>> for QEMU, but I think that it would be too much load.
>>>
>>> I suggest to focus mainly on CAN anyway and left ADC as
>>> optional task if the time remains...
>>>
>>> When RTEMS has reasonable CAN API it would be big GSoC
>>> achievement.
>>>
>>> Best wishes,
>>>
>>> Pavel
>>>
>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CAN Options and Licensing, Testing, etc

[Joel Sherrill]

On Wed, Apr 13, 2022, 10:46 PM Prashanth S 
wrote:

> Hi Pavel,
>
> But if you would fit with writing/porting driver
>> for some other CAN interface which is available
>> under QEMU it would be great. I.e. SJA1000 on PCI/e
>> on x86 and may be some other target or  Zynq UltraScale+
>> MPSo on QEMU it would be nice to have ability to test
>> driver by everybody and writing at least one other to BBB
>> would help to define API which would fit more targets better
>> even in future.
>>
>
> Yes, Adding a CAN driver in QEMU would be more accessible for everyone to
> test the APIs. I will try to do that.
>

Depends on your goal. If porting a CAN stack, it doesn't matter which
architecture or bsp you are using. You just need an easy way to test it.
Qemu is that easy way.

If CAN on BBB, then you need to be on hardware and plan for that.


> Other option is to add writing BBB CAn controller support
>> for QEMU, but I think that it would be too much load.
>>
>
> I think QEMU does not have Am335x support (
> https://wiki.qemu.org/Documentation/Platforms/ARM).
>
> Regards
> Prashanth S
>
> On Thu, 14 Apr 2022 at 00:29, Pavel Pisa  wrote:
>
>> Dear Prashanth,
>>
>> On Wednesday 13 of April 2022 04:32:45 Prashanth S wrote:
>> > 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.
>>
>> I think that testing against Linux kernel is good
>> option. AM3358 has to CAN controllers so if you can
>> find pin mux combination to connect CAN transceivers
>> to both then you can test and load/flood them directly
>> by the board. So I agree with this as a good environment
>> for development.
>>
>> The BBB is probably relatively accessible for others too.
>>
>> But if you would fit with writing/porting driver
>> for some other CAN interface which is available
>> under QEMU it would be great. I.e. SJA1000 on PCI/e
>> on x86 and may be some other target or  Zynq UltraScale+
>> MPSo on QEMU it would be nice to have ability to test
>> driver by everybody and writing at least one other to BBB
>> would help to define API which would fit more targets better
>> even in future.
>>
>> Other option is to add writing BBB CAn controller support
>> for QEMU, but I think that it would be too much load.
>>
>> I suggest to focus mainly on CAN anyway and left ADC as
>> optional task if the time remains...
>>
>> When RTEMS has reasonable CAN API it would be big GSoC
>> achievement.
>>
>> Best wishes,
>>
>> Pavel
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CAN Options and Licensing, Testing, etc

[Prashanth S]

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

>
>
> On Tue, Apr 12, 2022 at 9:32 PM Prashanth S 
> 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  wrote:
>>
>>>
>>>
>>> On Tue, Apr 12, 2022 at 12:39 PM Oliver Hartkopp 
>>> 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 >>> > > 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

Re: CAN Options and Licensing, Testing, etc

[Prashanth S]

Hi Pavel,

But if you would fit with writing/porting driver
> for some other CAN interface which is available
> under QEMU it would be great. I.e. SJA1000 on PCI/e
> on x86 and may be some other target or  Zynq UltraScale+
> MPSo on QEMU it would be nice to have ability to test
> driver by everybody and writing at least one other to BBB
> would help to define API which would fit more targets better
> even in future.
>

Yes, Adding a CAN driver in QEMU would be more accessible for everyone to
test the APIs. I will try to do that.

Other option is to add writing BBB CAn controller support
> for QEMU, but I think that it would be too much load.
>

I think QEMU does not have Am335x support (
https://wiki.qemu.org/Documentation/Platforms/ARM).

Regards
Prashanth S

On Thu, 14 Apr 2022 at 00:29, Pavel Pisa  wrote:

> Dear Prashanth,
>
> On Wednesday 13 of April 2022 04:32:45 Prashanth S wrote:
> > 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.
>
> I think that testing against Linux kernel is good
> option. AM3358 has to CAN controllers so if you can
> find pin mux combination to connect CAN transceivers
> to both then you can test and load/flood them directly
> by the board. So I agree with this as a good environment
> for development.
>
> The BBB is probably relatively accessible for others too.
>
> But if you would fit with writing/porting driver
> for some other CAN interface which is available
> under QEMU it would be great. I.e. SJA1000 on PCI/e
> on x86 and may be some other target or  Zynq UltraScale+
> MPSo on QEMU it would be nice to have ability to test
> driver by everybody and writing at least one other to BBB
> would help to define API which would fit more targets better
> even in future.
>
> Other option is to add writing BBB CAn controller support
> for QEMU, but I think that it would be too much load.
>
> I suggest to focus mainly on CAN anyway and left ADC as
> optional task if the time remains...
>
> When RTEMS has reasonable CAN API it would be big GSoC
> achievement.
>
> Best wishes,
>
> Pavel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CAN Options and Licensing, Testing, etc

[Gedare Bloom]

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  wrote:
>
>
>
> On Tue, Apr 12, 2022 at 9:32 PM Prashanth S  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  wrote:
>>>
>>>
>>>
>>> On Tue, Apr 12, 2022 at 12:39 PM Oliver Hartkopp  
>>> 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 >>> > > 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 

Re: CAN Options and Licensing, Testing, etc

[Joel Sherrill]

On Tue, Apr 12, 2022 at 9:32 PM Prashanth S 
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  wrote:
>
>>
>>
>> On Tue, Apr 12, 2022 at 12:39 PM Oliver Hartkopp 
>> 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 >> > > 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

Re: CAN Options and Licensing, Testing, etc

[Pavel Pisa]

Dear Prashanth,

On Wednesday 13 of April 2022 04:32:45 Prashanth S wrote:
> 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.

I think that testing against Linux kernel is good
option. AM3358 has to CAN controllers so if you can
find pin mux combination to connect CAN transceivers
to both then you can test and load/flood them directly
by the board. So I agree with this as a good environment
for development.

The BBB is probably relatively accessible for others too.

But if you would fit with writing/porting driver
for some other CAN interface which is available
under QEMU it would be great. I.e. SJA1000 on PCI/e
on x86 and may be some other target or  Zynq UltraScale+
MPSo on QEMU it would be nice to have ability to test
driver by everybody and writing at least one other to BBB
would help to define API which would fit more targets better
even in future.

Other option is to add writing BBB CAn controller support
for QEMU, but I think that it would be too much load.

I suggest to focus mainly on CAN anyway and left ADC as
optional task if the time remains...

When RTEMS has reasonable CAN API it would be big GSoC
achievement.

Best wishes,

Pavel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CAN Options and Licensing, Testing, etc

[Prashanth S]

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

>
>
> On Tue, Apr 12, 2022 at 12:39 PM Oliver Hartkopp 
> 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 > > > 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

Re: CAN Options and Licensing, Testing, etc

[Pavel Pisa]

Hello Joel, Prashanth and others,

On Tuesday 12 of April 2022 15:43:58 Joel Sherrill wrote:
> + LinCAN - GPL
> + SocketCAN - GPL
> + NuttX CAN - Apache
> + CANOpen - Apache
>
> The licensing alone eliminates two of the solutions.

LinCAN license is GPL with special exception which
I proposed at university to make it usable for embedded
targets withink companies and specially RTEMS

https://sourceforge.net/p/ortcan/lincan/ci/master/tree/lincan/src/can_queue.c

/* To allow use of LinCAN in the compact embedded systems firmware*/
/* and RT-executives (RTEMS for example), main authors agree with next*/
/* special exception: */
/**/
/* Including LinCAN header files in a file, instantiating LinCAN generics */
/* or templates, or linking other files with LinCAN objects to produce*/
/* an application image/executable, does not by itself cause the  */
/* resulting application image/executable to be covered by*/
/* the GNU General Public License.*/
/* This exception does not however invalidate any other reasons   */
/* why the executable file might be covered by the GNU Public License.*/
/* Publication of enhanced or derived LinCAN files is required although.

Which is exactly based on RTEMS previous model, which in the fact I personally
like more than plain BSD, but I agree that it makes writing RTEMS code
even more harder because it disqualifies direct use of both BSD and GPL
sources if this kind of dual license should be kept.

But LinCAN code can be relicensed to almost any kind of license
by me. Only USB support (in separate branch) and some small part
of MPC5200 driver code is written by other people, my former studnets
during their semestral and theses work. There are traces of the original
Arnaud Westenberg and T. Motylewski code of preceding Linux CAN
driver attempts. But probably each their line has been rewritten
during my rearchitect of the code and bringing it to working state.
As the former group to which I have had belong at the time of writting
moved out of the faculty, I can relicense the code with only noticing
department head...

But it is questionable if the LinCAN code is so good start point.
On the other hand, I do not like binding RTEMS CAN drivers to BSD
stack and I do not like RTEMS to strong dependency on it in general.
It s OK for BBB, MPC5200, Zynq etc.. But for imxRT, SAME70, TMS570
an alike smaller which fit RTEMS hard RT control area well
it is blocker.

> 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

Yes I would not mix that and I would not build ADC support on libbsd
at all. I can imagine advantage of SocketCAN and its combination
with libbsd and BSD networking stack, but I really diskike that
dependency for 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. 

QEMU supports SJA1000 on PCI/PCIe cards (Kavser and others) which
is supported by LinCAN and many other drivers. So it can be used with
x86 RTEMS BSPs and it has been tested with Malta MIPS (big endian)
and more ARM targets with PCI on Linux kernel.
But on the other hand BBB or Zynq are more appropriate targets
for real-time and RTEMS. QEMU support for BBB would be nice.
QEMU supports Xilinx CAN and CAN FD controllers. See

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/863043713/Using+CAN+CAN+FD+with+Xilinx+QEMU

It seems that support s available for Zynq UltraScale+ MPSoC and Versal ACAP.
Old Zynq 7000 XCAN does not seem to be supported.
So for RTEMS direct match is to use aarch64 xilinx-versal and xilinx-zynqmp
BSPs... But they would be probably harder to use than BBB
even if only the real HW test are available and BBB is more common
in community.

So ideal project would be to try setup API and add driver to test
it on real HW on BBB and then on x86 or xilinx-zynqmp in QEMU.

As for project timing, I would suggest to start real coding work
earlier, study period should be run before start of conding
period. If all goes well than there can be holiday at the end.
But to make this work well it demand lot of effort and it can be really
valuable and visible.

I am open to suggestions from others, I am adding Chris as he
is probably the best to comment Xilinx optiosn.
 
> And since CANOpen is an independent and long running project, I'd lean to
> it as the selection.


CANopen is layer above CAN and can be solved independently.

We have generic CANopen infrastructure which has been tested
on Linux LinCAN then 

Re: CAN Options and Licensing, Testing, etc

[Joel Sherrill]

On Tue, Apr 12, 2022 at 12:39 PM Oliver Hartkopp 
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  > > 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

Re: CAN Options and Licensing, Testing, etc

[Prashanth S]

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

CAN Options and Licensing, Testing, etc

[Joel Sherrill]

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