Can you tell me what the CAN_P1 parameters are used for, like CAN_P1_UC_PROTOCOL=
As in my image above I would expect CAN_D1_PROTOCOL and CAN_D1_DRIVER not a mixture of CAN_D1_PROTOCOL and CAN_P1_DRIVER when CAN_D1_DRIVER exists in the documentation.
I wonder, does the current mechanism also allow running UAVCAN and a 11bit protocol at the same time on one bus (which would probably imply two drivers for one bus)? The UAVCAN pages explicitly mention that scenario.
What is explicitly mentioned in documentation is that if there are other devices comunicating with CAN 2.0A then UAVCAN can live with the presence of their communication.
Two drivers for one bus obviously will not work in current code.
well, I think it wouldn’t/shouldn’t be really difficult to extend the mechanism to allow to register a driver for 29bit and one for 11bit. In the low level driver it would be just a case testing if it is 29bit or 11bit for calling the appropriate driver … the libcanard is made such that it can be used for 29bit and 11bit, so I would be surprised if this wouldn’t be so for libuavcan too. Just thinking about Code Bounty for DJI CANBus.
Anyway, you answered my question Thx.
Hello，thank u for your sharing.I am a new man for UAVCAN ,and I have some problem about how does the Ardupilot node broadcast its message in the APM program. now I can open the CAN port and make my PC receive some 1HZ data through a CAN-USB equipment from my pixhawk.what should I do to continue my study.THANK U!
There really is no need to use the two buses that way. Remember CANbus devices are smart devices. So the bus is equal opportunity. The second bus is designed for redundancy. Which means you can have two devices with one being the backup for the primary.
OK. Look forward to seeing how this all goes. Have some friends who design/build a commercial product that separates the buses between actuators and sensors. My understanding is it was for possible noise on the actuator bus but I have no idea if that’s really required.