CubeMX or not?

In a nutshell,comprehensive, competent, bloaty and slow !

To be fair, they can't really win - if they cover everything you get bloaty and slow, if they don't then they haven't enabled you to use all the nice hardware on the chip. I think they make the right choice.

The Cube tools are great for getting something going quickly and finding out how to set stuff up. The framework and program model they use has a huge main file full of "put your code here" type comments - fine to get you going and for learning but not production quality.

I don't use any more of ST's code than the header files for important stuff.

I have used Keil's (relatively expensive) middle ware and I don't much like that either !

The advantage of the ST stuff is that you do have complete source code access and can work it any way you like. The documentation could be better.

MK

luni, 2 decembrie 2019, 11:39:42 UTC+2, pozz a scris:

I have used until now the following STM32 chips: F030, F091 and more recently G070. All with my own "drivers". Read the manuals. They are quite good. Things are simpler than you may think. UART, USART, SPI, I2C, ADC, GPIO, I2S. PLL, clocks. They are really simple. Timers of course, capture, compare etc. I had some problems understanding the SPI "software NSS" thing on the STM32 but I got used with that too. CubeMX is horror. It scared me.

I have no experience of ST's stuff. But I can certainly say that for most of the microcontroller manufacturers I have used, the libraries, SDK's, headers, configuration stuff, examples, etc., is truly terrible. Yes, there are tradeoffs and you can't please everyone - but they could do far better at trying to avoid /displeasing/ everyone. Most of the stuff looks like it was made by students in their summer holidays, with no oversight or coordination.

There are manufacturers who won't give you the headers for their chips, but insist on complicated on-line SDK generators producing hundreds of files.

There are manufactures where the headers are inconsistently named between different devices in the family (one will have "UART0", another will have "UARTS[0]", and other such pointless inconveniences).

Pretty much all of them suffer from rampant lasagne programming, where toggling a GPIO pin takes a dozen layers of calls through "middle ware", "hardware abstractions" and "drivers" - making an operation that should take two or three instructions run to 50-100 instruction cycles. The true "geniuses" add a crappy imitation of C++ virtual functions in C, for extra wasted time and space.

I've seen manufacturers drivers that fail when compiled in C99 mode rather than C90 mode. Pretty much all of them vomit up heaps of warnings when you enable even the most basic of checks. Lots of them fail with optimisations due to the programmers' misunderstandings of "volatile" and the C concept of "compatible types".

I've seen stuff written in assembly that is incredibly inefficient, because it was originally written for a totally different chip and then translated "word for word" to a different device. I've seen code that is incomprehensible because it is full of support for wildly different devices, including architectures that haven't been sold for decades.

The most impressive example I saw was from Freescale CodeWarrior for tiny 8-bit micrcontrollers. I used the wizard to make code for an analogue input, thinking it would save me reading the reference manual. The generated code, and the crap it pulled in from other SDK parts, took over 3K words - for a device with 2K words of flash. After reading the manual, getting the analogue input to work took /one/ line of C, resulting in /one/ assembly instruction.

My experience with CubeMX is small, LPCOpen is none, SAM is high, and STM32 high. I've learned by experience to stick to what the vendor SDKs provide at the start of the project. Then I evaluate the drivers that might not be performing at the high level that I need and customize those drivers to suit my needs. It usually ends up (1) greatly simplifying the driver after understanding the HW interface details and (2) meeting the performance requirement turns out to be not much additional programming work. You do end up putting in some time deconstructing the bloaty driver but you successfully get to "done".

In other words, only optimize the code that needs it. Doing so for all driver code is like swimming against the tide because SDK updates could negate your efforts.

JJS

I dropped it because of the bloat and poor code of the libraries. It is about as bad as the Atmel foundation code, and of the same reason: the code tries to fit all, and it makes it a bad fit to everyone.

If you feel that you can write the hardware handling code yourself, just drop CubeMX and do it yourself. However, CubeMX can be a help to solve the puzzle of I/O pin setup planning - it is a mess, as the pin multiplexing is far from regular.

