CubeMX or not?

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.