stm32f4 getting started

Comments

4 comments

  • Avatar
    frank meyer

    First, I can't comment on using a Mac.

    Second, I'm not sure about your experience, i.e. where to begin. Mac users are usually associated with "I don't care how it works internally if it does it's job" (no offence intended).

    And you should note that Crossworks is not directly supported by ST. There are 'precooked' examples in the peripheral Libs for Keil-MDK, IAR, Atollic, and Tasking, but not Crossworks. So, you need some manual work.

    But as a starting point:

    First, get the "STM32F4 DSP and Std.Peripheral Library" from ST's page, which is about 40Mb, and unpack it somewhere.

    Then, you need to download/install the support packages for STM32, best done inside Crossworks. These are the STM32 CPU support package, the CMSIS support packages (CMSIS 3 is latest), and the "STM32F4xx DSP and Standard Peripherals Library Updates" packages. The latter one presumes an already installed peripheral lib, as mentioned above.

    As mentioned above, there are no 'ready to go' examples for Crossworks, you will need to do it yourself. But I briefly explain how build one of those examples.

    First, choose your example - they are in .../STM32F4xx_DSP_StdPeriph_Lib_V1.0.1/Project/STM32F4xx_StdPeriph_Examples/

    I would recomment something like SysTick or GPIO/IOToggle.

    Now, create a Crossworks project, selecting the "Manufacturers / STMicroelectronics" and the project template "Generic STM32 /  executable for STMicroelectronics STM32".  In the upstarting wizzard, slect the proper choices for your board - this is described in the Crossworks manual, I'm not going to dwell on this her in detail.

    The wizzard creates a 'main.c', which includes a '__cross_studio_io.h' file and does a 'debug_printf()'. You can go ahead and compile & run this. This is the simpler way, without touching ST's peripheral Libs here.

    To get such a Peripheral Libs example working, I go to the folder selected above (e.g. .../STM32F4xx_DSP_StdPeriph_Lib_V1.0.1/Project/STM32F4xx_StdPeriph_Examples/GPIO/IOToggle), and copy all file into the Crossworks project folder. This are just a few, including a new 'main.c'.

    As said, no precooked example - here you have to make some manual settings. (Other toolchains have wizzards that do this settings automatically if you choose the right controller or board.) This means settings and changes in the project properties. This again is explained in the Crossworks manual.

    At first, add this source files copied to the project. Then, open 'stm32f4xx_conf.h' and comment out every include except 'misc.h', 'stm32f4xx_gpio.h' and 'stm32f4xx_rcc.h' - if you follow this example. Add the path  '.../STM32F4xx_DSP_StdPeriph_Lib_V1.0.1/Libraries/STM32F4xx_StdPeriph_Driver/inc'   to this include files to your project properties. Then, you need to add the regarding *.c file, i.e. 'misc.c', 'stm32f4xx_gpio.c' and 'stm32f4xx_rcc.c'. They are located the '../src' subfolder where the includes reside. You will need to add the folders .../STM32F4xx_DSP_StdPeriph_Lib_V1.0.1/Libraries/CMSIS/Include' and .../STM32F4xx_DSP_StdPeriph_Lib_V1.0.1/Libraries/CMSIS/Device/ST/STM32Fxx/Include', too.

    Additionally, you need to define the preprocessor macro 'USE_STDPERIPH_DRIVER' in the project properties. IYou might need to check the predefined 'HSE_VALUE" in 'stm32f4xx.h', too. It is usually defined to 25.000.000 Hz, and does at least not match for the discovery board, where the ext. quartz is 8MHz. But that latter setting is not critical to get started. Only timer values and UART baudrates would not match, but it would build and run anyway.

    I may have forgotten something, just give a feedback here.

    0
    Comment actions Permalink
  • Avatar
    Post

    This HowTo is very useful. We switched from a M4 back to a M3 CPU because getting the compiler and library to work was like entering an impenetrable jungle. In addition, ST changed their peripheral library too, it was really a nightmare. We will probably use a NXP M4 CPU without any peripheral library. Programming peripherals in C is real work and always preferable to fiddling around with different software packages that do not work together. If we stay with ST, we will follow your recommendations.

    0
    Comment actions Permalink
  • Avatar
    Florian Augustin

    So I have to add the needed c-files from the src-folder to the source-files in the project?

    Is it a bad idea to include all c-files from src-folder and turn on optimization level 1 or more?? Won't the complier throw away the unnecessary c-files?

    0
    Comment actions Permalink
  • Avatar
    frank meyer

    So I have to add the needed c-files from the src-folder to the source-files in the project?

    Assuming you mean '.../STM32Fxxx_StdPeriph_Lib_Vx.x.x/Libraries/STM32F4xx_StdPeriph_Driver/src'  - not necessarily. I leave them in the .../src subfolder. They are part of the peripheral library, and not assumed to change. I usually add them to the project by right-clicking on the Source folder in the project, and selecting "Add existing files..." in this context menu.

    The source code and generated object files are than shared among all projects that use them - I don't see a problem here. Changing the optimization level or other project properties might also change the generated object code, which neither should be a problem.

     

    Is it a bad idea to include all c-files from src-folder and turn on optimization level 1 or more?? Won't the complier throw away the unnecessary c-files?

    That should be no problem. Albeit, as I believe, the linker will sort out unused functionality, and remove uncalled functions even at optimisation level 0.

    But for one thing it bloats the project for backup/restore, and may confuse others dealing with the project (... that may include you, six month later ;-) )

    0
    Comment actions Permalink

Please sign in to leave a comment.