CAN3 with STM32 trouble

Applications & Usage
1

Hello. I have some trouble with using libuavcan on STM32.
As I see, the value UAVCAN_STM32_NUM_IFACES defines literally number of current CAN periph in STM32 (CAN1, CAN2…). If I want use CAN1, I must define UAVCAN_STM32_NUM_IFACES as “1”, if CAN2 - as “2”.
Right?
But some STM32 controllers has CAN3 also. And … hence I must define _NUM_IFACES as “3”…
But… I see, that UAVCAN_STM32_NUM_IFACES cannot contain value more than 2.
What can I do for turning on CAN3 using libuavcan? One way I see - redefine values, used for other two CANs?

2

Hi Sergey. The macro UAVCAN_STM32_NUM_IFACES contains the number of CAN interfaces that will be used by the library, and there are two valid values:

  • 1 - only CAN1 will be used
  • 2 - both CAN1 and CAN2 will be used (dual modular redundancy)

The third CAN interface is not supported irrespective of the platform.

3

Thanks, Pavel.
I understood that CAN3 is unsupported.
Well… Just our PCB designer made a mistake, and spent CAN3 wire instead CAN1. And now …
Is it any way to redefine CAN1 to CAN3 with minimal manual operations??

And I see a good idea to have opportunity to switch on/off each CAN in libuavcan separetely from each other (only CAN1, CAN2, CAN3… or both CAN1+CAN2 or CAN2+CAN3+CAN100(fantastic as example))

Also PX4 source code (FMU-v5) initialize all three CANs. It seems, that CAN3 is fail and unused in it. I asked the similar question in PX4 community.

4

Yes, you will need a soldering iron and a piece of wire.

I don’t think it’s going to be useful in the upstream. The stock STM32 driver should be considered an implementation example which you can base your own custom driver on. If you need CAN3, just take the stock driver and modify it as necessary. Supporting every possible combination of CAN peripherals would likely add too much variance into the build process, complicate testing and hurt the general robustness of the driver (which is already pretty bad considering that we support so many different RTOSes and peripheral configurations).

You should also keep in mind that you can’t use CAN2/CAN3 without enabling CAN1 (more info in the reference manual).

5

Unfortunately, BGA package assumes to show any masterclass of manual wiring. I redefined any constants in libuavcan to CAN3 instead CAN1. It works well.
I dont see any reasons not to add CAN3 to library. Take note to this offer.
Thanks.

6

Supporting CAN3 is certainly a good thing. What I am against of is providing additional configuration options for the library allowing the user to use CAN3 or CAN2 instead of CAN1. There should be three regular options:

  • 1 – CAN1
  • 2 – CAN1 and CAN2
  • 3 – CAN1, CAN2, and CAN3
7

Hello, Pavel.
I also agree with your options, described above.
In my situation I redefined CAN1 as CAN3 as it was more light way for testing failed-wired PCB, until we got corrected plate (with CAN1 wired). It was a temporary solution. But in perspective it should be fine to have CAN3 in libuavcan
Thanks.