Low Layer Library, first impressions

[waclawek.jan]

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

[Raouf Hosni]

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!

[Tesla DeLorean]

Posted on October 14, 2015 at 02:42

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

. My English teachers concluded I was retarded. But I'm a pretty high functioning retard, as I make significantly more than most English teachers.

[waclawek.jan]

Posted on October 14, 2015 at 09:15

Jasmin,

> the SPLs were incompatible with the new “Code and Play�? approach of the Cube > environment. OK, so on behalf on ST you now publicly admitted that Cube is aimed at the amateurs. Don't get me wrong - I don't underestimate amateurs and I don't confuse the word ''amateur'' for ''dilettante'', and see it more as a synonym to ''hobbyist''

(i.e. somebody who is not paid regularly for his work).

Professionals don't ''Code and Play'', they do ''Program and Work''. Thus, they strive for substantial information and simple and concise examples, rather than fancy and fluff. This is why > 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. And this is why LL completely fails to: > provide an easier migration path from the SPL environment to the STM32Cube environment. Let this discussion be the proof. The sooner you understand this and stop wasting time, energy and money on LL, and concentrate on real work, the better for all. Jan Waclawek PS. Sorry for misspelling your name.

[matic]

Posted on October 14, 2015 at 18:23

I never used SPLs, because I started programming when Cube already exist. But I soon realized that, if I want to have a fast code, I have to write directly to registers and avoid HAL functions. But I found those functions useful for a starting point, just to see how to use registers of some peripheral. 

[jpeacock]

Posted on October 14, 2015 at 19:58

I understand the need for the Cube in competing against Microchip for the novice engineer market.  There is a niche there, since all other things being equal (in terms of easy to use software) a Cortex part will outperform a PIC in just about any way imaginable, not least ease of writing and debugging code. 

The PIC's advantage is a freebie library of adequate software, including TCP/IP and device drivers.  If you don't know better it looks like a great deal.  Use it and you soon hit a wall as you work up the learning curve.  The Cube idea follows much the same logic, easy to start but like the PIC supplied software a major pain once you're past the novice stage. So there is a place for the Cube idea, but ST should not count on anyone now using the SPL to migrate.  More likely it goes the other way, once the Cube limitations are recognized migrate to the SPL and custom, high performance drivers. [off topic] The RCA 1802 wasn't based on the PDP-8, that was the Intersil IM6100.  The PDP-8 was a 12-bit machine (anyone remember the DEC VT78 and OS/8?) and far more, uhh, interesting to program compared to an 1802.  The problem with the 1802 was an outdated process, crude instruction set and was quickly left behind by the 8080 and 6502 variants.  It did make for a great machine language trainer though.   Jack Peacock

[waclawek.jan]

Posted on October 14, 2015 at 21:14

To avoid any further confusion:

> I never used SPLs, I never advocated SPL; IMO it is as superfluous as Cube is. OTOH, historically, it's here and there's a substantial common knowledge and code base bound to it, and from ST's standpoint it makes much more sense to invest into SPL than into LL. I understand that it is hard to admit one's mistake, but all of us make errors. > I found those functions useful for a starting point, just to see how to use registers of some peripheral. This is why I call for quality documentation and concise examples. Snippets (I'd like to see them evolve), and examples in the Appendix of the 'F0/'L0 RMs, are the way to go. JW PS. Jack, the MIPS-cored PIC32 are even competitors to the ARMs, although I don't know how much all the libraries you mentioned apply to them.

[waclawek.jan]

Posted on October 14, 2015 at 22:14

> I recall for example that code examples page 935 F052 didnt work because ST had decided to rename register definitions in a similar

> fashion as the did with F1xx series so code from these had to be rewritten if run on anything else or something .

I dont' use the 'F0/'L0 other than I played with them briefly, so can't comment on the details; but the basic idea of provided snippets is IMO solid. This highlights another large problem, namely user feedback and its acceptance. I went

http://www.efton.sk/STM32/STM32F4xx_doc_errors.txt

, and quite some of it has been accepted; but this is not a proper systemic method. I don't claim I know what is the solution. > The notion that ST still have not fixed this forum engine is very good evidence ST in reality dont give a crap. Now I (and others) do rant on the forum software regularly (see ''worst forum software ever'' tag, waitaminute, tags don't work either :) ), but it is not true that they don't give a crap, they do work on it. Let's admit honestly, it's not a trivial task. > because the top managers would look bad in front of ST board and etc internal ST problems It is a huge company. It is not easy to fix internal problems in *any* larger group of people. The best we can do is IMO to suggest ways to improve the outputs; it's up to the people in the company to find out how to respond/implement these suggestions. There's no other way. > Just do a search on that [eevblog] forum. ''STM32 Cube'' returns interesting results indeed. http://www.eevblog.com/forum/microcontrollers/st-official-anouncment-of-new-low-level-api/msg757106/#msg757106 is pertinent to this thread. JW

