Is ST Cube IDE a piece of buggy crap?

[AVI-crak]

Ram.
(translation errors)

[westfw]

Ram.  (translation errors)   

But STM32F030 has at least 4k of RAM, and HK32F030 seems to have 10k.  Where did 2k come in?
(I know that the RPi RP2040 does some weird stuff with "banks" of RAM, though they end up looking like one chunk.)

[ataradov]

HK32F030M has 16 K of flash and 2K of SRAM. Example device https://www.lcsc.com/product-detail/Microcontroller-Units-MCUs-MPUs-SOCs_HK-HK32F030MJ4M6_C907709.html

I don't get their naming convention. Normally this "M" place would men package type. But "M" part is available in multiple packages and other letters in the name define the package.

Non-M devices have 16K-256K of flash and 10K of RAM.

[DavidAlfa]

It actually has 4KB!
Could be something like ST's untested extra 64KB flash, but it's there.
Been developing in it yesterday's entire afternoon, else than the usual "Why is this not working!" and the intensive RTFM, I am impressed for what it packs in $0.25.
So superior to equivalent pic/avr!
Jlink programs and starts the debugging session in 5 seconds, rarely hangs, ask that to the pickit and MplabX!
Another thing is ST IDE performance has greatly increased in the last versions, I remember somewhere in 2021, it was freezing all the time and using massive amounts of RAM, which no longer happens.

[peter-h]

I tend to agree; fewer problems with Cube v10.

Still suffers from the "can't insert breakpoints" even though you have not reached the max 5. Exit Cube and restart... Fortunately I manage most debugging with 1 or 2.

[westfw]

(I'll say one thing for ST.  They seem to be continually working on their development environment.  That's probably a good thing, despite the pain caused by the "churn."  If their original attempts (STLIB?) looked like they might have been written by a summer intern, at least it looks like they have permanent people working on it now (and continuously.))

[tellurium]

If their original attempts (STLIB?) looked like they might have been written by a summer intern

Cause software is not important. It'll be developed... somehow! BOM rules.

[paulca]

I tend to agree; fewer problems with Cube v10.

Still suffers from the "can't insert breakpoints" even though you have not reached the max 5. Exit Cube and restart... Fortunately I manage most debugging with 1 or 2.

I find deleting the breakpoints is good practice.  I don't mean deactivate either.  Double clicking the breakpoint icon on the line just deactivates that breakpoint, the breakpoint itself is remembered.  In JavaEE there are few practical limits on break points and I see people with dozens of them, stepping or "Continue"ing past them one after the other.  I'm like, "Go to your break points, click Delete All, now make the one or two you need and stop wasting time!"

So when I get that warning about hardware breakpoints, I just go and delete all the breakpoints in the breakpoint viewer except the one or two I'm actually using and relaunch the debug context. 

I have only once or twice had to restart because the debug launch context got a few stuck breakpoints which persisted even after the code was moved around them.  They were not registered with eclipse suggesting they are stuck in the GDB context.

[peter-h]

I think most larger volume chip users don't use free tools. They want tools which are supported, and there is zero support for Cube IDE/MX. And ST will be aware of this. They own a big chunk of the "industrial" business, with little threat from say Espressif due to the political risk and most of those applications being in short market life retail products.

Just looking at the project I am working on, no way this could have been done in a big company. You just could not waste coders' time fixing all that stuff. It happened in my company because of an initial lack of direction and a general a lack of time and money. But having spent much of 2 years on it myself, it is nearly done now; I hope to finish it in January. Would I do anything like this again? NO. But this platform will do anything I want to develop in the rest of my actuarial life expectancy

I still find it rather depressing how much half working sh*t there is out there, how little support there is, how so much stuff on say github doesn't work, how the main ST forum is near-useless with near-zero ST participation, not to mention a lot of nastiness coupled with posts containing no useful information, how forums and lists are full of posts by desperate people who are getting no replies (but the issues must have been solved; it's just that those who solved them don't tell anybody how they did it, partly because they are more leechers than contributors and partly because of commercial confidentiality). Never again...

