STM32CubeMX

[metal]

I downloaded keil v5.11a and managed to learn which software components to add from "Manage run-time environment":
CMSIS: CORE
DEVICE: Startup
stdPeriph Drivers: RCC, GPIO, Framework

I blinked that LED, no pb. But, i came across STM32CubeMX, which seems awesome, but when I look at system_stm32f4xx.c file from CubeMX, its version is 2.1.0, while the version used from "Manage run-time environment" is 1.3.0. Also, opening the project created by CubeMX, keil notifies me that this project is a legacy.

Apparently, from CudeMX I can init peripherals and automatically add HAL functions which required the modification of system_stm32f4xx.c to work with HAL.

Now, where should one go?

[dotm]

Keil support normally. Keil does not know cubemx and expects the legacy std periph driver, thats why you get this message.
Or you simply ditch the keil pack downloader.
Cubemx is almost the same as the standard peripheral library btw, and just another contribution to their huge mess they allready have.

[metal]

Yesterday I read on ST forums that CubeMX is there to stay, I noticed it creates a project that is compatible with keil v4.73, that's why keil v5.11a complains about the legacy support, though it compiles fine, without any problems. I can't remember where I read that there will be a middleware thing but it's not ready yet, may be I am wrong, I don't remember.

I don't understand why they release a software which creates keil v4.73 project file, then create a HAL library which has no full documentation, then ask people on their download pages to use it.

This ARM industry is very confusing indeed.

[metal]

I found this page, the PDF is kinda interesting: http://www.keil.com/appnotes/docs/apnt_266.asp

STMicroelectronics has introduced the new STM32Cube software platform and STM32CubeMX graphical configuration tool. ARM is currently working closely with STMicroelectronics to develop Device Drivers that make use of the STM32Cube libraries and are compatible with CMSIS-Driver API 2.02. At the same time, we plan to integrate STM32CubeMX and Keil MDK such that the code generated by STM32CubeMX will be used to configure the drivers. This will greatly simplify device and driver configuration and provide more robust configurations and drivers.
During this transition phase, developers targeting STM32 devices are required to use the previous version of CMSIS and MDK-Middleware. The new STM32 Device Family Packs providing CMSIS-Driver API 2.02 compliant drivers will carry the major version 2.

User Manual
More manuals

I noticed this incompatibility issue because of an error during compile: Error : USB Host - Install missing component

[bigtoy]

I'll second (or third) the concerns about STM32cube. I haven't used it, however I have used the standard STM32 peripheral libraries. And have found many significant problems with them. I would expect Cube to be the same libraries re-wrapped. Which would mean - do not consider it to be production code. Not at all.

Like I said, I haven't used Cube. But that's been my experience with other STM provided code. Be very careful.

[metal]

What should I use then, I am just new to this ARM world.Is the best way to open the datasheet in one page, and do it the PIC/AVR way?

[dotm]

Is the best way to open the datasheet in one page, and do it the PIC/AVR way?

Definitely not.
I'd say you can use the STM32 Std Peripheral Drivers since you have to rewrite your code anyways when the CMSIS Driver API is done for your STM32 device (if you want to use the CMSIS API then).
The reason is that there are tons of examples out there for the old Std Peripheral Drivers and not so much for Cube, but a lot of the Cube API is similar to the Std Peripheral API, so you may be able to profit from the old Tutorial anyways.
This sucks a little because you allready know that you have to redo your code in the future if you want to make it portable across devices, but you can minimize your efforts with the following considerations:

-Always use as much abstraction as possible, so instead doing things like
GPIOA->BSRR = GPIO_Pin_1
use
GPIO_SetBits(GPIOA, GPIO_Pin_1)
This example is quite trivial since both codephrases tell you basically the whole story but setting flags in USART control registers or similar non-trivial operations acn be hard to read afterwards and will always be device specific. Better let the Middleware do that for you, right now this allows you at least to switch freely across the STM32 range.

-Use the Keil Project Generator, even if anything is not at the last known technology state. since MDK 5 the pack update function is brilliant! And the Configuration Wizard is really helpful.

