Skip to main content
waclawek.jan
Super User
September 17, 2015
Question

Low Layer Library, first impressions

  • September 17, 2015
  • 21 replies
  • 4589 views
Posted on September 18, 2015 at 01:12

As announced by Jasmine in https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/DispForm.aspx?ID=57714&RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex%5fmx%5fstm32%2fHAL%20gpio%20libary%20code%20bug&Source=https%3A%2F%2Fmy%2Est%2Ecom%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex%5Fmx%5Fstm32%2FFlat%2Easpx%3FRootFolder%3D%252fpublic%252fSTe2ecommunities%252fmcu%252fLists%252fcortex%255fmx%255fstm32%252fHAL%2520gpio%2520libary%2520code%2520bug%26FolderCTID%3D0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B%26TopicsView%3Dhttps%253A%252F%252Fmy%252Est%252Ecom%252Fpublic%252FSTe2ecommunities%252Fmcu%252FLists%252Fcortex%255Fmx%255Fstm32%252FAllItems%252Easpx , the Low Layer ehm API is available in the current 'L4xx Cube

http://www.st.com/web/en/catalog/tools/PF261908 - and it's not even ''next week''! :) A whopping 200MB zip, for those who are curious; although the LL-related content is one order of magnitude less (and the vast majority of it are the examples). For real content, look into STM32Cube_FW_L4_V1.1.0\Drivers\STM32L4xx_HAL_Driver\Inc\, filenames of the stm32l4xx_ll_***.h style (i.e. containing ''ll''); there are two more files in ..\Src, too. Documentation - portions of both STM32Cube_FW_L4_V1.1.0\Documentation\STM32CubeL4GettingStarted.pdf and the doxygen-autovomited STM32Cube_FW_L4_V1.1.0\Drivers\STM32L4xx_HAL_Driver\STM32L486xx_User_Manual.chm - does not depart from the style and quality of the rest of Cube. Examples in STM32Cube_FW_L4_V1.1.0\Projects\STM32L476RG-Nucleo\Examples_LL\. . An excerpt from the ''blinkey'' example, to get the feeling of it (doxygen-style comment/headers omitted):

int
main(
void
)
{
/* Configure the system clock to 80 MHz */
SystemClock_Config();
/* -2- Configure IO in output push-pull mode to drive external LED */
Configure_GPIO();
/* Toggle IO in an infinite loop */
while
(1)
{
LL_GPIO_TogglePin(LED2_GPIO_PORT, LED2_PIN);
/* Insert delay 250 ms */
LL_mDelay(250);
}
}
__STATIC_INLINE 
void
Configure_GPIO(
void
)
{
/* Enable the LED2 Clock */
LED2_GPIO_CLK_ENABLE();
/* Configure IO in output push-pull mode to drive external LED2 */
LL_GPIO_SetPinMode(LED2_GPIO_PORT, LED2_PIN, LL_GPIO_MODE_OUTPUT);
LL_GPIO_SetPinOutputType(LED2_GPIO_PORT, LED2_PIN, LL_GPIO_OUTPUT_PUSHPULL);
LL_GPIO_SetPinSpeed(LED2_GPIO_PORT, LED2_PIN, LL_GPIO_SPEED_LOW);
LL_GPIO_SetPinPull(LED2_GPIO_PORT, LED2_PIN, LL_GPIO_PULL_NO);
}
__STATIC_INLINE 
void
SystemClock_Config(
void
)
{
/* MSI configuration and activation */
LL_FLASH_SetLatency(LL_FLASH_LATENCY_4);
LL_RCC_MSI_Enable();
while
(LL_RCC_MSI_IsReady() != 1) 
{
};
/* Main PLL configuration and activation */
LL_RCC_PLL_ConfigDomain_SYS(LL_RCC_PLLSOURCE_MSI, LL_RCC_PLLM_DIV_1, 40, LL_RCC_PLLR_DIV_2);
LL_RCC_PLL_Enable();
LL_RCC_PLL_EnableDomain_SYS();
while
(LL_RCC_PLL_IsReady() != 1) 
{
};
/* Sysclk activation on the main PLL */
LL_RCC_SetAHBPrescaler(LL_RCC_SYSCLK_DIV_1);
LL_RCC_SetSysClkSource(LL_RCC_SYS_CLKSOURCE_PLL);
while
(LL_RCC_GetSysClkSource() != LL_RCC_SYS_CLKSOURCE_STATUS_PLL) 
{
};
/* Set APB1 & APB2 prescaler*/
LL_RCC_SetAPB1Prescaler(LL_RCC_APB1_DIV_1);
LL_RCC_SetAPB2Prescaler(LL_RCC_APB2_DIV_1);
/* Set systick to 1ms in using frequency set to 80MHz */
/* This frequency can be calculated through LL RCC macro */
/* ex: __LL_RCC_CALC_PLLCLK_FREQ(__LL_RCC_CALC_MSI_FREQ(LL_RCC_MSIRANGESEL_RUN, LL_RCC_MSIRANGE_6), 
LL_RCC_PLLM_DIV_1, 40, LL_RCC_PLLR_DIV_2)*/
LL_Init1msTick(80000000);
/* Update CMSIS variable (which can be updated also through SystemCoreClockUpdate function) */
LL_SetSystemCoreClock(80000000);
}

