Pin assignment explained
Pin assignment explained
I noticed in stmhal/boards there is a make-pins.py script. Can someone explain to me how this is supposed to work? Do I modify the .csv file and run script to generate code? If I would like to port this code to a different board where/how do I confirm the pin assignments? Thanks
Re: Pin assignment explained
make-pins.py is run as part of the build process. It takes several files as input:
stmhal/boards/stm32F4xx_af.csv, stmhal/boards/stm32f4xx_prefix.c, and stmhal/boards/BOARDNAME/pins.csv
and it generates the following output files:
build-BOARDNAME/pins_BOARDNAME.c, build-BOARDNAME/genhdr/pins.h, build-BOARDNAME/pins_qstr.h, build-BOARDNAME/genhdr/pins_af_const.h
If you're creating a different board which uses an STM32F4xx processor, then you should create a new file called pins.csv, which should go in your particular board directory.
Look at any of the other boards for an example. Basically this provides a map from the pins that you've made accessible on your board to the cpu pins.
For example in stmhal/boards/PYBV10/pins.csv the line: X11,PC4 says that the X11 board pin is mapped to the PC4 CPU pin.
When you do a build, the file: stmhal/build/PYBV10/pins_PYBV10.c will be generated. This is the C file which creates the Pin objects for your board.
If you're creating a board that uses a different processor, then you may need to create a customized make-pins.py script (I had to do this for the teensy).
If I haven't explained things well enough, feel free to ask more questions.
stmhal/boards/stm32F4xx_af.csv, stmhal/boards/stm32f4xx_prefix.c, and stmhal/boards/BOARDNAME/pins.csv
and it generates the following output files:
build-BOARDNAME/pins_BOARDNAME.c, build-BOARDNAME/genhdr/pins.h, build-BOARDNAME/pins_qstr.h, build-BOARDNAME/genhdr/pins_af_const.h
If you're creating a different board which uses an STM32F4xx processor, then you should create a new file called pins.csv, which should go in your particular board directory.
Look at any of the other boards for an example. Basically this provides a map from the pins that you've made accessible on your board to the cpu pins.
For example in stmhal/boards/PYBV10/pins.csv the line: X11,PC4 says that the X11 board pin is mapped to the PC4 CPU pin.
When you do a build, the file: stmhal/build/PYBV10/pins_PYBV10.c will be generated. This is the C file which creates the Pin objects for your board.
If you're creating a board that uses a different processor, then you may need to create a customized make-pins.py script (I had to do this for the teensy).
If I haven't explained things well enough, feel free to ask more questions.
Re: Pin assignment explained
Okay. That helps. I'm starting to piece things together a little more. I've got a netduino plus 2 board so the micro is the same. I was hoping to work on the sd card port for this board. At first glance it appears wired to SPI3(kind of) but not in a way that I can take advantage of the stm32 spi peripheral. I'm going to dig into the netduino firmware to see what they did. Thanks.
Re: Pin assignment explained
There is a NETDUINO_PLUS_2 board already defined. I did all of my early development on that while I was waiting for the pyboard.
And yes - the sdcard appears to be connected up as 1-bit SPI mode. So the low-level routines for talking with the card will need to be redone.
If you need help with anything, let me know. I have one of the Netduino boards and I'm definitely interested in see better support.
And yes - the sdcard appears to be connected up as 1-bit SPI mode. So the low-level routines for talking with the card will need to be redone.
If you need help with anything, let me know. I have one of the Netduino boards and I'm definitely interested in see better support.
Re: Pin assignment explained
Page 113 of the SD Specifications: https://www.sdcard.org/downloads/pls/si ... t1_301.pdf describes the SPI mode.
Re: Pin assignment explained
Thanks. This is the first time I've worked with an ST microcontroller and I could use a little advice. I've got the sd card inserted switch working on the Netduino Plus 2 but can't seem to get the power control line working. I've included the two functions below I have modified. I think they are what is called here but I don't see the pin changing states:
Any help is appreciated. Any advice on debugging? I have just been rebuilding micropython and jtagging it. What are people using as an IDE to set breakpoints etc? Thanks again.
Code: Select all
>>> sd=pyb.SD
>>> sd.power(0)
True
>>> sd.power(1)
False
>>>
Code: Select all
bool sdcard_power_on(void) {
if (!sdcard_is_present()) {
return false;
}
GPIO_InitTypeDef GPIO_InitStructure;
/* Configure I/O for Power FET */
GPIO_InitStructure.Pin = MICROPY_HW_SDCARD_POWER_PIN.pin_mask;
GPIO_InitStructure.Mode = GPIO_MODE_OUTPUT_OD;
GPIO_InitStructure.Speed = GPIO_SPEED_HIGH;
HAL_GPIO_Init(MICROPY_HW_SDCARD_POWER_PIN.gpio, &GPIO_InitStructure);
HAL_GPIO_WritePin(MICROPY_HW_SDCARD_POWER_PIN.gpio, MICROPY_HW_SDCARD_POWER_PIN.pin_mask, GPIO_PIN_RESET);
return True;
}
void sdcard_power_off(void) {
HAL_GPIO_WritePin(MICROPY_HW_SDCARD_POWER_PIN.gpio, MICROPY_HW_SDCARD_POWER_PIN.pin_mask, GPIO_PIN_SET);
}
Re: Pin assignment explained
Do you have a branch in github somewhere I can look at?
Then I can pull down your branch and try it here.
You didn't include any of the python bindings.
I haven't yet used the JTAG on the board. I tend to debug generic issues using ddd on the host (with the unix version). And I just use old fashioned printf debugging on the micropython board.
When I started out on micropython, I would code up my class, and remove all of the processor specific stuff and then debug on the unix version to make sure my functions were getting called and that I was understanding how things worked.
Are you building using make BOARD=NETDUINO_PLUS_2 ?
Tip: Create a file called GNUmakefile and have it look like:
then you only need to type make (make looks for GNUmakefile before Makefile, so it gives you a chance to do some customizations)
You didn't initialize the Pull field in GPIO_InitStructure.
Normally, I would have put the call to HAL_GPIO_Init in the make_new method, and made the power method just set the pin to 0 or 1.
Then I can pull down your branch and try it here.
You didn't include any of the python bindings.
I haven't yet used the JTAG on the board. I tend to debug generic issues using ddd on the host (with the unix version). And I just use old fashioned printf debugging on the micropython board.
When I started out on micropython, I would code up my class, and remove all of the processor specific stuff and then debug on the unix version to make sure my functions were getting called and that I was understanding how things worked.
Are you building using make BOARD=NETDUINO_PLUS_2 ?
Tip: Create a file called GNUmakefile and have it look like:
Code: Select all
$(info Using GNUmakefile)
BOARD = NETDUINO_PLUS_2
$(info BOARD set to $(BOARD))
include Makefile
You didn't initialize the Pull field in GPIO_InitStructure.
Code: Select all
GPIO_InitStructure.Pull = GPIO_NOPULL;
Re: Pin assignment explained
I'm just working on a local copy right now. Let me do some cleanup and I'll create a branch I can share.
I have not touched any of the python bindings. I was hoping to use the existing SD.power() method just to test it out. I think SD.power() calls sd_card_power_off() or sd_card_power_on() in sdcard.c.
I am using BOARD=NETDUINO_PLUS_2 and thanks for the makefile tip.
I have not touched any of the python bindings. I was hoping to use the existing SD.power() method just to test it out. I think SD.power() calls sd_card_power_off() or sd_card_power_on() in sdcard.c.
I am using BOARD=NETDUINO_PLUS_2 and thanks for the makefile tip.
Re: Pin assignment explained
OK - then the pin initialization should go into sdcard_init and be wrapped up something like:
and the sdcard_power_on and power_off functions should just call HAL_GPIO_WritePin (also protected by the same #if). You should probably also have a delay after turning the power on to allow the card to initialize.
I hadn't looked at the sdcard stuff for a while - ignore my comment about the python binding.
Code: Select all
#if defined(MICROPY_HW_SDCARD_POWER_PIN)
...Do the stuff to call HAL_GPIO_Init...
#endif
I hadn't looked at the sdcard stuff for a while - ignore my comment about the python binding.
Re: Pin assignment explained
The sdcard power on and off are working now and probably were the whole time. I was using the usb connector as ground and it's not grounded
https://github.com/gradoj/micropython
I have created a branch but I haven't got the compile options proper yet. I can wrap the power pin as you suggested but what should I do with the SPI/SDIO difference? I was thinking of creating MICROPY_HW_HAS_SDCARD_SPI and MICROPY_HW_HAS_SDCARD_SDIO but the MICROPY_HW_HAS_SDCARD is used in lots of places where the code is required for both spi and sdio. Would it make sense to just use the NETDUINO_PLUS_2? The cleanest would be to have a sdcard_sdio.c and sdcard_spi.c which both include the same sdcard.h and handle it through the makefile somehow. The code is going to get difficult to read with so many compile switches. Suggestions?
https://github.com/gradoj/micropython
I have created a branch but I haven't got the compile options proper yet. I can wrap the power pin as you suggested but what should I do with the SPI/SDIO difference? I was thinking of creating MICROPY_HW_HAS_SDCARD_SPI and MICROPY_HW_HAS_SDCARD_SDIO but the MICROPY_HW_HAS_SDCARD is used in lots of places where the code is required for both spi and sdio. Would it make sense to just use the NETDUINO_PLUS_2? The cleanest would be to have a sdcard_sdio.c and sdcard_spi.c which both include the same sdcard.h and handle it through the makefile somehow. The code is going to get difficult to read with so many compile switches. Suggestions?