Forums

CubeMX or not?

Started by pozz December 2, 2019
I worked with NXP Cortex-M3 LPC1768 and similar and Microchip/Atmel SAM 
D20/C21.

I didn't like Atmel Software Framework so I extracted a buch of 
low-level files from ASF (mainly headers to manipulate registers) and 
rewrite the high-level drivers for peripherals I used (UART, ADC, 
Timers, ...)
It wasn't a simple task, I spent many days to understand what ASF really 
do, decide what to import in my project, what to exclude and what to 
refactor.
Anyway I now have a simpler and more understandable sources for my 
projects with SAM MCUs.

A similar thing happens with NXP LPCOpen, even if they are *only* 
low-level libraries. The driver of LPCOpen is very simple and not 
directly usable by at application point-of-view.

Now I need to start a project with STM32 and I noticed the usual thing: 
the silicon vendor releaes two ready-to-use libraries: low-level (for 
manipulating registers) and high-level drivers generated automatically 
from CubeMX tool.
I'm wondering if it's worth to give a possibility to CubeMX code or to 
stay with low-level files and make personal high-level drivers.

What is your experience with CubeMX high-level generated code?
On 02/12/2019 09:39, pozz wrote:
> I worked with NXP Cortex-M3 LPC1768 and similar and Microchip/Atmel SAM > D20/C21. > > I didn't like Atmel Software Framework so I extracted a buch of > low-level files from ASF (mainly headers to manipulate registers) and > rewrite the high-level drivers for peripherals I used (UART, ADC, > Timers, ...) > It wasn't a simple task, I spent many days to understand what ASF really > do, decide what to import in my project, what to exclude and what to > refactor. > Anyway I now have a simpler and more understandable sources for my > projects with SAM MCUs. > > A similar thing happens with NXP LPCOpen, even if they are *only* > low-level libraries. The driver of LPCOpen is very simple and not > directly usable by at application point-of-view. > > Now I need to start a project with STM32 and I noticed the usual thing: > the silicon vendor releaes two ready-to-use libraries: low-level (for > manipulating registers) and high-level drivers generated automatically > from CubeMX tool. > I'm wondering if it's worth to give a possibility to CubeMX code or to > stay with low-level files and make personal high-level drivers. > > What is your experience with CubeMX high-level generated code?
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 worked with NXP Cortex-M3 LPC1768 and similar and Microchip/Atmel SAM > D20/C21. > > I didn't like Atmel Software Framework so I extracted a buch of > low-level files from ASF (mainly headers to manipulate registers) and > rewrite the high-level drivers for peripherals I used (UART, ADC, > Timers, ...) > It wasn't a simple task, I spent many days to understand what ASF really > do, decide what to import in my project, what to exclude and what to > refactor. > Anyway I now have a simpler and more understandable sources for my > projects with SAM MCUs. > > A similar thing happens with NXP LPCOpen, even if they are *only* > low-level libraries. The driver of LPCOpen is very simple and not > directly usable by at application point-of-view. > > Now I need to start a project with STM32 and I noticed the usual thing: > the silicon vendor releaes two ready-to-use libraries: low-level (for > manipulating registers) and high-level drivers generated automatically > from CubeMX tool. > I'm wondering if it's worth to give a possibility to CubeMX code or to > stay with low-level files and make personal high-level drivers. > > What is your experience with CubeMX high-level generated code?
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.
On 02/12/2019 10:57, Michael Kellett wrote:
> On 02/12/2019 09:39, pozz wrote: >> I worked with NXP Cortex-M3 LPC1768 and similar and Microchip/Atmel >> SAM D20/C21. >> >> I didn't like Atmel Software Framework so I extracted a buch of >> low-level files from ASF (mainly headers to manipulate registers) and >> rewrite the high-level drivers for peripherals I used (UART, ADC, >> Timers, ...) >> It wasn't a simple task, I spent many days to understand what ASF >> really do, decide what to import in my project, what to exclude and >> what to refactor. >> Anyway I now have a simpler and more understandable sources for my >> projects with SAM MCUs. >> >> A similar thing happens with NXP LPCOpen, even if they are *only* >> low-level libraries. The driver of LPCOpen is very simple and not >> directly usable by at application point-of-view. >> >> Now I need to start a project with STM32 and I noticed the usual >> thing: the silicon vendor releaes two ready-to-use libraries: >> low-level (for manipulating registers) and high-level drivers >> generated automatically from CubeMX tool. >> I'm wondering if it's worth to give a possibility to CubeMX code or to >> stay with low-level files and make personal high-level drivers. >> >> What is your experience with CubeMX high-level generated code? > > 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. >
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.
On 12/2/2019 1:39 AM, pozz wrote:
> I worked with NXP Cortex-M3 LPC1768 and similar and Microchip/Atmel SAM > D20/C21. > > I didn't like Atmel Software Framework so I extracted a buch of > low-level files from ASF (mainly headers to manipulate registers) and > rewrite the high-level drivers for peripherals I used (UART, ADC, > Timers, ...) > It wasn't a simple task, I spent many days to understand what ASF really > do, decide what to import in my project, what to exclude and what to > refactor. > Anyway I now have a simpler and more understandable sources for my > projects with SAM MCUs. > > A similar thing happens with NXP LPCOpen, even if they are *only* > low-level libraries. The driver of LPCOpen is very simple and not > directly usable by at application point-of-view. > > Now I need to start a project with STM32 and I noticed the usual thing: > the silicon vendor releaes two ready-to-use libraries: low-level (for > manipulating registers) and high-level drivers generated automatically > from CubeMX tool. > I'm wondering if it's worth to give a possibility to CubeMX code or to > stay with low-level files and make personal high-level drivers. > > What is your experience with CubeMX high-level generated code?
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
On 2.12.19 11:39, pozz wrote:
> I worked with NXP Cortex-M3 LPC1768 and similar and Microchip/Atmel SAM > D20/C21. > > I didn't like Atmel Software Framework so I extracted a buch of > low-level files from ASF (mainly headers to manipulate registers) and > rewrite the high-level drivers for peripherals I used (UART, ADC, > Timers, ...) > It wasn't a simple task, I spent many days to understand what ASF really > do, decide what to import in my project, what to exclude and what to > refactor. > Anyway I now have a simpler and more understandable sources for my > projects with SAM MCUs. > > A similar thing happens with NXP LPCOpen, even if they are *only* > low-level libraries. The driver of LPCOpen is very simple and not > directly usable by at application point-of-view. > > Now I need to start a project with STM32 and I noticed the usual thing: > the silicon vendor releaes two ready-to-use libraries: low-level (for > manipulating registers) and high-level drivers generated automatically > from CubeMX tool. > I'm wondering if it's worth to give a possibility to CubeMX code or to > stay with low-level files and make personal high-level drivers. > > What is your experience with CubeMX high-level generated code?
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
On Monday, December 2, 2019 at 4:39:42 AM UTC-5, pozz wrote:
> What is your experience with CubeMX high-level generated code?
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 http://www.nadler.com/embedded/newlibAndFreeRTOS.html) 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
Il 02/12/2019 20:13, Dave Nadler ha scritto:
> On Monday, December 2, 2019 at 4:39:42 AM UTC-5, pozz wrote: >> What is your experience with CubeMX high-level generated code? > > 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.
Ouch, LL too?
> USB stack has bad bugs and no RTOS integration.
Luckily I won't use USB.
> FreeRTOS integration is broken (see http://www.nadler.com/embedded/newlibAndFreeRTOS.html)
Ouch, I need FreeRTOS. Thanks for the link.
> LwIP integration is broken and out-of-date; Ethernet drivers buggy.
Seriously? Do you have fixed Ethernet driver?
> 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.
Another question that is different than the original.
On Monday, December 2, 2019 at 5:17:57 PM UTC-5, pozz wrote:
> Il 02/12/2019 20:13, Dave Nadler ha scritto: > > On Monday, December 2, 2019 at 4:39:42 AM UTC-5, pozz wrote: > > ... > > 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. > > Another question that is different than the original.
This is relevant to your question, as RubeMX and STM drivers do not address these issues...
On 2/12/19 8:39 pm, pozz wrote:
> I worked with NXP Cortex-M3 LPC1768 and similar and Microchip/Atmel SAM > D20/C21. > > I didn't like Atmel Software Framework so I extracted a buch of > low-level files from ASF (mainly headers to manipulate registers) and > rewrite the high-level drivers for peripherals I used (UART, ADC, > Timers, ...) > It wasn't a simple task, I spent many days to understand what ASF really > do, decide what to import in my project, what to exclude and what to > refactor. > Anyway I now have a simpler and more understandable sources for my > projects with SAM MCUs.
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.
> Now I need to start a project with STM32 and I noticed the usual thing: > the silicon vendor releaes two ready-to-use libraries: low-level (for > manipulating registers) and high-level drivers generated automatically > from CubeMX tool. > I'm wondering if it's worth to give a possibility to CubeMX code or to > stay with low-level files and make personal high-level drivers. > > What is your experience with CubeMX high-level generated code?
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.