-Use an RTOS from the beginning on. Yes I know many say you shouldn't but this helps abstract your code further more. And it allows you to use the Keil middleware like USB and the file system. Making your state machine to a RTOS-driven program is very hard when your program is in an advanced state.

-Use C99 Mode and export small functions of your module as __inline functions since you can't know if the compiler does automatic inlining even if you told him. Some of the ST Driver functions are one-liners that would result in a jump anyway.

-The ST Drivers will need to have a little tweaking to perform fast, be sure that when your developing is finished you should (if you use Keil)
.) #undef USE_FULL_ASSERT
.) linker: --inline_type=all
.) compiler: --autoinline
.) compiler: optimize for time

 some general considerations.
- check out the CMSIS-DSP Library before doing anything but basic math. I have rewritten my code with its trigonometric functions and it runs 20x faster now.
- also check out ChibiOs, even if I don't like it because its not CMSIS, it has a very nice HAL for a big range of STM32 devices
- use the Keil Microlib
- check out the Cortex intrinsics before programming your own basic functions. As an example, value saturation can be done with the cpu command set (_ssat, _ussat) I had to learn this the hard way by programming my own routines and afterwards I realized that these are allready available as intrinsic functions

Thats all I can say after 1 Year of intensive Cortex M4 programming.

[sarah90]

What should I use then, I am just new to this ARM world.Is the best way to open the datasheet in one page, and do it the PIC/AVR way?

I'm basically using just gcc/gdb and the (old) STM32 Std Peripheral Drivers. There are some basic Makefiles on github that get you started and you'll end up with a very fast and clean build environment.

CubeMX is basically only required to set up your clock configuration as it is just too complex to deduct from the datasheets. I also like checking pin availability in CubeMx but won't let it generate other code than the clock config.

If you're planning to program for other arm devices as well you may want to look into libopencm3 (http://libopencm3.org/wiki/Main_Page) which provides an api abstraction to many arm devices.

[pablo2048]

If you're planning to program for other arm devices as well you may want to look into libopencm3 (http://libopencm3.org/wiki/Main_Page) which provides an api abstraction to many arm devices.

I personally don't think that libopencm3 is a good way - look at status information - there is lot of things to be resolved and work to do, but commit graphs (https://github.com/libopencm3/libopencm3/graphs/contributors) shows very little advance in this year...

[Ichan]

I just tried the CubeMX with F4-Discovery board as the case, the generated code compiled cleanly with keil mdk arm - but the version on my pc is still 4.72    yeah.. i am lazy enough updating my software tools.

So Metal, if you want to use it then the easiest way is to stick to 4.7x version. I can not comment yet about the cube itself.

-ichan

[metal]

Here we go, keil followed the changes..
 

STMicroelectronics STM32F4 Series Device Support, Drivers and Examples

Code:

 Version: 2.2.0 Keil.STM32F4xx_DFP.2.2.0.pack  Download

PACK based on STMicroelectronics STM32CubeF4 Firmware Package V1.3.0

    STD Peripheral Library components removed

New Device variants introduced matching ST Cube device database

    e.g. STM32F407IG -> STM32F407IGHx or STM32F407IGTx

CMSIS Drivers Version 2 (changed Cclass "Drivers" to "CMSIS Driver")

    Ethernet MAC, USART, I2C, MCI, SPI, USB Device, USB Host

MDK-ARM Example projects require MDK-Middleware 6.1.1 and CMSIS 4.2.0

    Board Support uses Board Interface API from MDK-Middleware (header file names changed)
    Boards: Keil MCBSTM32F400, ST Microelectronics STM32F429I-Discovery, STM32F401C-Discovery, STM32F4-Discovery

Difference to version 2.1.0:

    File stm32f4xx_hal_conf.h moved from component Device::STM32Cube HAL:Common into Device::STM32Cube Framework::Classic
    Updated RTE_Device and USB Device/Host, USART, MCI and SPI drivers
    Updated LCD board interface driver for STM32F429-I Discovery
    Updated ADC board interface driver for MCBSTM32F400

