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 <joel at rtems.org> wrote:

>
>
> On Wed, Apr 13, 2022, 10:46 PM Prashanth S <fishesprashanth at gmail.com>
> 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 <ppisa4lists at pikron.com> 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
>>>
>>>