Correct me if I am wrong, but it's essentially a bunch of macros/static inline functions, barely doing anything else than renaming simple register accesses. Now I completely fail to understand the reason to do that, so there must be something wrong with me. JW #grammer-nazis
    This topic has been closed for replies.

    21 replies

    mikael239955_stm1_st
    Associate III
    September 17, 2015
    Posted on September 18, 2015 at 01:46

    Nothing wrong with you, it's just one of ST's repeating disasters!

    I ask in vain to my self what kind of problem do ST have not able

    to understand what a clean, simple,consistent well documented set

    of, or one definition file stands for and is to a developer?.

    mikael239955_stm1_st
    Associate III
    September 17, 2015
    Posted on September 18, 2015 at 01:46

    if you by accident found one in that 200MB zip pile let me know!

    Tesla DeLorean
    Guru
    September 18, 2015
    Posted on September 18, 2015 at 02:10

    Honestly I did try to reason with them, but didn't seem to get a lot of traction, at this point it's all going to have to collapse under it's own weight. Someone there is going to have to have some sort of epiphany, as the way things are going it's just going to get more unmaintainable.

    I'm going to join the Jan on the Dark Side, and tinker at the register level.
    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    carl2399
    Associate III
    September 18, 2015
    Posted on September 18, 2015 at 05:37

    I'm a register level tinkerer - that way all I need is my code and the Programmers Reference Manual - there is no intermediate convenience / magic / interpretation.

    It's a bit slower to start with, but quickly gains traction as you build up your own PAL (Personal Abstraction Layer). 

    Five years later, I spend a minimum amount of time dealing with registers, the majority of the time being spent on developing the end user applications.

    Tesla DeLorean
    Guru
    September 18, 2015
    Posted on September 18, 2015 at 06:12

    I spent may of my formative years writing in assembler, building libraries of functions, the register stuff is not particularly alien to me, the SPL has just represented a clean abstraction that's served very well.

    The thing I do observe is some people claiming they are doing things more efficiently while using dozens of load-store, or RMW type operations, that the compiler can't fold.
    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    John F.
    Associate III
    September 18, 2015
    Posted on September 18, 2015 at 09:09

    OK. I started with the 1802 (a PDP 8 on a chip) in assembler and working out the offsets for jumps by hand. All the same, I don't want to go back there!

    Not having seen the ''Low Level'' stuff I thought it

    had

    to be an improvement on HAL. Now I think differently.

    I have a question about middleware (USB / SD card etc. ...).

    Can anyone explain exactly where the split is between third party (say Keil for example) middleware and the code ST produces. As far as I understand, Keil middleware now depends on ST drivers ... but if they all depend on HAL and I don't want anything to do with HAL where does that leave me?

    I've googled all over trying to understand this and guidance from Keil seems to be use HAL or write your own drivers. I really want to understand this. Please help!

    e1369008
    Associate
    September 18, 2015
    Posted on September 18, 2015 at 10:02

    I am very sorry for the off-topic post, but a certain person whom we all love really needs to read

    http://englishplus.com/grammar/00000227.htm

    .

    AvaTar
    Senior III
    September 18, 2015
    Posted on September 18, 2015 at 11:32

    > I am very sorry for the off-topic post, but a certain person whom we all love really needs to read

    http://englishplus.com/grammar/00000227.htm

    .

     

    As a saying in my native language goes : ''You have only one chance to make a first impression.''

    Going back to topic, I'm also in conflict of switching to register level hacking, or switching to a different vendor alltogether.

    I think/fear that not until big company with serious investments in Cortex M devices backing away from Cube and ST, that epiphany in ST's leadership will happen.

    carl2399
    Associate III
    September 18, 2015
    Posted on September 18, 2015 at 11:52

    Definitely agree with Clive on not underestimating the power of modern compilers. I regularly look at the extended assembly listing of my application (pretty easy using the GCC compiler), and just marvel at what gets produced!! More than 9 times out of 10 I would be hard pressed to better the result.

    What's nice about starting at the register level is that a c++ wrapper can make for neat code structure. With static allocation of classes (all classes defined at compile time), the output is practically indistinguishable from c, but at the source code level there's no comparison to the elegance that can be achieved.  I'm by no means a c++ wizard, using mainly a ''structure with functions'' approach, but have been gradually adding virtual functions as a way to make for nice Application Layer derived classes.

    Raouf Hosni
    ST Employee
    October 13, 2015
    Posted on October 14, 2015 at 01:57

    Hello,

    Please be assured that we are listening to our community and that we are taking the comments and demands into account. We are constantly striving to gradually improve our firmware offer to meet these expectations.

    While the existing Standard Peripheral Libraries (SPLs) are and will be maintained until EOL of the corresponding STM32 family, we chose to not develop SPLs for new products as it seemed a bit counter-productive to maintain two partially redundant libraries while the SPLs were incompatible with the new “Code and Play�? approach of the Cube environment. Later, we understood that a part of our community still perceived the legacy SPLs as a good compromise between performance, simplicity, portability, and that it should have been made available in one form or another for the newer families. We also think that we can still provide an easier migration path from the SPL environment to the STM32Cube environment.

    Concerning our next move, we are currently and actively working towards improving our STM32Cube firmware offer to address these concerns.

    Stay tuned!