Any positive feedback on Cube ecosystem from commercial users?

[sasha]

Posted on June 11, 2015 at 05:04

Hi, I'm evaluating using Cube + MX for a commercial project.  Seems like public opinion is pretty negative about this tool and ecosystem however.  Has anyone had a positive experience in using Cube for a commercial project?

These are my main concerns:* Buggy HAL libraries* Code generation tool producing messy code, have to carefully place user code between sections* No way to add user code to header files #cube #stm32cubemx

[markb]

Posted on June 11, 2015 at 07:52 Hi, I am currently developing 2 small scale commercial projects based on the STM32F405 and the HAL. It's working for me because I have coded around the bugs in the library (that I know about!) and do a lot of testing. The HAL libraries do seem to be of a shockingly bad quality and they (ST) don't appear to be in any hurry to fix the bugs which is worrying. Without version control (git), I couldn't imagine being able to use the HAL with any hope of producing a working product. But with version control, it's possible to maintain a stable  version of the code which can be updated when ST produce a new release. Cheers, Mark

[sasha]

Posted on June 11, 2015 at 09:20

Thanks for the reply Mark, 

Are you using the Code Generation Tool?  It's certainly helpful, but I'm definitely concerned it's going to mash my code at some point in the future...In hindsight do you think it would be better to stick to using the SPL?  This is my first project using ARM core (10+yrs experience with AVR Megas, so bit of a learning curve).

[markb]

Posted on June 11, 2015 at 11:41 Hi, Yes, I am generating code with the cube thing and then fixing up the stuff it gets wrong. That's where having everything under source code control is vital because you can easily spot the mistakes! I haven't used the SPL because I have only recently moved to using ST devices but from what I read on this forum, it sounds like it is mature and, maybe, not so buggy. Others can surely comment on this. Because the STM32 is completely new to me, using the cube to generate all the setup stuff (clocks, peripherals, etc.) made life a bit easier and now I am fairly committed to keeping on that path which I don't mind as long as I end up with something that works reliably. It is my optimistic hope that ST will wake up and fix at least the worst of the HAL bugs. Cheers, Mark

[Tesla DeLorean]

Posted on June 11, 2015 at 18:16

I haven't used the SPL because I have only recently moved to using ST devices but from what I read on this forum, it sounds like it is mature and, maybe, not so buggy. Others can surely comment on this.

The SPL has always had a VERY low bug density, it's a very thin abstraction layer. ST's silicon has also been very solid, and not constantly stepped to the point you have to be acutely aware of if. There are some silicon bugs, and there's an errata sheet.I've made some long standing observations about HAL/Cube, I don't plan to revisit them here. I would recommend that anyone using any manufacture library do a code walk on it and apply the same rigour their company would expect of them.

[Andrei Chichak]

Posted on June 11, 2015 at 20:21

1) Buggy code libraries - I haven't had much problem with it. I suspect that ST borrowed heavily from their previous library code. There's going to be teething pains, but they seem to be fixing issues quickly. (Another 12-bit processor company could learn from ST)

2) Messy generated code - If the generated code is treated as gospel code that never gets touched, there are more than enough affordances for you to call ST's code without putting your code within the user code sections.3) Code into header files - ??? code doesn't go into header files? I'm not sure what you're saying here.A

[sasha]

Posted on June 12, 2015 at 01:06

Andrei - 3) code in header files, I meant function prototypes, defines etc. If you add your own functions to the generated .c files (e.g. additional ADC routines to adc.c) then there is no way of including a function prototype in the .h file that I can see.  I guess the work around here is to not put any user code in the generated files at all, if you want it accessible to other files.

Thanks for all your responses.