I find deleting the breakpoints is good practice.  I don't mean deactivate either.  Double clicking the breakpoint icon on the line just deactivates that breakpoint, the breakpoint itself is remembered

Yes; I do that now, but that is just crap software though

Along with the ability to set a breakpoint where there is no actual binary code (due to optimisation driven removal, etc). Already discussed.

I remember tools like that from 1980, Z80 days.

[DavidAlfa]

They seem to be continually working on their development environment

Because they had to! In the last decade they had a tour through all the available IDEs: EWARM, Keil, IAR, TrueStudio, SW4STM32...
Each having their their own specific things, making porting hard and painful, sometimes requiring lengthy steps to enable advanced functionalities.
Also they replaced their libraries, so all the old code was no longer supported.
Now we have a stable platform getting better everyday.
After 2 years of DIY learning all ARM from 0, all the register bits (Not easy at first!), the HK32 is a breeze to develop for.

Also, I remember some terrible ST code when I got my F429-DISCO circa 2013,  tried the most simple thing, toggling a LED, opened some sample code and the GPIO init alone was using 2 screens!
Used to "TRISB=0xA1", felt like I was developing some stage-4 cancer and ran away .

Same as when I "really" tried to use Arduino in the ESP32-S3!
It's easy to run do.begin(), but if you want to go deeper, now you must have a PhD in C++!
Who thought it was a good idea? That's why I I hate Arduino so much!!

Things can be really tidy even at low level, for example, this is current GPIO init running on the HK32.
The "for" loops are a bit convoluted, but provides really compact initialization

Code: [Select]

typedef struct {
    GPIO_TypeDef          *port;
    GPIO_InitTypeDef      init;
} GPIO_Init_t;

typedef struct {
    GPIO_TypeDef          *port;
    uint8_t               pin;
    uint8_t               af;
} GPIO_AFInit_t;



Code: [Select]

const GPIO_AFInit_t GPIOAF_cfg[] = {
    { GPIOC, GPIO_PinSource5, GPIO_AF_2 },                                     // SPI SCK
    { GPIOC, GPIO_PinSource6, GPIO_AF_2 },                                     // SPI MOSI
    { GPIOD, GPIO_PinSource7, GPIO_AF_4 },                                     // TIM2 CH1 CCP INPUT
};

const GPIO_Init_t GPIO_cfg[] = {
    { GPIOA, { GPIO_Pin_3, GPIO_Mode_OUT, GPIO_Speed_10MHz, GPIO_OType_PP }},  // LED
    { GPIOB, { GPIO_Pin_4, GPIO_Mode_OUT, GPIO_Speed_10MHz, GPIO_OType_PP }},  // OLED CS
    { GPIOC, { GPIO_Pin_5, GPIO_Mode_AF,  GPIO_Speed_10MHz, GPIO_OType_PP }},  // OLED SCK
    { GPIOC, { GPIO_Pin_6, GPIO_Mode_AF,  GPIO_Speed_10MHz, GPIO_OType_PP }},  // OLED MOSI
    { GPIOC, { GPIO_Pin_3, GPIO_Mode_OUT, GPIO_Speed_10MHz, GPIO_OType_PP }},  // OLED DC
    { GPIOC, { GPIO_Pin_4, GPIO_Mode_OUT, GPIO_Speed_10MHz, GPIO_OType_PP }},  // OLED RST
    { GPIOD, { GPIO_Pin_4, GPIO_Mode_OUT, GPIO_Speed_10MHz, GPIO_OType_PP }},  // DEBUG SIGNAL
    { GPIOD, { GPIO_Pin_7, GPIO_Mode_AF,  GPIO_Speed_10MHz, GPIO_OType_PP, GPIO_PuPd_UP, GPIO_Schmit_Enable }},  // TIM2 CH1 CCP INPUT

};


