CubeMX or not?

On Mon, 2 Dec 2019 11:13:57 -0800 (PST), Dave Nadler <drn@nadler.com>
wrote:

>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


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:
> On Mon, 2 Dec 2019 11:13:57 -0800 (PST), Dave Nadler <drn@nadler.com>
> wrote:
> 
>> 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
> 
> 
> 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, 

Why? Was it buggy?

> I never go back to HAL (LL to me is
> kinda like HAL, awful to work with).  

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.


> But for initialization, Cube was
> OK.  At least it's just for init.

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


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

DMA for timers? What do you mean?


> Will find out about the SPI issues soon.

Please, explain.


> Not Ethernet or USB on this particular project.

USB, how bad!! :-(

On Thu, 12 Dec 2019 09:04:08 +0100, pozz <pozzugno@gmail.com> wrote:

>Il 12/12/2019 07:50, boB ha scritto:
>> On Mon, 2 Dec 2019 11:13:57 -0800 (PST), Dave Nadler <drn@nadler.com>
>> wrote:
>> 
>>> 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
>> 
>> 
>> 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, 
>
>Why? Was it buggy?


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 never go back to HAL (LL to me is
>> kinda like HAL, awful to work with).  
>
>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.


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.


>
>
>> But for initialization, Cube was
>> OK.  At least it's just for init.
>
>Indeed it is what I use ASF (Atmel Software Framework) for.


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.

>
>
>> I definitely like the DMA for timers and A/D but haven't used it for
>> anything else yet.
>
>DMA for timers? What do you mean?


Loading Capture/Compare registers for making PWM waveforms.

>
>
>> Will find out about the SPI issues soon.
>
>Please, explain.


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.

>> On Mon, 2 Dec 2019 11:13:57 -0800 (PST), Dave Nadler <drn@nadler.com>  >> 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.


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.



>
>
>> Not Ethernet or USB on this particular project.
>
>USB, how bad!! :-(


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

Il 11/12/2019 23:41, Clifford Heath ha scritto:
> 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.

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


>> 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.