GSoC 2022 - CAN API test

[Pavel Pisa]

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