Code: [Select]

    for(uint8_t i=0; i < sizeof(GPIO_cfg) / sizeof(GPIO_Init_t); i++)                          // GPIO init
        GPIO_Init(GPIO_cfg[i].port,  (GPIO_InitTypeDef*) &GPIO_cfg[i].init);

    for(uint8_t i=0; i < sizeof(GPIOAF_cfg) / sizeof(GPIO_AFInit_t); i++)                      // GPIO AF init
        GPIO_PinAFConfig(GPIOAF_cfg[i].port, GPIOAF_cfg[i].pin, GPIOAF_cfg[i].af);



[peter-h]

I think you are doing what I always did: table-driven initialisation of everything.

I don't think many people do it these days, and the ST devt environment discourages it, with an individual "HAL" function for initialising every device, and a corresponding "HAL" function for de-initialising every device (which almost nobody uses, but you have to watch it because some of these e.g. USB use the heap).

[DavidAlfa]

Yeah, tables are great for organization, but will often waste space...
Most of the existing struct can be reused for the next initialization by changing only few elements.
But that "waste" might not be so important when you need instructions to fetch the values.
Anyways it's constant data, won't hurt too much...
I'd chose it everytime, instead of moving through 500 lines searching the one that loads the parameter into the struct.

[peter-h]

The other thing about a table is that the device gets initialised as per that order. Whereas if one is calling a load of init functions all over the place, it is easy to get the order mixed up. Usually it doesn't matter but sometimes it definitely does e.g. (IIRC) you cannot initialise some peripherals if their clock is not enabled. This stuff is mostly poorly documented.

[DavidAlfa]

Yeah, I make several tables for different peripherals, but first of all it goes the RCC, so no issues..

[peter-h]

Why not do a single table?

One could have "delay" codes in the table, to wait x us etc. In some cases this is needed e.g. waiting for the PLL to stabilise (there is IIRC a polling method to detect stability there, but you get the idea). Perhaps a little tricky since the CPU starts at say 16MHz so your delay code needs to know that

[Kjelt]

“Memory frames”??  What’s that? 

https://en.wikipedia.org/wiki/Magnetic-core_memory#/media/File:KL_CoreMemory.jpg

[AVI-crak]

Perhaps someone will come in handy. https://github.com/AVI-crak/gpio_one
I have my bike "gpio_one_pin(zap_gpio. )" for stm32f4xxx series (for all cases in this series). Done once, so you don't have to look at the documentation again. The macro first translates the structure path into text, then processes the text to a compact unique number of 32 bits, and finally runs a function - which uses this number to fill the peripheral registers.
When optimization is enabled, the parsing of the structure path is fully optimized before the ready value is called from memory. With optimization disabled, path parsing will be in a separate function (take up space).
When you type the name of the structure in the macro gpio_one_pin(zap_gpio. ) - ide starts suggesting options for filling the path. And everything is set up so that false paths do not exist. Well, the most important thing is that all alternative states (AF0-15) are already in the macro.
One line for one leg, one time.

Code: [Select]

    /// SPI4
    gpio_one_pin(zap_gpio.E.pin02.v_af05_spi4_sck.speed4.pull_up.lock_on);             /// spi4_sck
    gpio_one_pin(zap_gpio.E.pin04.out.speed4.lock_on);                                 /// spi4_nss
    gpio_one_pin(zap_gpio.E.pin05.v_af05_spi4_miso.speed4.pull_up.lock_on);            /// spi4-mo
    gpio_one_pin(zap_gpio.E.pin06.v_af05_spi4_mosi.speed4.pull_up.lock_on);            /// spi4_mi
The macro is very difficult to adopt for the stm32f1 series, even more difficult for the stm32H. But for large stm32f4 cases - it fits perfectly. Setting up 160 pins in the STM32Cube way is literally a thousand lines. In my case it is 160 lines.
In order to reduce the error rate, I use a text report from STM32Cube. I just replace the copied text with my code. It is impossible to completely abandon the STM32Cube - this is the only quick search for an alternative connection of legs to the MK.

