Pin assignment explained

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
gradoj
Posts: 27
Joined: Mon Aug 11, 2014 5:47 pm

Pin assignment explained

Post by gradoj » Mon Aug 11, 2014 7:08 pm

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

Online
User avatar
dhylands
Posts: 3228
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Pin assignment explained

Post by dhylands » Mon Aug 11, 2014 8:16 pm

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.

gradoj
Posts: 27
Joined: Mon Aug 11, 2014 5:47 pm

Re: Pin assignment explained

Post by gradoj » Thu Aug 14, 2014 7:05 pm

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.

Online
User avatar
dhylands
Posts: 3228
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Pin assignment explained

Post by dhylands » Thu Aug 14, 2014 9:18 pm

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.

Online
User avatar
dhylands
Posts: 3228
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Pin assignment explained

Post by dhylands » Thu Aug 14, 2014 9:26 pm

Page 113 of the SD Specifications: https://www.sdcard.org/downloads/pls/si ... t1_301.pdf describes the SPI mode.

gradoj
Posts: 27
Joined: Mon Aug 11, 2014 5:47 pm

Re: Pin assignment explained

Post by gradoj » Mon Aug 18, 2014 2:16 pm

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:

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);

}
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.

Online
User avatar
dhylands
Posts: 3228
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Pin assignment explained

Post by dhylands » Mon Aug 18, 2014 3:00 pm

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:

Code: Select all

$(info Using GNUmakefile)

BOARD = NETDUINO_PLUS_2
$(info BOARD set to $(BOARD))

include Makefile
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.

Code: Select all

GPIO_InitStructure.Pull = GPIO_NOPULL;
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.

gradoj
Posts: 27
Joined: Mon Aug 11, 2014 5:47 pm

Re: Pin assignment explained

Post by gradoj » Mon Aug 18, 2014 10:04 pm

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.

Online
User avatar
dhylands
Posts: 3228
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Pin assignment explained

Post by dhylands » Mon Aug 18, 2014 11:33 pm

OK - then the pin initialization should go into sdcard_init and be wrapped up something like:

Code: Select all

#if defined(MICROPY_HW_SDCARD_POWER_PIN)
...Do the stuff to call HAL_GPIO_Init...
#endif
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.

gradoj
Posts: 27
Joined: Mon Aug 11, 2014 5:47 pm

Re: Pin assignment explained

Post by gradoj » Sun Aug 24, 2014 3:01 am

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 :oops:

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?

Post Reply