2018-07-11 01:15 AM
Dear Community,
I am new to the STM32, have used the Renesas platform in the past, it seems to me that the STM32 HAL is using precious (S)RAM memory for information that could be considered constant.
For each peripheral that you configure in Stm32cubemx there will be a handle in main.c like so:
/* Private variables ---------------------------------------------------------*/
UART_HandleTypeDef huart2;
UART_HandleTypeDef huart3;The size of UART_HandleTypeDef turns out to be 128 bytes, each one of them... And no, this memory is not used as a data buffer to read/write to the uart. B.T.W. DMA_HandleTypeDef is 120 bytes as such using a UART with RX and TX DMA will cost you....
Looking at the definition of UART_HandleTypeDef it turns out that some fields are indeed used to keep track of dynamic information (transfer state etc). However a lot of them could be considered constants, so why are they in RAM?
Would it not be more efficient/flexible to generate multiple struct variables of which some could be constant, allowing them to remain in flash, like so:
static const UART_InitTypeDef uart2initData =
{
.BaudRate = 9600,
.WordLength = 8,
// etc.
}
static UART_DynDataTypeDef uart2dynData;
const UART_HandleTypeDef huart2 =
{
.pInit = &uart2initData,
.pDynData = &uart2dynData,
}
This way a lot of (S)RAM usage could be prevented...
Looking forward to your opinions...
Regards,
Martin
#stm32cubemx-stm32-hal-sram-waste*2018-07-11 01:49 AM
The Cube implementation comes with a lot of debatable design desicions, you can either take it or leave it.
I decided for the latter.
2018-07-12 01:38 AM
Hi AvaTar,
Thanks for you opinion!
If you don't use the Cube implementation, I guess that you don't use the HAL peripheral library either?
To me it is HAL that wastes RAM because of the structure definitions and interfaces that were chosen.
For the ST32H7 HAL was the only peripheral library that I could find, is there an alternative that I missed?
Best regards,
Martin
2018-07-12 01:59 AM
... is there an alternative that I missed?
The LL (LowLevel) library, supposedly a HAL subset of Cube similar to the 'old' SPL.
You might need to check the stage of completion for individual MCUs, and the level of testing. Both seem to be lacking a bit for newer MCUs.
2018-07-12 02:36 AM
Thanks again Avatar,
Too bad that for the STM32H7 the LL libraries haven't been released yet... Read somewhere on this forum that it will be Q4 of this year. I am testing the peripherals that I need with the HAL, so far I haven't run into major functional issues yet, keeping my fingers crossed...
When the time comes that I run into RAM limits guess that I will have to put those HAL drivers on a diet my self.
2018-07-12 02:55 AM
Too bad that for the STM32H7 the LL libraries haven't been released yet...
In your position I would do a search for issues related to the H7 silicon and HAL here - I remember several threads.
The H7 is architectural quite different from the F7 and former STM32, but suffered some release delays recently.
Me following this just out of curiosity, I would choose a Cortex A + Linux for applications the H7 targets.