For many peripherals you can change the assigned pins from the "mpconfigboard.h" file. It appears you can change the CAN names, but it does not show the pin number assignments that can be changed. I looked through several other board files hoping for some guidance but did not find a good example.
The default micropython pins for CAN2 are B8 for RX and B9 for TX. But the default DFU pins (if I wanted to bootload over CAN) are B5 for RX and B13 for TX. It seems like it should be easier to change to alternate pins.
How would I go about editing this?
Thanks
Custom board change CAN pins
Custom board change CAN pins
_______________
Travis Travelstead
Travis Travelstead
Re: Custom board change CAN pins
The simplest way is to just set the alternate function on the pin you want.
The defaults are really just for convenience.
The defaults are really just for convenience.
Re: Custom board change CAN pins
Maybe I am not seeing it, but it seems like the CAN interface is one of the few that do not let me pass different pin assignments to, like SPI.
I looked up the pin alternative function from the REPL and both B13 and B5 do not show CAN as options, even though I know from the STM32CUBEMX and the DFU documentation say it is.
How would you go about doing this?
I looked up the pin alternative function from the REPL and both B13 and B5 do not show CAN as options, even though I know from the STM32CUBEMX and the DFU documentation say it is.
How would you go about doing this?
_______________
Travis Travelstead
Travis Travelstead
Re: Custom board change CAN pins
I was able to get this working. Had to dig into the "can.c" file under "ports/stm32"
I was able to change the PB12 to PB5 and test that CAN2 worked with this change. It is strange that this is not as easily configurable as the other communications peripherals.
I was able to change the PB12 to PB5 and test that CAN2 worked with this change. It is strange that this is not as easily configurable as the other communications peripherals.
Code: Select all
// assumes Init parameters have been set up correctly
STATIC bool can_init(pyb_can_obj_t *can_obj) {
CAN_TypeDef *CANx = NULL;
uint32_t GPIO_Pin = 0;
uint8_t GPIO_AF_CANx = 0;
GPIO_TypeDef* GPIO_Port = NULL;
switch (can_obj->can_id) {
// CAN1 is on RX,TX = Y3,Y4 = PB9,PB9
case PYB_CAN_1:
CANx = CAN1;
GPIO_AF_CANx = GPIO_AF9_CAN1;
GPIO_Port = GPIOB;
GPIO_Pin = GPIO_PIN_8 | GPIO_PIN_9;
__CAN1_CLK_ENABLE();
break;
// CAN2 is on RX,TX = Y5,Y6 = PB12, PB13
case PYB_CAN_2:
CANx = CAN2;
GPIO_AF_CANx = GPIO_AF9_CAN2;
GPIO_Port = GPIOB;
GPIO_Pin = GPIO_PIN_12 | GPIO_PIN_13;
__CAN1_CLK_ENABLE(); // CAN2 is a "slave" and needs CAN1 enabled as well
__CAN2_CLK_ENABLE();
break;
default:
return false;
}
_______________
Travis Travelstead
Travis Travelstead
Re: Custom board change CAN pins
Looking at the datasheet, CAN2_TX is alternate function 9 on pin B13. So even though we didn't create a constant for it, you can do this:TravisT wrote: ↑Fri Nov 10, 2017 6:55 amMaybe I am not seeing it, but it seems like the CAN interface is one of the few that do not let me pass different pin assignments to, like SPI.
I looked up the pin alternative function from the REPL and both B13 and B5 do not show CAN as options, even though I know from the STM32CUBEMX and the DFU documentation say it is.
How would you go about doing this?
Code: Select all
can_tx = pyb.Pin(pyb.Pin.cpu.B13, pyb.Pin.AF_PP, pyb.Pin.PULL_NONE, 9)
Passing pins into say the SPI constructor is just a convenience way of having the SPI code do the above (using appropriate AF numbers) for you.
I think that a change could be make to stm32/boards/make_pins.py to get constants created for the CAN pins.
Re: Custom board change CAN pins
Where do I find this in the docs? I'm still working on platform creation starting from G30_TH.can_tx = pyb.Pin(pyb.Pin.cpu.B13, pyb.Pin.AF_PP, pyb.Pin.PULL_NONE, 9)
You don't need to use can_tx after this. Just initializing the pin will make the CAN2_TX signal show up on B13.
JG
John Griessen blog.kitmatic.com
Re: Custom board change CAN pins
You won't find it in the micropython docs. It's just the way that the STM32 chips work.
You can read about it in the "I/O pin multiplexer and mapping" (this is section 8.3.2 in my copy) of the RM0090 Reference Manual for the STM32F405. URL is: http://www.st.com/resource/en/reference ... 031020.pdf
You can read about it in the "I/O pin multiplexer and mapping" (this is section 8.3.2 in my copy) of the RM0090 Reference Manual for the STM32F405. URL is: http://www.st.com/resource/en/reference ... 031020.pdf