Write my own library

[SGian.1]

Hi there !

I want start to write my own library, and step by step stop to use HAL library. Please some one know where i can find information, tutorial , or know some good book and whenre i can buy ? or webbinar ?

Thank you

Sergio

[KnarfB]

We already have CMSIS register-level programming, LL (low level), HAL and some other libs like libopencm3, mbed, .... So the first and foremost task should be to formulate clear design goals for a new library and state how it will differentiate from the existing ones. IMHO there is not much room for yet another library, but you mileage may vary.

hth

KnarfB

[waclawek.jan]

> where i can find information

Information on what exactly?

> formulate clear design goals for a new library

First, answer the question, "why". Not "why another library", but "why any library at all".

Writing a "library" is an incredibly expensive endeavour and is highly unlikely to pay off at all.

Chip manufacturers do it, as it is a marketing vehicle for them. They tell customers (which are typically managers, not engineers), that with a "library" programs can be written faster. There is absolutely no evidence for this, but it's a widely accepted "truth". Also, young developers demand "libraries" as they are told by the similarly misinformed academia that they need them.

What you really need is a library of use cases. You build that naturally as you write your applications (of course "libraries" will get into way here). Just remember to maintain some structure and style and documentation (still a costly operation), so that given piece of code then can be easily "copypasted" and reused again and again. Don't be worried to make it perfect at once: it gets perfected by repeated use, not by polishing.

JW

[Pavel A.]

If you use FreeRTOS, look at FreeRTOS+ collection of components. Do not reinvent the wheel.

[SGian.1]

First thank you.

I know very well write a library is a very hard job, but sometime i think HAL library don't work very well...

[S.Ma]

Then write your library incrementally so it can coexist and progressively replace part of the HAL. Starr where you think the most significant difference would be noticeable. Linker will keep in memory what is used.

[Danish1]

The Reference Manual for your stm32 is a good place to start. That says what needs to be done in order to achieve different aspects fo a peripheral's functionality.

The Reference Manual has much better documentation than you get for HAL etc. (Except in the recent cases where ST say to use/follow the HAL - this a gross dereliction of duty and short-sighted in that ST will end up with a reputation for poor peripherals since we won't be able to use them to their full capability).

But, even after years of reading them, I still struggle sometimes and study the ST examples to aid my understanding of the Reference Manual and maybe a protocol that a particular peripheral supports.

A major problem with having your own peripheral library is that you will find it much harder to port your code from one stm32 family to another. Peripherals do change. Although I have successfully ported my peripheral-support code originally written for stm32f1 onto stm32f4, stm32f7, stm32l0 and stm32l4, I have so far failed to get some aspects working on stm32h7. And that's just on the peripherals I use.

But as "." said, write your library incrementally so it can coexist and progressively replace part of the HAL. Starr where you think the most significant difference would be noticeable

I do not think you will ever get significant acceptance by other people of *your* library over a freely-available one promoted by the component vendor (in this case ST) and toolchain supplier(s). But if it makes you more productive, or if you enjoy doing it and are willing to do it on your own time, why not?

Hope this helps,

Danish

[SGian.1]

Thank for your wonderful message

Sergio

[Tesla DeLorean]

>>..that with a "library" programs can be written faster.

NOT learning the bit level register minutia of a specific device is demonstrably a lot quicker than spending time learning it, or reading manuals / watching videos.

Not knowing what you're doing, or how anything works at a low level, will likely extend the development and debug process significantly.