[Ichan]

I am playing with this CubeMX tool, just finished the blinky tutorial on the user manual (UM1718) - i think i will gonna like this tool.

The generated code compiled and run ok on F4Discovery board both with mdk 4.72 and 5.12 - the last one will convert the project to newer format and ask us to choose "software pack". I my self prefer to stay with 4.xx and may replace the 4.72 currently installed with 4.73 which is the most right version for the CubeMX (ver 4.4.0).

I found that the mdk arm 4.xx version can be installed side by side with 5.xx version.

-ichan

[bluex]

I'll second (or third) the concerns about STM32cube. I haven't used it, however I have used the standard STM32 peripheral libraries. And have found many significant problems with them. I would expect Cube to be the same libraries re-wrapped. Which would mean - do not consider it to be production code. Not at all.

Like I said, I haven't used Cube. But that's been my experience with other STM provided code. Be very careful.

I have used STM32 peripheral lib for more than 3 years professionnaly, and I can't agree with you. It has some flows, extremely very few bugs, but it's not that bad. Now, like as ANY peripheral lib, when you use a general purpose lib, there are always compromizes done by the developpers, and you inherits of that. But from my own experience, almost all their code works very fine. The main problem you'll cross that will force you to work with registers directly is not the code of the lib, but the sporadic and sometimes stranges bugs in the physical peripherals themselves (on the STM32).
While most peripherals works correctly, you'll find some strange behaviours with DMA combined with I2C slave for example, DMA that sometimes hangs (when redirected to external RAM) and that you need to retrigger manually. For such cases, the lib is of no help, you need to dive in the datasheets and manage everything by hand.
Now, back to the peripheral lib, if you don't like some behaviours, ST has been kind enought to provide all the sources codes. So nothing is hidden. I can't see myself blaming them about that.
The main problem with ST is the lack of detailed documentation when you want to do some acrobaties with DMA and peripherals.

@metal
Now for CubeXXX tools and lib, it's there to stay. ST is even preparing a GCC based compiler that will be provided by them in near future. The CubeXXX is the start of their strategy to be able to provide ready to use and to upgrade packages.

[bobcat1]

Hi all

I also use the ST library for long time and I find it among the best driver library I use
The only problem it is not optimize for real time ,it look like it was written by a PC software engineer's and not embedded engineer's
Although in most project it is not important since the speed of the MCU cover for it.
Any how I have one project who fail because of using this library and I have to rewrite some of the driver to make it work

All the best

Bobi

[metal]

their libraries are for general use, if you need to work with time critical, you might need to consider real-time OS.

[Ichan]

I got more interest on this STM32CubeMX, trying to find sample projects using this tool on the web got almost no result.

So, how about making a playground for it? Will you guys join in? 

-ichan

[metal]

what's on your mind?

[Ichan]

Make a new thread with subject lets say "Playing with STM32CubeMX" - we share project, experience, and problem using that tool on this thread.

How about? I already have one or two getting started project.

-ichan

[metal]

I am working on uA723 PSU, while I was writing this reply, I had finished the schematic/PCB draft for it, still need some work, more thought about some issues, but I am almost there. I just want to create a PSU which has a good zener reference rather than a bandgap one like LM317, be able to produce very low ripple at its output, this can be only achieved the discrete way.

I have very few STM32F107RCT6 chips, I am willing to learn how to use the ADC, timers, etc.. to create a 7-segment voltmeter/ammeter panel for this project. I understand, very well, that this chip is a waste for such project, but I am ready to waste it for the sake of learning. I can order F031 chips as well, I just need 12-bit ADC, no pb.. it will be a long journey though.. I am fond of those 7-segments thing :- )

[Ichan]

So i just create that thread, hope i wont be lonely in there 

http://www.sonsivri.to/forum/index.php?topic=59095.msg169486#msg169486

Metal, note that currently CubeF1 is not available yet.

-ichan