8000 STM32CubeF4 - a panacea? · Issue #337 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

STM32CubeF4 - a panacea? #337

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
dpgeorge opened this issue Mar 10, 2014 · 9 comments
Closed

STM32CubeF4 - a panacea? #337

dpgeorge opened this issue Mar 10, 2014 · 9 comments
Assignees
@dpgeorge

Comments

@dpgeorge
Copy link
Member

Two weeks ago, ST released a firmware library that seems to be the answer to many of our problems. It's called STM32CubeF4 and is a HAL firmware library for the STM32 series of microcontrollers. At the moment it only supports the STM32F4xx series, but that's fine for the pyboard.

Here are the main points:

  • Is intended as a replacement for the peripheral driver library.
  • Provides a neat HAL for all STM32 devices, adressing issue mbed HAL #11.
  • The HAL is now released under a BSD license, addressing issue Need to work out license of STM libraries #26.
  • Includes updated USB drivers, including host and device.
  • Includes FatFS support (same as the one currently in use, by ChaN).
  • Includes TCP/IP (useful in the future).

See here http://www.st.com/web/en/catalog/tools/PF259243#

I'd say we move to using this new set of libraries ASAP. I'll work on it.
@dpgeorge dpgeorge self-assigned this Mar 10, 2014
@dhylands
Copy link
Contributor

Hey Damien,

I'm willing to help out with this.

How do you want to proceed? Just do it all at once? Or perhaps create a new branch which strips out all of the old peripheral support and start to add in the new stuff?

8000 @dpgeorge
Copy link
Member Author

Thanks Dave, that would be great if you could help.

I'm a fan of "do it all at once", but in this case it's a rather large
change, so lets create a new branch. And if things go wrong, it's easy to
revert and compare.

I would like to retain as much of the STM directory structure as possible,
to make it easy to upgrade in the future and also know which files came
from where.

Something like:

CMCIS/
STMHAL/Inc
STMHAL/Src
FatFs/

I'm open to suggestions on this.

@dhylands
Copy link
Contributor

I created a makefile for Projects/STM32F4-Discovery/Examples/GPIO/GPIO_EXTI and needed the following include directories (starting from withing a gcc diretory inside the above):

INC =  -I../Inc
INC += -I$(TOP)/Drivers/STM32F4xx_HAL_Driver/Inc
INC += -I$(TOP)/Drivers/CMSIS/Device/ST/STM32F4xx/Include
INC += -I$(TOP)/Drivers/BSP/STM32F4-Discovery
INC += -I$(TOP)/Drivers/CMSIS/Include

and needed sources from:

../Src
$(TOP)/Drivers/BSP/STM32F4-Discovery
$(TOP)/Drivers/STM32F4xx_HAL_Driver/Src

Of course, this doesn't include any of he USB stuff.

I was thinking that getting the basic clocks and stuff, and a super-simple UART going we can get back to a REPL and then build up from that.

I'd be inclined to #if 0 out stuff (rather than actually deleting it).

I just thought of another approach, which is probably even better than using a new branch, and that's to create a new platform directory, (say stmhal) which will replace stm once its done. Then its kind of like a new port.

@dhylands
Copy link
Contributor

The makefile I built can be found here:
https://github.com/dhylands/stm32cubef4-gpio-exti

@dhylands
Copy link
Contributor

And the GPIO_EXTI example seems to work fine on my discovery board. The button is glitchy so sometimes I get more than one LED toggle per button push,

@dpgeorge
Copy link
Member Author

I was also thinking to create a completely new port (eg stmhal), since
that's basically what it is. Only issue is that any changes to the
original stm between now and when stmhal is done won't be in the stmhal
port.

But, since the change really needs to be done all at once (ie can't mix old
peripheral and new HAL library), it's probably worth starting from scratch,
building up a basic working REPL, then importing all the functionality from
stm.

So, I suggest creating stmhal.

@blmorris
Copy link
Contributor

Damien and Dave- I have a slightly off-topic request, although this seems like a reasonable place to ask as it is related to board-level I/O configuration.
There are a few remaining compiler macro references to PYBOARD3/4, STM32F4DISC and NETDUINO_PLUS_2 lurking within the code tree, for example within stm/stmperiph/stm324x7i_eval.h, stm324x7i_eval.c, and stm324x7i_eval_sdio_sd.c, which are used to configure the pin and polarity for the SD_DETECT function. (Similar references also remain within usart.c, lcd.c, led.h)
Dave's pin configuration work already removed similar macro references for the user switch, consolidating them in the main board configuration directory; I was wondering if it is possible to do the same for the SD card detect pin.
Removing these macro references will make it possible for me or anyone else to create and maintain a configuration directory for their own boards - at this point it makes little sense to ask for my own directory within the main MicroPython source tree, as my boards are not widely available nor well suited for general purpose MicroPython development anyway.

So far I have been lucky that my choices of pins and polarities for SD Card detect and user switch have been compatible with Pyboard4, or at least close enough to adapt with minimal effort, but I still need to make a few fixes whenever anyone touches Makefile, mpconfigport or mponfigboard.

Thanks!

@dpgeorge
Copy link
Member Author

@blmorris Sounds like a good idea, to make SD_DETECT configurable as the other pins. We'll try to make sure this happens, but remind us again if it doesn't, or, issue a pull request.

@dpgeorge
Copy link
Member Author

Okay, the new Cube HAL has been ported and is now working in the stmhal/ directory.

Please note that the stmhal 7BA8 / port now supersedes stm/. stm/ is now obsolete.

As requested by @blmorris , the SD card detect pin is now configurable in mpconfigport.h.

tannewt pushed a commit to tannewt/circuitpython that referenced this issue Nov 7, 2017
@dhalbert
Merge pull request micropython#337 from tannewt/fix_pin_reset
2148211 
esp8266: Actually disable pins when reset on reload.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dpgeorge dpgeorge

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dhylands @dpgeorge @blmorris
0