Cube vs standard peripheral driver

[mark2399]

Posted on December 18, 2014 at 17:21

Hi,

Does anyone know if STM are going to continue developing the standard peripheral drivers for the foreseeable future? Or are they being superseded by by the Cube drivers?If if both will be running in parallel does anyone have any comments on the strengths/weaknesses of either?We are most of the way through a year long development using the standard perhiperal drivers for an F4, but are about to start a new project on a different stm32 processor. On the whole we've found them fairly ok, if a little clunky.On the face of it the Cube system looks more rapid to develop, but are the HAL drivers etc more elegantly written? Are they suitable as a professional tool?Any answers welcome.thanks,Mark #cube #stm32

[Tesla DeLorean]

Posted on December 18, 2014 at 17:31

Does anyone know if STM are going to continue developing the standard peripheral drivers for the foreseeable future?

They are mature and stable, what additional development do you expect to occur? I think I've got a commitment they won't be abandoned, but don't expect to see them in this form on new chips. If you have a large base of working code, it's not going to rot on the vine. There have been other threads on this topic, I have no plans on rehashing it again.

[mark2399]

Posted on December 18, 2014 at 18:26

Thanks for the reply Clive. Apologies for asking a common question. I did have a quick search but will search a little harder...

Sounds like Cube might be the way forward if they won't be making standard peripheral drivers for the future processors. 

[waclawek.jan]

Posted on December 18, 2014 at 18:30

IMHO, there's little reason to resort to any ''library'' for peripherals access. All you really need is a set of symbols for symbolic access (provided in the ARM/CMSIS-required stm32XXXxx.h headers, and we can then discuss their shortcomings), and the datasheet/manual.

I can think of only one - although valid and very strong, I admit - argument in favour of using ''libraries'', namely that the examples use them. There is one more argument which could be brought up, namely portability, but I see that as a dubious one - either the peripherals are fully compatible in hardware, and then you need no wrapper, or they are not, and then usually the wrappers won't help much, as you need to study and understand the differences anyway (e.g. handling the GPIO/interconnect matrix in 'F1/'L1 vs. rest of STM32). So, at the end of the day, you might be better off with the old fashioned, ''direct register access'', especially in light of the short life of the first ''library'' (I don't subscribe to the ''oh, it's moving, 5-6 years is ages in this industry'' sentiment) and the mere fact that ST deliberately chose to be incompatible with the new one... Whether sticking to a conservative and old fashioned approach is elegant and professional enough, I leave to your discretion... JW