[peter-h]

The ST Cube IDE "HAL" code includes exactly such functions - for setting up a single pin.

They are quite handy but I would not have done it that way if I was starting bare-metal. I would work through every page of the RM and use a table. But that's ~2000 pages and you can see why this is impractical.

[paulca]

They are quite handy but I would not have done it that way if I was starting bare-metal. I would work through every page of the RM and use a table. But that's ~2000 pages and you can see why this is impractical.

Then do it for every model of mcu.

This is why we need a small number of monoglots, those people who specialise into the n-th degree on a platform.

However, I prefer to be a polyglot and learn a small amount about a large array of platforms.  Learn enough to be of practical use at least.

The HAL libraries still fall short on easy of use, rapidity of development.  In my experience, nothing actually works first try out of the box, there is always some little niggling little bit of config you forgot.  Forgetting to tick and interrupt, setting the DMA item size wrong whatever.  It's always a struggle, always a fight, you always end up learning far more than you felt you needed to do get the job done... if and only if... their HAL libraries did it's job properly and made these things easy.

To that end, I believe they need to apply a good solid dose of "convention over configuration".  They need to facade a lot of the overly complicated BS which is so complicated because it's trying to handle everything from the "high school hello world" right up to their latest, greatest most complicated variant of it that nobody is going to use.  It's just too much, too different goals which are not compatible.  In my opinion the HAL library needs split up into "common" and "advanced" where the common handle the 90% of the simple things easily, even with canned or default config for the most common use case and then a HAL_ADV library for handling the bizarre and massively complicated scenarios like 3 chained timers using PWM capture, output capture and tiggers with DMA.

That way when you have a simple prototype to knock up with a bread and butter UART it's just a half dozen clicks and it's ready.

HAL Libraries are 100% useless if you have to spent as long working out how to use it as it would have taken to read the datasheet and set the resisters yourself.

Oh... and I know it's an MCU library set, but for the love of god can we have some f...ing logging in it?  Even compile out macros or something.  Having no logging mechanism in your HAL library... in my opinion would be 25 lashes in front of the whole software department.

[AVI-crak]

HAL libraries are written with very little attempt at separating hardware/user code levels. Because it is allowed to access the hardware from the user code. In fact, these are several wrappers over the standard cmsis - many layers of abstractions with a variable meaning and description of states. It's like piling up fixes for an initially stupid decision.
I use my own cmsis-level functions for each chip series, my own unique functions for each unique chip on a unique PCB, and many user-level functions for all chips without limitation. It turned out to be quite convenient.
For example, for a timer, one of the many options for a given MK series, and the legs are adjusted for a specific project (this is below the level of the series). From the iron code, only the timer function is visible, which in itself is standard for the user level, and at the same time the user does not see and does not work with peripheral registers. Differentiation of visibility levels according to all rules.
As a result, my IDE shows a small number of functions and variables in the right quick use column - which are directly connected to the user's file. In the HAL version, there will be an endless list of everything that is in the project, literally millions of lines. Do you need it?

It seems to me that the main problem with HAL is that it was written by arduino programmers, and for arduino users. This type of user always writes all the code to one file. This is an unspoken rule for them.

[peter-h]

That part of ST code works fine. Example:

Code: [Select]

void Configure_GPIO(GPIO_TypeDef *port, uint32_t pin, GPIO_PinState pin_state, uint32_t mode, uint32_t pull, uint32_t slew)
{
GPIO_InitTypeDef  GPIO_InitStruct;

GPIO_InitStruct.Pin  = pin;
GPIO_InitStruct.Mode = mode;
GPIO_InitStruct.Pull = pull;
GPIO_InitStruct.Speed = slew;
HAL_GPIO_Init(port, &GPIO_InitStruct);
HAL_GPIO_WritePin(port, pin, pin_state);
}

