Hello Prashanth S and others, I am copying reply to the list for recrd and others consideration
On Sunday 19 of June 2022 17:30:16 Christian Mauderer wrote: > Would that be a generic test for the CAN API that all BSPs can run? Or > would it be a hardware specific one? The CAN base test can be HW independent when system is brought up and CAN interface is configured. Even bitrate and actual bring up can be target independed if the driver provides common IOCTL to setup bitrate, sampling point etc. common way. Only speed has to be changed for for case when transmitter cannot handle given rate. And for sure you need to know if the interface is CAN FD capable. Even for really thorough performance testing of the driver, it is enough to to implement function which receives each received frame, decreases CAN ID by one and sends it back. The ID decrease is required to increase priority of reply Tx message which ensures that tester flood does not block the reply. This test has been used by Jan Charvat during testing of NuttX ESP32C3 CAN driver testing https://dspace.cvut.cz/bitstream/handle/10467/101692/F3-DP-2022-Charvat-Jan-NuttX-RTOS-CAN-Bus-Driver-for-Espressif-ESP32C3.pdf You can use Linux kernel based system on the side of the tester and if the latency tester side provides HW timestamping then you can retrieve really precise statistic/characteristic of the HW. I infrastructure has been used in past even to attest RTEMS CAN driver on MPC5200. If you have two interfaces, you can forward messages from one to another and flood system. We have done such testing for Oliver Hartkopp to attest Linux kernel CAN gateway. The code has been updated by Matej Vasilevski during his thesis https://dspace.cvut.cz/bitstream/handle/10467/101450/F3-DP-2022-Vasilevski-Matej-vasilmat.pdf The other option is to use our old VCA abstraction which for CAN provides compatability between LinCAN, SocketCAN and NuttX CAN API and includes canping utility with master and slave side for throughput testing. All is part of OrtCAN project http://ortcan.sourceforge.net/ CAN ping https://sourceforge.net/p/ortcan/canping/ci/master/tree/ The interfacing to RTEMS API on libVCA side would be easy. The file to connect library to SocketCAN, LinCAN or NuttX is singe file, NuttX example https://sourceforge.net/p/ortcan/ortcan-vca/ci/master/tree/libvca/vca_inuttx.c So I think there are many options, simple loop to read aceh message and send it with ID-1 is simple and usesfull step tos tart. Best wishes, Pavel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel