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 <ppisa4li...@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 > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
