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