STM32CubeFx Examples generated by STM32CubeMX

[petr239955]

Posted on February 26, 2016 at 10:34

Hi

CubeMX team

, w

hy are not

firmware

examples for

development boards

written using

STM32CubeMX

?

I think

it would help

to quickly find

errors in

STM32CubeMX

.

Also,

customers should

share 

original ioc file for 

development boards.

Petr #cubemx #firmware-examples-stm32cubemx

[Nesrine M_O]

Posted on March 01, 2016 at 16:39

Hi Petr,

Unfortunately, the *.ioc files for examples under STM32Cube_FW packages are not available now. I confirm that there is a plan to have the initialization code of our examples generated using CUBEMX, and to provide as well the .ioc file. But unfortunately not at the short term.-Syrine-

[LMI2]

Posted on March 07, 2016 at 19:47

I was going to post about this same subject. I too think it is important.

[Ron Koch]

Posted on December 07, 2016 at 15:40

I have the same concern. I'm starting out with an F7 discovery board. I'm trying to use the middleware generated by MX. All the examples seem to use BSP. The interface to higher level applications seems to be different for each so the examples are not useful. I'm close to jettisoning MX and using BSP. But how long will that be supported?

[Asantos]

Posted on December 07, 2016 at 17:30

  I also agree with that. See the link:

https://community.st.com/0D50X00009XkaTjSAJ

 

 Ari.

[aaron239955_stm1_st]

Posted on December 07, 2016 at 19:44

ST should at least call the examples HAL examples, not CubeMX examples.  The name is misleading and sets up expectations that they might be more useful for CubeMX related work than they are.  At least they are using HAL calls instead of old STL code, as the 'CubeMX Examples' used to do.  But they are HAL example code. NOT CubeMX example code.

[Herve PIERROT]

Posted on December 09, 2016 at 11:07

In fact, those examples are STM32Cube examples.

STM32Cube include both FW/API (HAL and LL) and Software Tools (STM32CubeMX)

The examples have been made to be using HAL, you are right, so they are STM32Cube examples.

But as STM32CubeMX is becoming a standard, and that's very nice to see, an ongoing process is converting every single example project of each FW packages in a STM32CubeMX project, including a *.ioc file.

But as you can imagine, this makes a certain amount of projects to update, so this is taking some times. It's never soon enough, but I would say, it will come soon.

[Ron Koch]

Posted on December 09, 2016 at 15:45

Sure it would take some time, but this thread started in February. This is a long time to be stuck between a platform being sunsetted and one I can't figure out how to use. I'm not sure how to proceed. 

[aaron239955_stm1_st]

Posted on December 09, 2016 at 15:57

I had the same problem a while back but I slogged through creating a working CubeMX configuration for the F746 discovery board. At the time I did it, when you chose the exact board, the selection of pin assignments for things like to SDRAM interface and the LCD controller were all wrong. There have been several updates to th libraries since then, so I am not sure if this has been improved or fixed. However I am attaching a current .ioc file that I use for the F746 Discovery board. I am using the STemWin GUI, which needs the LCD controler and SDRAM. The config file has the QSPI interface initialized but I haven't spent time to get that going.

Besides having the configurations correct, there is additional code needed to, for example, use the touch controller on the board, and to finish initializing the SDRAM before use. Those I have taken from the BSP and example code but its a little more problematic for me to attach them.

Hope this helps

________________ Attachments : OScope.ioc.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hz3B&d=%2Fa%2F0X0000000bFo%2Ffaqzlim9uCnUVL3zRTlgN7FcG9e7DDbuIDGCgialgW4&asPdf=false

[Tesla DeLorean]

Posted on December 09, 2016 at 21:30

Unfortunately the concept significantly over-reaches and fails to deliver. We are years into this experiment, and a solid library has been abandoned and replaced by an endless stream of updates and bug fixes. This Microsoft approach to software, where at some point there is hope of fixing everything and getting closure, does not work.

I'm very skeptical of the value of a code generator that spits out large blocks of canned/boiler-plate code. Such a generator is easy to make, and allows for the auto-generation of the examples over a wide array of chips/boards.

The main problem is that everyone is going to use the output code and it will spread into everything, and as such it needs to be thoroughly tested and validated, and manage errors properly. People who rely on code generators aren't going to have the skills to go through it critically to make it production ready.

There needs to be significantly more effort to release bullet-proof and bug free code, and the software group needs to test real-world applications of the code they are generating, and not be satisfied that it merely 'demonstrates' a level of functionality in some very narrow uses cases.

This could perhaps start with a heavier presence here of the software group responsible to focus them on the problems and real-world uses related to their code. Solid and robust code should not need a lot of support, but it is going to take a lot of effort and focus to get to that point.