and the two functions called above are ST-provided. The 1st one is really horrible though:

Code: [Select]


/**
  * @brief  Initializes the GPIOx peripheral according to the specified parameters in the GPIO_Init.
  * @param  GPIOx where x can be (A..K) to select the GPIO peripheral for STM32F429X device or
  *                      x can be (A..I) to select the GPIO peripheral for STM32F40XX and STM32F427X devices.
  * @param  GPIO_Init pointer to a GPIO_InitTypeDef structure that contains
  *         the configuration information for the specified GPIO peripheral.
  * @retval None
  */
void HAL_GPIO_Init(GPIO_TypeDef  *GPIOx, GPIO_InitTypeDef *GPIO_Init)
{
  uint32_t position;
  uint32_t ioposition = 0x00U;
  uint32_t iocurrent = 0x00U;
  uint32_t temp = 0x00U;

  /* Configure the port pins */
  for(position = 0U; position < GPIO_NUMBER; position++)
  {
    /* Get the IO position */
    ioposition = 0x01U << position;
    /* Get the current IO position */
    iocurrent = (uint32_t)(GPIO_Init->Pin) & ioposition;

    if(iocurrent == ioposition)
    {
      /*--------------------- GPIO Mode Configuration ------------------------*/
      /* In case of Alternate function mode selection */
      if((GPIO_Init->Mode == GPIO_MODE_AF_PP) || (GPIO_Init->Mode == GPIO_MODE_AF_OD))
      {
        /* Check the Alternate function parameter */
        assert_param(IS_GPIO_AF(GPIO_Init->Alternate));
        /* Configure Alternate function mapped with the current IO */
        temp = GPIOx->AFR[position >> 3U];
        temp &= ~(0xFU << ((uint32_t)(position & 0x07U) * 4U)) ;
        temp |= ((uint32_t)(GPIO_Init->Alternate) << (((uint32_t)position & 0x07U) * 4U));
        GPIOx->AFR[position >> 3U] = temp;
      }

      /* Configure IO Direction mode (Input, Output, Alternate or Analog) */
      temp = GPIOx->MODER;
      temp &= ~(GPIO_MODER_MODER0 << (position * 2U));
      temp |= ((GPIO_Init->Mode & GPIO_MODE) << (position * 2U));
      GPIOx->MODER = temp;

      /* In case of Output or Alternate function mode selection */
      if((GPIO_Init->Mode == GPIO_MODE_OUTPUT_PP) || (GPIO_Init->Mode == GPIO_MODE_AF_PP) ||
         (GPIO_Init->Mode == GPIO_MODE_OUTPUT_OD) || (GPIO_Init->Mode == GPIO_MODE_AF_OD))
      {
        /* Configure the IO Speed */
        temp = GPIOx->OSPEEDR;
        temp &= ~(GPIO_OSPEEDER_OSPEEDR0 << (position * 2U));
        temp |= (GPIO_Init->Speed << (position * 2U));
        GPIOx->OSPEEDR = temp;

        /* Configure the IO Output Type */
        temp = GPIOx->OTYPER;
        temp &= ~(GPIO_OTYPER_OT_0 << position) ;
        temp |= (((GPIO_Init->Mode & GPIO_OUTPUT_TYPE) >> 4U) << position);
        GPIOx->OTYPER = temp;
      }

      /* Activate the Pull-up or Pull down resistor for the current IO */
      temp = GPIOx->PUPDR;
      temp &= ~(GPIO_PUPDR_PUPDR0 << (position * 2U));
      temp |= ((GPIO_Init->Pull) << (position * 2U));
      GPIOx->PUPDR = temp;

      /*--------------------- EXTI Mode Configuration ------------------------*/
      /* Configure the External Interrupt or event for the current IO */
      if((GPIO_Init->Mode & EXTI_MODE) == EXTI_MODE)
      {
        /* Enable SYSCFG Clock */
        __HAL_RCC_SYSCFG_CLK_ENABLE();

        temp = SYSCFG->EXTICR[position >> 2U];
        temp &= ~(0x0FU << (4U * (position & 0x03U)));
        temp |= ((uint32_t)(GPIO_GET_INDEX(GPIOx)) << (4U * (position & 0x03U)));
        SYSCFG->EXTICR[position >> 2U] = temp;

        /* Clear EXTI line configuration */
        temp = EXTI->IMR;
        temp &= ~((uint32_t)iocurrent);
        if((GPIO_Init->Mode & GPIO_MODE_IT) == GPIO_MODE_IT)
        {
          temp |= iocurrent;
        }
        EXTI->IMR = temp;

        temp = EXTI->EMR;
        temp &= ~((uint32_t)iocurrent);
        if((GPIO_Init->Mode & GPIO_MODE_EVT) == GPIO_MODE_EVT)
        {
          temp |= iocurrent;
        }
        EXTI->EMR = temp;

        /* Clear Rising Falling edge configuration */
        temp = EXTI->RTSR;
        temp &= ~((uint32_t)iocurrent);
        if((GPIO_Init->Mode & RISING_EDGE) == RISING_EDGE)
        {
          temp |= iocurrent;
        }
        EXTI->RTSR = temp;

        temp = EXTI->FTSR;
        temp &= ~((uint32_t)iocurrent);
        if((GPIO_Init->Mode & FALLING_EDGE) == FALLING_EDGE)
        {
          temp |= iocurrent;
        }
        EXTI->FTSR = temp;
      }
    }
  }
}


