57c873d304
this disables SLCAN if enabled using CAN_SLCAN_CPORT and SERIALn_PROTOCOL=22 when we are armed, to reduce load on the CAN thread from the very inefficient SLCAN processing |
||
|---|---|---|
| .. | ||
| AP_CANDriver.cpp | ||
| AP_CANDriver.h | ||
| AP_CANIfaceParams.cpp | ||
| AP_CANManager.cpp | ||
| AP_CANManager.h | ||
| AP_CANSensor.cpp | ||
| AP_CANSensor.h | ||
| AP_CANTester.cpp | ||
| AP_CANTester.h | ||
| AP_CANTester_KDECAN.cpp | ||
| AP_CANTester_KDECAN.h | ||
| AP_SLCANIface.cpp | ||
| AP_SLCANIface.h | ||
| README.md | ||
README.md
Testing And Debugging
In case unavailability of all the CAN modules that we support, I have created a CAN Driver called CANTester. Currently there are following modes inside CANTester:
1: TEST_LOOPBACK
This test verifies if the low level ifaces are functioning properly. To do that messages are sent so as to ensure TX buffers are filled to the max, and also read the data of the bus. Sequence of incoming data is tested, and also that no transmitted packet was dropped during transmit.
2: TEST_BUSOFF_RECOVERY
This test is only applicable to boards with H7 chip, where the bus off needs to be handled manually. This test is implemented to check if Bus off recovery is handled and recovered properly. Busoff error can be generated by simply shorting the CANH and CANL.
3: TEST_UAVCAN_DNA
This test simply creates a uavcan node allocation client and tries to get node allocated, the allocated node needs to match the requested node id for success. This tests AP_UAVCAN and underlying DNA library.
4: TEST_TOSHIBA_CAN
This test simply emulates a ToshibaCan ESC on a bus and handles the data sent by Toshiba CAN driver, and and also responds with ESC telemetry.
5: TEST_KDE_CAN
This test simply emulates a KDECAN ESC on a bus and handles the data sent by KDE CAN driver, and and also responds with ESC telemetry. Need to supply this command long MAV_CMD_PREFLIGHT_UAVCAN 1 after enabling KDECAN because need to do Enumeration before use.
A lot more tests will be needing to be added overtime to ensure robustness and maintainability of CAN Ecosystem.
Testing under SITL
https://github.com/linux-can/can-utils contains a nice set of utility to do CAN related testings on Linux system. I used Ubuntu for this development, for Ubuntu systems you can simply download this tool using sudo apt-get install can-utils
Following are the common commands that can be used while testing or developing:
- Create Virtual CAN Interface:
sudo modprobe vcan
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0
sudo ip link add dev vcan1 type vcan
sudo ip link set up vcan1
- Route one CANSocket to another
sudo modprobe can-gw
sudo cangw -A -s vcan0 -d vcan1 -e
sudo cangw -A -s vcan1 -d vcan0 -e
- Delete routes
sudo cangw -D -s vcan0 -d vcan1 -e
sudo cangw -D -s vcan1 -d vcan0 -e
- Route SLCAN to VCAN, this allows connecting CAN devices to SITL run via CAN Adapter like the one running in Ardupilot itself.
sudo modprobe slcan
sudo slcan_attach -f -s8 -o /dev/ttyACM0
sudo slcand ttyACM0 slcan0
sudo ifconfig slcan0 up
sudo cangw -A -s vcan0 -d slcan0 -e
sudo cangw -A -s slcan0 -d vcan0 -e
- Dump can messages:
sudo candump vcan0