CubeMX or not?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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?

Re: CubeMX or not?
On 02/12/2019 09:39, pozz wrote:
Quoted text here. Click to load it

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



Re: CubeMX or not?
On 02/12/2019 10:57, Michael Kellett wrote:
Quoted text here. Click to load it

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.


Re: CubeMX or not?
luni, 2 decembrie 2019, 11:39:42 UTC+2, pozz a scris:
Quoted text here. Click to load it

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.

Re: CubeMX or not?
On 12/2/2019 1:39 AM, pozz wrote:
Quoted text here. Click to load it

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

Re: CubeMX or not?
On 2.12.19 11:39, pozz wrote:
Quoted text here. Click to load it


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


Re: CubeMX or not?
On Monday, December 2, 2019 at 4:39:42 AM UTC-5, pozz wrote:
Quoted text here. Click to load it

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

Re: CubeMX or not?
Il 02/12/2019 20:13, Dave Nadler ha scritto:
Quoted text here. Click to load it

Ouch, LL too?


Quoted text here. Click to load it

Luckily I won't use USB.


Quoted text here. Click to load it

Ouch, I need FreeRTOS. Thanks for the link.


Quoted text here. Click to load it

Seriously? Do you have fixed Ethernet driver?


Quoted text here. Click to load it

Another question that is different than the original.

Re: CubeMX or not?
On Monday, December 2, 2019 at 5:17:57 PM UTC-5, pozz wrote:
Quoted text here. Click to load it

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

Re: CubeMX or not?
wrote:

Quoted text here. Click to load it


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.




Re: CubeMX or not?
Il 12/12/2019 07:50, boB ha scritto:
Quoted text here. Click to load it

Why? Was it buggy?

Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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


Quoted text here. Click to load it

DMA for timers? What do you mean?


Quoted text here. Click to load it

Please, explain.



USB, how bad!! :-(

Re: CubeMX or not?

Quoted text here. Click to load it


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.

Quoted text here. Click to load it


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 << 8);

Gets right to the point without hiding the operation by calling an
inline HAL batch or even worse, a HAL function.  LL doesn't help me in
this manner.  Nobody else probably cares.  I come from time when
everything was done in assembler (but not ARM programming)
I still need to now assembly language for ARM to be able to debug
completely and understand the generated code.  HAL and LL makes it
extremely difficult for me to follow the code through debugging.


Quoted text here. Click to load it


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.

Quoted text here. Click to load it


Loading Capture/Compare registers for making PWM waveforms.

Quoted text here. Click to load it


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.


Quoted text here. Click to load it


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.



Quoted text here. Click to load it


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




Re: CubeMX or not?
On 2/12/19 8:39 pm, pozz wrote:
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Re: CubeMX or not?
Il 11/12/2019 23:41, Clifford Heath ha scritto:
Quoted text here. Click to load it

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


Quoted text here. Click to load it


Site Timeline