Code: [Select]


/**
  * @brief  Sets or clears the selected data port bit.
  *
  * @note   This function uses GPIOx_BSRR register to allow atomic read/modify
  *         accesses. In this way, there is no risk of an IRQ occurring between
  *         the read and the modify access.
  *
  * @param  GPIOx where x can be (A..K) to select the GPIO peripheral for STM32F429X device or
  *                      x can be (A..I) to select the GPIO peripheral for STM32F40XX and STM32F427X devices.
  * @param  GPIO_Pin specifies the port bit to be written.
  *          This parameter can be one of GPIO_PIN_x where x can be (0..15).
  * @param  PinState specifies the value to be written to the selected bit.
  *          This parameter can be one of the GPIO_PinState enum values:
  *            @arg GPIO_PIN_RESET: to clear the port pin
  *            @arg GPIO_PIN_SET: to set the port pin
  * @retval None
  */
void HAL_GPIO_WritePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin, GPIO_PinState PinState)
{
  if(PinState != GPIO_PIN_RESET)
  {
    GPIOx->BSRR = GPIO_Pin;
  }
  else
  {
    GPIOx->BSRR = (uint32_t)GPIO_Pin << 16U;
  }
}


The above shows the classic HAL issue: code bloat. There is a lot of code to deal with EXTI but if you aren't using EXTI then this is just wasted code.

[dietert1]

As you have the source, you can insert an #ifdef #endif switch in order to make it a compile time option, thus saving on code size. This isn't code bloat, as EXTI support by hardware is a reality and required in the HAL.

Regards, Dieter

[DavidAlfa]

Still much easier/faster to tweak HAL code for your needs than making everything from scratch.

[peter-h]

Yes indeed; I tend to do exactly that.

[westfw]

Quote from: paulca on Yesterday at 05:46:02 am

HAL Libraries are 100% useless if you have to spent as long working out how to use it as it would have taken to read the datasheet and set the resisters yourself.

Yes, exactly.  The entire post reflects my opinions!

A really useful HAL library would have the same APIs across multiple vendors.
The individual vendors have very little motivation for making this be so - locking you in to their own products is much preferable!
Also, vendors like to add special feature that a fully generalized HAL would have difficulty supporting.