CAN: added CAN_Dn_PROTOCOL2 for 11 bit auxillary protocol

[tridge]

This allows for a 2nd CAN protocol specified by CAN_Dn_PROTOCOL2. This protocol needs to use 11 bit addressing and the same CAN bitrate as the DroneCAN driver (usually 1MBit)
With this enabled users no longer need to dedicate a CAN bus for devices such as Benewake CAN lidar, USD1 radar and various EFI CAN ECUs
Tested with both SITL and a CubeOrangePlus with a Benewake Lidar

[IamPete1]

If its DroneCAN only shouldn't the param live down a level with the DroneCAN params?

It would be nice to bypass the 11 bit limit for scripting so it can be used to add support for new/bespoke DroneCAN messages.

This will be very useful.

[tridge]

If its DroneCAN only shouldn't the param live down a level with the DroneCAN params?

It is only DroneCAN at the moment, but in principle other protocols (eg. Piccolocan) could implement this by implementing the add_11bit_driver() method.
Structurally, this is principally a AP_CANManager feature, and from the point of view of most end-users using DroneCAN they are adding a 2nd protocol. The restriction of only 11bit comes from not being able to reliably distinguish protocols that do the same addressing scheme.

It would be nice to bypass the 11 bit limit for scripting so it can be used to add support for new/bespoke DroneCAN messages.

that would be nice, but we'd need to work out how to do that. I suspect we'd need to be able to pass a list of message IDs we want to get in scripting so we don't get all messages (similar to the filter list in MAVCAN). Then we'd need to make the DSDL compiler generate lua bindings. That is quite a large project.

[IamPete1]

that would be nice, but we'd need to work out how to do that. I suspect we'd need to be able to pass a list of message IDs we want to get in scripting so we don't get all messages (similar to the filter list in MAVCAN). Then we'd need to make the DSDL compiler generate lua bindings. That is quite a large project.

I think to start with a virtual mirror would be OK, just as if you had two physical CAN ports connected to the same bus. That is the current solution to the issue. Fancy filters would be nice, but they only apply to DroneCAN.

[IamPete1]

Also once this is supported for more protocols you might want the 29 bit protocol as the auxiliary and the 11 bit as the primary.

[tridge]

Also once this is supported for more protocols you might want the 29 bit protocol as the auxiliary and the 11 bit as the primary.

that would be possible of course, but can you give an example of a use case?

[rmackay9]

Maybe we should add a comment to say that PROTOCOL should be set to DroneCAN for this to work.

[rmackay9]

Not my area really but it looks ok to me.

[EosBandi]

@tridge, Can we add an exception for scripting drivers as secondary driver, and instead of using 11bit addressing, we can pass raw messages? This allows the use of DroneCAN devices from scripting without connecting the two buses together. It will work well with this #25703