--

-TV

Only a boob would use Cube? Only a blockhead? I can't remember which is more popular.

I've been using RubeMX for around 18 months. During that time I've reported dozens of bugs, a few of which have been fixed. The HAL and LL libraries (high and low level drivers) are bloated and buggy. USB stack has bad bugs and no RTOS integration. FreeRTOS integration is broken (see

LwIP integration is broken and out-of-date; Ethernet drivers buggy. Support for F7 series is especially buggy. My workflow is:

- create the initial project using CubeMX, under source control.

- patch all the errors in the generated project files

- patch bugs I know about in the generated code.

- commit to source control frequently

- if I need to regenerate the project from Cube (pin assignment changes etc), - always commit prior regenerating - review all changed files: replace from repository or merge fixes

The ST chips have some interesting hardware issues (F4 anyway):

- SPI is brain-dead; chip-selects must be done with SW or timers, no support for xfers other than 8-bit or 16-bit (and we use 20-bit ADC/DAC).

- DMA sometimes gives up under stress, very hard and non-performant to catch/resume.

So, better than Microchip and their absurd "Harmony", similar to Freescale parts (now NXP), similar to Gecko tools, not as good as current NXP part support (MCUxpresso).

Hope that helps! Best Regards, Dave

Ouch, LL too?

Luckily I won't use USB.

Ouch, I need FreeRTOS. Thanks for the link.

Seriously? Do you have fixed Ethernet driver?

Another question that is different than the original.

This is relevant to your question, as RubeMX and STM drivers do not address these issues...

Did you publish any of your ASF rewrite? Some of the Arduino libs are buggy (e.g. USB re-connect) and ASF works but has the problems you noted.

None, but I wouldn't trust this kind of code generator. Switch to an RTOS platform (ChiBios, Nuttx, etc) or use libopencm3 to write your own, would be my policy.

I uses CubeMX for STM32F4xx to help with the initialization and choosing pins and peripherals and alternate function I/O and generate code for IAR EWARM IDE.

After I fixed the HAL init code, I never go back to HAL (LL to me is kinda like HAL, awful to work with). But for initialization, Cube was OK. At least it's just for init.

I definitely like the DMA for timers and A/D but haven't used it for anything else yet.

Will find out about the SPI issues soon.

Not Ethernet or USB on this particular project.

Il 12/12/2019 07:50, boB ha scritto:

Why? Was it buggy?

I understood you can generate LL or HAL/LL drivers. If you don't use HAL drivers, I think it's better to select only LL drivers.

Indeed it is what I use ASF (Atmel Software Framework) for.

DMA for timers? What do you mean?

Please, explain.

USB, how bad!! :-(

It did not enable the IO pins for the timer PWM outputs. I think the newer CubeMX is better but the older version I used did not have all possible implementations of peripherals available.

For instance, you cant tell the DMA initialization several things about how its channels and streams are used in CubeMX. There is always code to add to get things to do what you want to do. This is expected and I don't have a problem with that I guess... Especially now that I have things working.

I did try in LL generation mode. Gave me the same feeling as HAL code did because of how they call the functions. How I like to set bits and fields is like this for example...

GPIOA->BSRR = (0x0001

Yes, a tool to help with the original pinout and initialization code.

I had a very bad experience with Atmel 13 years ago or so. (bad silicon and denial from Atmel) Hopefully Microchip makes them a better company to deal with now.

Loading Capture/Compare registers for making PWM waveforms.

Dave mentioned that the STM32F4 chips has some issues he didn't like. That is what I am using but haven't gotten to the SPI peripheral yet.

I did see something in some documentation somewhere about using the

1ms timer tick for SPI when I was looking at removing its interrupt so I left the tick timer interrupt enabled. I'm using almost every timer there is in this part.

No Ethernet in my part but there is USB. Not using either one here though.

Nope. Anyway I only extracted include files and clock configurations and initialization routines. No more. I rewrote every peripheral driver, starting from initialization.