[waclawek.jan]

Posted on October 15, 2015 at 09:11

> Now your just beeing silly, 3 post ago you wrote one heck of complaint post now try to lick their butt! ;)

Choose your words, please! If your neighbours are having aloud row, and do that regularly - you can tell them to keep the noise low, you can even call the police; but you shouldn't give them marital advice nor preach them about anger management. Or you can move out. It makes sense to rant about the quality of products, documentation, code examples, web; it is counter-productive to discuss the internals of the company. JW

[mikael239955_stm1_st]

Posted on October 25, 2015 at 00:55

>If your neighbours are having aloud row, and do that regularly - you can tell them to keep the noise low,

>you can even call the police; but you shouldn't give them marital advice nor preach them about anger >management. Or you can move out. >JW Hmm, actually the only ones who are giving marital advices and preaching about anger management on the public square (this very forum) exposing your dysfunctional marriage disturbing the entire neighbourhood and the police at night time while having tantrums over it is you and Jasmine,etc. >Choose your words, please! >JW Chose your manners and live as you preach, please! Because ST said years ago they only wanted to DISCO and would set the rules for it, if you tango there is lot of others around, NXP, Freescale , ATMEL etc, so you can move your self out as you suggest. >It makes sense to rant about the quality of products, documentation, code examples, web; >it is counter-productive to discuss the internals of the company. >..http://www.efton.sk/STM32/STM32F4xx_doc_errors.txt... >JW Dear Don QueShotte, to where have your onemanband windmill battle taken you so far? Page 1 of 1123 in your F429 novel? There is at least 50 to 60 more refmanuals to read, good luck! >Now I (and others) do rant on the forum software regularly (see ''worst forum software ever'' tag >waitaminute tags don't work either but it is not true that they don't give a crap, they do work on it. Well , if so why are you complaining in the same sentence , 7 years later about the same thing? Dont answer, we all do know, ST don't give a crap! ST cant take constructive criticism for their work and outside suggestion for improvement nor even through assigned FAE's come on, deleting my original post but keeping  yours with my original attached how stupid is that! and you my dear Jan with aid from Jasmine proved the rest of the situation with your own comments... Thank you so much , that was way easier then planned... Strangely enough Jan i do concur to the broader picture you paint up, unfortunately 7-8 years has passed and things is not getting better and ST is in denial so all we can do is wait until someone higher up in management have epiphany or similar event.

[Nickname12657_O]

Posted on October 27, 2015 at 12:04

Dear Gentleman,

We are fully open to receive any criticism from our STM32 community, and are listening to all of you carefully but we can NOT tolerate users who are not accepting our “Code of Conduct�?. Therefore we will continue deleting inappropriate words and keeping trace of original post of the authors who are the responsible of the used words.

https://my.st.com/public/STe2ecommunities/mcu/_layouts/ST/MYSTForum/CodeOfConduct.aspx

Thank you.

Regards,

STMicroelectronics.