And, you can use HAL without ever using Cube MX.
or you can use cube once to generate a project makefile and initial setup of all the common peripherals and then never again
many ways to skin a cat
Porting a HAL based ILI9341 library to non-HAL, for someone already able to write low level code, should not be a major undertaking. All SPI writes should be abstracted out and can be replaced with your own functions.
Of course if its high performance DMA based, well, you'll have to learn about implementing that, which will take some time and effort. But if you don't have this time, why are you reinventing the wheel and writing all your own peripheral libraries.
I'm not reinventing the wheel.I was looking for a library that doesn't use HAL.Is this not a legitimate request?
You are writing something which already exists, that is reinventing the wheel. Of course its 100% fine to do this, many justifications for it.
But you already wrote peripheral drivers, so you have SPI driver thats working right? Can you replace the HAL calls with your own?
Checking github I see lots, but I didn't look closely:
https://github.com/Isyaam/ES-STM32-ILI9341/blob/master/Src/ILI9341.cpphttps://github.com/i998/ILI9341_spi_STM32https://github.com/MakMe1/ili9341_stm32f4https://github.com/zoosmand/STM32F429I-disk1__std_periph__template/blob/main/Core/Src/ili9341.c
I know where this discussion is heading!! If you're happy with HAL that's fine, and I respect that, but I'm sorry HAL it's not my cup of tea, that's all.
Porting a HAL based ILI9341 library to non-HAL, for someone already able to write low level code, should not be a major undertaking. All SPI writes should be abstracted out and can be replaced with your own functions.
Of course if its high performance DMA based, well, you'll have to learn about implementing that, which will take some time and effort. But if you don't have this time, why are you reinventing the wheel and writing all your own peripheral libraries.
I'm not reinventing the wheel.I was looking for a library that doesn't use HAL.Is this not a legitimate request?
You are writing something which already exists, that is reinventing the wheel. Of course its 100% fine to do this, many justifications for it.
But you already wrote peripheral drivers, so you have SPI driver thats working right? Can you replace the HAL calls with your own?
Checking github I see lots, but I didn't look closely:
https://github.com/Isyaam/ES-STM32-ILI9341/blob/master/Src/ILI9341.cpp
https://github.com/i998/ILI9341_spi_STM32
https://github.com/MakMe1/ili9341_stm32f4
https://github.com/zoosmand/STM32F429I-disk1__std_periph__template/blob/main/Core/Src/ili9341.c
Honestly, I didn't think about replacing the HAL function with my own! I try to do that!
Thanks for the heads-up man
So you're going to re-invent a better wheel
Maybe do something in between?
Just create a separate "test" project with the HAL and all that shit and then only copy some small parts out of it into your own project. Maybe also clean it up a bit? Starting with "working" code is often easier then starting from scratch.
The HAL code is useful to get started. It is what is produced by the code generator (Cube MX). Then you can read it to see what it does and learn from it.
This is easier said then done. To get to the bottom of what the generated code does you have to search through multiple files and filter the actual code from the many not helpful lines of comment
It is rarely actually wrong but is usually bloated because of insufficient granularity;
I have not tried that many, but all the attempts I made did not work. These were all target to USB, but never the less.
I would not want to start from scratch by reading the 2000 page RM. I did read every word of the 300 page data sheet when doing the PCB.
No need to read the whole manual if you are only using a couple of the peripherals.
I always found that wrapping my head around the HAL intricacies is more complex than writing my own "driver" functions.
The only exceptions are probably related to more complex functions (USB stack, etc.).
My thoughts exactly, but see above, the code generated for USB did not work for me so I dug through the crap and learned about USB and wrote my own bare metal code. Probably lacks some protection but it works.
Well, you might run into problems when you want to switch to a different line of STM32 controllers; the peripherals are allover the place so you likely end up needing to port a whole bunch of drivers if you have to use a different microcontroller from ST.
This is not a very big problem, since most of the peripherals are similar. One difference I know of is the GPIO. The F1 series needs a different setup then the F3 series. Not a big deal. Read the manual and adapt your code.
From what I have seen the HAL for the STM32 parts isn't bad perse (it is also MISRA compliant) but I'd research how effective ST's HAL routines are for a certain problem and whether there are known issues. IMHO it is a good idea to start with using the HAL and go from there; avoid trying to write your own HAL if it doesn't work and there are no known issues in the particular feature you are trying to use. You are likely doing something wrong. RTFM.
The problem I see with this if that when you go this road you are either stuck with it or have to rewrite the code to get rid of it when you are finalizing your work. So for me it is better to just start without it. You only have to do it once for every unique device you use.
And where is the difference in reading the HAL documentation or just the low level user documentation, you have to read and learn anyway. I prefer the latter, but that is me.
One thing I would like to state is that some of the posters approach a lot of the questions from a professional standpoint, meaning a business eye on things, like "we have to use HAL because of our customers and compliance rules", instead of reading that the original poster is a hobbyist. There is a big difference between the two worlds. Time and money
Also that it often evolves into a pissing contest about what is the best solution. (See the thread about debugging) A very human trade to which I'm no stranger, but when getting older you learn to see things clearer. There is no best solution, just a solution that fits you best.
I only saw one post that gave the original poster an answer to his real question and that is this one:
https://www.eevblog.com/forum/microcontrollers/(stm32)-am-i-the-only-one-not-using-hal/msg4260583/#msg4260583thm_w came up with a bunch of github links to repositories for the display driver and an option on how to get rid of the possible HAL in them. Kudos to him
No, is not uncommon, usually is a method used by "consultant types" or developers that want job security. It make sure that nobody could get support for your own version of spaghetti and wheel reinvention from anywhere and also on-boarding another developer is not cost effective, so they will turn back to you. Usually coupled with useless documentation and architecture. Because the companies that developed this chips surely have no idea how theri stuff works and need some rando to do it from scratch in an "optimized" mode.
At lest in my current workplace, whoever comes with this crap gets a swift kick in the behind.
Yeah, have seen this a few times, and when "your company" is unable to finish the product and your customers start to ask difficult questions, somehow I get involved* to fix it. Then your incompetent developers have to come to the Internet to spew some bullshit like this to get their frustration off their chests. But don't worry, we both got paid, and the customer finally got something delivered.
*) through some very weird routes I can't disclose because the end customers are usually very large and have weird non-disclosure requirements.
See? People like this still exist! Imagine comments like above by DC1MC were the default commonplace reply just a few years ago. What a blast from the past.
Ummm hmmm, when the "incompetent developers" have reached the end of their rope and the customers are starting to ask really hard questions, who you gonna call call, call Siwastaja, he will solve all with all the pending issues with one hand tied behind using his proprietary "pfuscherei.lib" optimized uncommented assembly, what CMSIS, what HAL, these are just bloat, raw metal baby, with my own register names, this how real consultants are doing it, it solves everything, just look at my freelancer.com (formerly known as rent-a-coder.com) reviews, are totally stellar .
Then all the "incompetent developers" are fired, the support contracts with the chip manufacturer are cancelled, the whole software development is kicked out and the company has but one super-star, or rock-star, consultant Siwastaja, that will solve anything with a bit of highly optimized code that no one was capable of thinking about. Of course, this code is unmaintainable, tied to a very specific chip type and even mask version, and of course the toolchain must not be updated ever, because the whole optimized mess will not compile anymore. But other large companies (undisclosed, under NDA, no details can be revealed) are using libpfuscherei, so is really a way better solution than what the manufacturer and standard bodies promotes, they have no clue, all incompetents .
Well, joking (and personal attacks) aside, I don't know why you feel so personally attacked Siwastaja, different companies have different development strategies, I'm pretty sure that your skills are appreciated in some circles, no need to resort to calling names and stuff if some other don't like the "extreme customization", to call it gently, promoted by some consultants.
Cheers,
DC1MC
All you can see is solving complexity by adding more complexity, so you project this mindset to others.
No, I solve problems by starting over from scratch. I totally loathe mysterious "libpfuscherei" solutions, and replacing ST's HAL with something even more complex and custom is not going to cut it. So I actually completely understand what you mean and totally agree with you, however surprising that might sound!
But there's more to it than that. You present a mistaken strawman, probably based on some actual negative experiences, but that does not match with my experience. Maybe I have been lucky never to see the crap you describe.
In the end, microcontrollers are fundamentally simple devices - even something like STM32H7 series - and the key to writing maintainable
and powerful code is to not think about one's job security, but instead focus on using the available resources and documentation to solve
the problem. The idea is not to choose between building a cathedral or renting an existing one, but to question if cathedral is needed at all, and maybe a simple shack with 2"x4" wooden framework and galvanized steel surface will do.
I find it funny however how emotional
you got about this, your first reaction to the topic being revealing your fantasies about getting people who don't agree with you fired, making yourself proactively agitated. I merely responded in the same tone, which is what I always do.
In the end though, what I said is exactly correct: if you routinely
fire people who prefer any other workflow than ST's HAL library, then it means you fire most of the competent programmers and are likely unable to finish any project that has requirements that can't be solved by ST's HAL - and that doesn't not require much. This will also lead to the pattern I have seen - anything non-trivial gets outsourced to some greybeard who is known to be able to do it, because everyone within the company is "too busy".
But of course I know you were just joking. You are not seriously firing people for something like that. Right? ... right?
.... 
...
No, I solve problems by starting over from scratch.
...
In the end, microcontrollers are fundamentally simple devices - even something like STM32H7 series
...
But of course I know you were just joking. You are not seriously firing people for something like that. Right? ... right?
No, of course not, firing someone over such an issue, THAT will be incompetence, the proper way is to not introduce this cancer in the organization and do a proper interview process, from:
a) "Show us your code" to
b) "Here is some existing source code, how do you think it can be improved ?"
if the answers are:
"a) Oh, my source code is totally secret and under NDA, I don't have anything that I can show and anyway, all my projects are different and problem specific, because all the problems are totally different, so is my code totally different because each time I start from scratch."
and
"b) Immediately throw this crap away, I will start and reimplement it from scratch to show the incompetents how is done..."
then you're not hired, period, whatever colour of beard you have, gray, pink or blue.
Is that simple.
There are three ways how to use the ILI9341 (more precisely, how to dump image data at it): one is RGB, where ILI9341 is more-less transparent through to the bare LCD and you have to shovel RGB at it continuously. This is how it's intended to be used on the Disco429 board, as that is aimed at showcasing the LTDC peripheral in the STM32F429, which was the first one incorporating that peripheral.
That means to get LTDC working which is not that complex and may be fun to get going, but also you need a framebuffer storage, which usually means also to get SDRAM going (again the 'F429 was the first to implement SDRAM controller within the FMC module), which is not that impossible again, but maybe less fun.
You still may need to send some initialization data to the ILI9341 through the side-channel (SPI), I'm not sure, I did not use this mode.
The second method is to use the internal framebuffer of ILI9341 and write to it through SPI. It's then ILI9341 which refreshes the LCD periodically, so you can write to it lazily only when you want and have time. On the Disco429 board this is viable, but maybe not that spectacular (i.e. don't expect play back video); however it frees up much of the mcu's pins for other useful purposes.
The third method is to use internal framebuffer of ILI9341 and write to it in parallel; this is extremely unwieldy on the Disco429 so no point to dwell on it further.
You may want to have a look at
Tilen Majerle's work (he started on those "libraries" before he became to be ST FAE). It does incorporate some sort of "librarysm", judge yourself.
JW
No, of course not, firing someone over such an issue, THAT will be incompetence, the proper way is to not introduce this cancer in the organization and do a proper interview process, from:
a) "Show us your code" to
b) "Here is some existing source code, how do you think it can be improved ?"
if the answers are:
"a) Oh, my source code is totally secret and under NDA, I don't have anything that I can show and anyway, all my projects are different and problem specific, because all the problems are totally different, so is my code totally different because each time I start from scratch."
and
"b) Immediately throw this crap away, I will start and reimplement it from scratch to show the incompetents how is done..."
then you're not hired, period, whatever colour of beard you have, gray, pink or blue.
The 'not invented here syndrom' is very strong in some people!
The problem with HAL is that, despite the name, it doesn't actually do any abstraction. Instead, it presents a way for the coder to specify exactly what values need to be written into what registers in the device, using macros and data structures which must be learned
in addition to fully understanding how the hardware works and how to configure it.
Given that there is
never an alternative to actually reading and understanding the reference manual, there is no benefit to be had by including an additional layer of obfuscation. Once you know that register X must be written with flags A | B | C in order to put the hardware into the mode you need, just write the register. Your code is simpler, clearer, smaller, faster, less ambiguous, easier to debug.
The analogy I've used before is that the HAL is like having a guide to "help" you navigate a foreign city. You might want to request, say, "buy a train ticket to <place>, returning tomorrow", or "order the chicken with noodles, but without the nuts", and hope that the guide understands your request and how to make it happen. Instead, though, the HAL replies "OK, sure, I can do that... you tell me exactly which words to say, and I'll say them for you".
For the same reason, it's not even portable between devices, so that argument goes out the window too.
The problem with HAL is that, despite the name, it doesn't actually do any abstraction. Instead, it presents a way for the coder to specify exactly what values need to be written into what registers in the device, using macros and data structures which must be learned in addition to fully understanding how the hardware works and how to configure it.
You are mixing up things. What is called "STM32 HAL" actually does a lot of abstraction, and is relatively simple to use, and indeed (often, sometimes) saves the developer from having to know all the internals. Coupled with some cubemx-like autogeneration it can actually save time. The problem is just that this isn't fully scalable and I have had people come to me when they can't continue on that path. So while I don't like that workflow and am just fine without it, and know many who totally agree and are totally able to work with my workflow no problems whatsoever, it's still a valid argument pro STM32 HAL.
What you seem to be describing is the earlier thing which name I already forgot, the one where you copy-paste 50 lines of code setting up almost-the-same-but-not-quite fields as in the peripheral registers in a struct, then call an init function with this. It always was a huge PITA. Yet just some 5 years ago you
had to use it or you were a NIHilist and not a cool kid. Later it was deprecated, good riddance, and everyone conveniently forgot their insistence of using that crap.
NIH is obviously crappy attitude but if you are able to write the necessary 30 lines of code to use DMA to communicate through SPI and sync this with ADC, this is not NIH. This is common sense and ability to use available resources to your advantage. And I definitely do notice my tendency to start from scratch even when it is not necessary. This is why I don't force this attitude unto others and don't force myself into projects. I get called only when my workflow is an advantage and not hindrance. But I can understand the need of different workflows and attitudes, and I can see the power in different types of people working together and combining their different skillsets. Unlike some who are so full of themselves they just call other workflows cancerous and want their users fired.
If someone is seeing challenges with STM32 peripherals and consultants are ruining their codebases by not using STM32HAL, they have very crappy consultants or something more serious going on. Real challenges are elsewhere.
But one thing is sure: user manuals, C language and base GNU tools never get old or irrelevant. Everything else seems to be a moving target. It's not far-fetched to say that insistence of some trend tool of year such as CubeMX combined with trend library of year, say STM32 HAL, is
exactly NIH, too, because the alternative is NOT building a massive cathedral from scratch, but instead use simple, ages old, well tested patterns.
But, STM32 HAL seems to now be stable enough and simple enough it's not too cancerous. Just be aware of people who strongly insist on any certain piece of technology and name-calls others NIHilists. Irrational fear of NIH, leading to forced reuse of unsuitable or overcomplicated code, is an equally big problem than actual NIH itself. Be careful.
The argument that I have to write everything from the scratch (which I've heard more than once in this thread) is totally not true,because for a given series of Stm32, you have to write let's say a Gpio_int function only once and then it can be used in all the projects (copy/paste).The same holds true for every single peripheral for that particular MCU.
I think programming in bare metal( no HAL) is more suited to people who have more solid background in electrical engineering, with some exceptions of course!
The argument that I have to write everything from the scratch (which I've heard more than once in this thread) is totally not true,because for a given series of Stm32, you have to write let's say a Gpio_int function only once and then it can be used in all the projects (copy/paste).The same holds true for every single peripheral for that particular MCU.
I think programming in bare metal( no HAL) is more suited to people who have more solid background in electrical engineering, with some exceptions of course!
Usually, for sane developers at least, these "own" solutions are so obvious and simple that no one complains.
In a recent co-operation project, everybody accepted my
IO_TO_GPO(GPIOA, 5);
HI(GPIOA, 5);
LO(GPIOA, 5);
macros without any issue at all. I think you need quite mental gymnastics if you think
MX_GPIO_Init(); // Regenerate with pointy-clicky whenever you need changes.
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET);
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_RESET);
is any more readable, writable, or modifiable. But it sure might be
acceptable. Is whichever NIH? I don't think so. People use NIH as a random personal insult like "you are gay", without knowing what it actually means.
It is also part of life to admit different coding styles, frameworks etc. exist and be able to dive into existing project. It's like tab vs. spaces; I have a definite opinion on that, but if someone writes spaces in the files, I try to adjust and also use spaces within that file.
Key to co-operation is not to make everyone to think in exact same way, but instead make everyone contribute the part they are best at. Some are great at putting together a fairly complex MCU project with filesystems, SD cards, ethernet, USB and whatever by pointy-clicking in CubeMX, utilizing autogeneration and libraries to the fullest, and do that in matter of weeks. And then, I like to build timing critical motor control, switch mode converters, data acquisition and processing, and so on. Both are skills that are needed in real life. Co-operation can bring it all together.
HALs (and automatic peripheral code generation) can definitely be a major time saver in my experience, especially if you're frequently flipping between different MCU families. I found myself to have become rather spoiled by the STM32 code configurator - the other day I had to initialise a timer in an Arduino, and I found myself mentally groaning having to open the datasheet and start figuring out which configuration bits to set to what value. There is definitely something to be said about "just give me a free-running timer with this limit and that prescaler, click [OK], click [Generate], done."
I've mostly worked with the STM32 HAL, and its automatic peripheral code generator. Most of my opinions about HALs and autogenerators stem from using CubeMX. It seems well-engineered and well-organised enough, atleast for my purposes, and the generated code is readable and makes sense. I've yet to hit a bug in the generated code, though admittedly I haven't written a huge amount of STM32 code.
What I think is most overlooked, is knowing exactly what code and files the autogenerator is responsible for, where it generates code, under what circumstances it generates code, and to give it "room to breathe" so to speak. It is also important to know how it integrates with your IDE. I am using Atollic with CubeMX, which used to be its own IDE before being bought out by ST and rebranded as the STM32CubeIDE. The most important workflow habit I've found, is that its best to let the autogenerator have free-realm in the files that it creates, and to physically isolate your own code from it - create a separate directory, say "App/", and place all your code in there. Don't fall for the "Put your code here" comments placed all over the autogenerated main.c file. I think this is very bad advice. The auto-generated main.c should have only TWO lines added: The first, declares your function "AppMain" as extern, and the second, which calls your AppMain() function. AppMain() is your "real" main function, and you keep its definition far, far away from the dirty hands of the code generator, under the "App/" directory. Doing this is where you need to know how the autogenerator integrated with your IDE. with Eclipse, you have to do a surprising amount of button-clicking just to have your code in your own directory.
The other thing I found important was to understand the structure of the autogenerated code. Again, this in my experience is completely implicit, but it will be there. One of those autogenerated files will be the "top level" header file, and the rest will be MCU/configuration-specific. I've seen projects include auto-generated include files, not realising that they are actually including files that are specific to the MCU or peripheral that was selected in the code configurator. Had the user changed the MCU in the code configurator, and re-generated the project, the user's application code would no longer compile. Its really important to avoid the impulse of "Hey, I can see X defined in file 'XYZ.h', I'll just include it and job done". Have a look first if it has a parent include file. I'm pretty sure in STM32-land, the only auto-generated include file that is "portable" is main.h. It will include all the other peripheral header files as it needs to, depending on what peripherals you've enabled in the code configurator.
Another sharp corner I've found in STM32, are the HAL peripheral handles. They will not be declared in the auto-generated top-level main.h file. Consequently I have to manually declare them as "extern" in my app code.
Another point of frustration, is figuring out what given configuration option in the code configurator is responsible for what autogenerated code/file in the project directory. One technique I use is to generate lots of STM32 "test" projects, where I select a particular configuration in the code configurator, generate the project, then slightly change the configuration, and generate another, separate project in a different directory. Then I run 'grep' against the two project directories in order to figure out exactly what kind of code that particular change introduces. I think this is really a major shortcoming from the vendors. They need to treat their auto-generator tools with no less importance than the compiler or IDE, and document the hell out of them.
Anyway, when you isolate code this way, I've found the claims of cross-family portability to become practical. You should be able to just copy your conveniently isolated "App/" folder from your STM32F1-based project directory to the STM32F4-based project directory, tell Eclipse to search your "App/" directory for source files, and you should be, at the very least, good to compile. Plus you don't get any confusion as to who owns what code. Re-running the code generator isn't gonna overwrite any of your application code. And providing you didn't accidently include any of the MCU-specific auto-generated headers (in STM32, you should only include the "main.h" autogenerated include file), combined with only using the peripheral handles as per the HAL, any potential differences in BSP code shouldn't have any impact in the application code.
Ofcourse, in practice it often isn't that simple. But (knock wood) so far I've "gotten away" with it.
HALs (and automatic peripheral code generation) can definitely be a major time saver in my experience, especially if you're frequently flipping between different MCU families.
Families, maybe - say between STM32F7 and STM32F4 - but between manufacturers, no way. This is because there is no standardized code interface - and it's no surprise, there practically cannot be without sacrificing a lot of what makes microcontrollers microcontrollers. All attempts to do so have failed. Thus, every hardware abstraction interface is totally NIH.
But, if your workflow is based on bare GNU tools and no manufacturer specific anything at all, then switching between different vendors is easy-peasy. Especially if everything's still ARM.
I had to port some code from STM32 to nRF52, two very different products with completely different approaches to manufacturer SDKs, and if I had been relying on those, it would have been a complete new learning experience from scratch. This was emphasized by the fact how weirdly different nRF52 is. With STM32, you have fairly complex peripherals with some quirks, eating up some time if you do everything yourself, and at least somewhat usable HAL library which can at least get trivial cases right quite easily. With nRF52, the peripheral designers should be awarded for unusually clean and simple-to-use design, documentation and register interface, but their SDK guys made it all so difficult to understand and use that it turns the ease-to-use argument completely around, in favor of not using any of their library code.
With the current chip shortage, being manufacturer agnostic has been immensely helpful. Sadly, manufacturer peripheral libraries, code generators and IDEs are manufacturer-specific. Even more sadly, they have tendency to have lifetime anywhere betweeen 2-5 years. So if you have to use 3 different manufacturers during 10 years, you likely learn and unlearn through 6 - 10 different "frameworks". And indeed, complaining about X has been a recurring theme on this forum. Next year, X is something else.
Now STM32HAL and even CubeMX have been surprisingly long-lived so far, so maybe there is some hope of things getting at least
stable. But I wouldn't hold my breath. Reading manuals, writing C and compiling with GCC never gets old, that's guaranteed.
HALs (and automatic peripheral code generation) can definitely be a major time saver in my experience, especially if you're frequently flipping between different MCU families. I found myself to have become rather spoiled by the STM32 code configurator - the other day I had to initialise a timer in an Arduino, and I found myself mentally groaning having to open the datasheet and start figuring out which configuration bits to set to what value. There is definitely something to be said about "just give me a free-running timer with this limit and that prescaler, click [OK], click [Generate], done."
Can the same thing be implemented by the API function or macro?
Like, the way it is done by e.g. libopencm3? See the API:
void rcc_set_pll_source(uint32_t pllsrc);
void rcc_set_ppre2(uint32_t ppre2);
void rcc_set_ppre1(uint32_t ppre1);
Simple and clear. No need for point and clicks mess. No frustrations with missing code blocks, files. Friendly for team development, where noone can suddenly regenerate and commit a bunch of surprising shit in the repository. The source code is self-descriptive: "ah, here we set the PLL source to external oscillator", rather than implicitly hidden in the auto-generated blocks.
I wish ST just hires libopencm3 guys and they do the right thing.
The current CubeMX style "assumes" only one developer working on a firmware, and there is no such thing as version control exists.
void rcc_set_pll_source(uint32_t pllsrc);
void rcc_set_ppre2(uint32_t ppre2);
void rcc_set_ppre1(uint32_t ppre1);
This is simple and clear because it doesn't abstract anything. It's kind of sweet spot; it satisfies the programmer's desire to do simple bare metal with no unnecessary abstraction, but it also satisfies the superficial company policy of needing some layer. Luckily, the higher-up does not understand it is not abstracting anything, so you get a pass
.
But, what the heck is pllsrc? It's still part specific. What are ppre2 and ppre1? They are just divisors. So you need to know what the input clock frequency is, and you also need to know where in the clock tree the signal divided by PPRE2 goes, to which peripherals.
Proper general abstraction of MCU peripherals is still a pipe dream. Real implementations that actually exist and are usable, are like what you describe. You can't avoid understanding the target chip and its peripherals.
This is simple and clear because it doesn't abstract anything. It's kind of sweet spot; it satisfies the programmer's desire to do simple bare metal with no unnecessary abstraction, but it also satisfies the superficial company policy of needing some layer. Luckily, the higher-up does not understand it is not abstracting anything, so you get a pass .
But, what the heck is pllsrc? It's still part specific. What are ppre2 and ppre1? They are just divisors. So you need to know what the input clock frequency is, and you also need to know where in the clock tree the signal divided by PPRE2 goes, to which peripherals.
Sure.
But I was not talking about the abstraction - I was talking about getting rid of code generation step.
The argument that I have to write everything from the scratch (which I've heard more than once in this thread) is totally not true,because for a given series of Stm32, you have to write let's say a Gpio_int function only once and then it can be used in all the projects (copy/paste).The same holds true for every single peripheral for that particular MCU.
When you use copy/paste you end up with multiple copies of the same code. That becomes a maintenance problem whenever a bug fix or modification has to be made. I prefer to maintain a single copy of the source and link the compiled code into all the projects that reference it at build time.
I think programming in bare metal( no HAL) is more suited to people who have more solid background in electrical engineering, with some exceptions of course!
I'm one of those exceptions
I think there is nothin wrong with your approach.
Not to dive into a religious discussion, but all I can say is what has worked for me.
Probably many here like me have been concerned about the ongoing chip shortage, and certainly abstractions like HAL and CubeMX can mitigate migration of code to newer available chips as intended. I think a lot of the reasoning that goes into HAL is that resource and execution efficiency is less important than development agility and hardware flexbility. This could well be the case if one has a low volume product or a limited lifespan product for which cost and/or long term availability of parts are not going to be an issue.
The problem I see with this approach is for large volume, cost-sensitive applications and where long-term availability is concerned, this is not necessarily an acceptable tradeoff. Having to use a more expensive microcontroller because HAL requires it for consumer electronics where profit margins may be relatively low. Furthermore, having to revise code on an existing microcontroller to modify or add features in the field also becomes harder if adding additional features using automatic code generation adds even more code bloat that might make the existing hardware inadequate for the upgrade. In these cases, rather than start out with an abstract library such as HAL or generated with CubeMX, one might start with bare hardware programming or a library with less overhead.
I kind of think that a manufacturer should be providing copious code examples rather than a one-size-fits-all monolithic library. The library is intended to hide details from the programmer which I think ultimately the programmer will need to know. Code examples tend to provide understanding of the resources being used rather than try to hide them. I usually end up looking for such code examples to get an idea of the parts of my problem that I need to understand so that I can write my own code.
certainly abstractions like HAL and CubeMX can mitigate migration of code to newer available chips as intended.
I sort-of see it as the reverse. Using a particular vendor's special tools, libraries, or OSes, makes it a lot harder to switch to a different vendor. They are motivated NOT to make their tools "abstract" enough that they'll work on some other chip, but "abstract enough" that you don't learn the "deep principles" that are portable. :-(
I guess it's nice that TI has a free TI-RTOS that you can use, but actually USING it sounds like a good way to get locked in to a vendor that doesn't have a great record WRT chip longevity (Luminary (cough)) USB stacks are probably another good example - has anyone seen a USB stack in a vendor library that it "about the same" as some other vendor's stack? (Hmm: maybe Atmel and NXP both have LUFA?) And then, how much have you really learned about USB?
certainly abstractions like HAL and CubeMX can mitigate migration of code to newer available chips as intended.
I sort-of see it as the reverse. Using a particular vendor's special tools, libraries, or OSes, makes it a lot harder to switch to a different vendor. They are motivated NOT to make their tools "abstract" enough that they'll work on some other chip, but "abstract enough" that you don't learn the "deep principles" that are portable. :-(
I guess it's nice that TI has a free TI-RTOS that you can use, but actually USING it sounds like a good way to get locked in to a vendor that doesn't have a great record WRT chip longevity (Luminary (cough)) USB stacks are probably another good example - has anyone seen a USB stack in a vendor library that it "about the same" as some other vendor's stack? (Hmm: maybe Atmel and NXP both have LUFA?) And then, how much have you really learned about USB?
But they didn't state "other vendors" they said "newer chips", which can be from the same vendor.
And in the case of ST,
some parts can be second sourced from Gigadevices/Mindmotion/HK/Megawin/CKS/Geehy
Using HAL or similar abstaction layers gives some vendor lock-in, but also a simpler path to other (especially newer) chips from the same vendor. Even if using direct hardware access it is usually much easier to port to a µC with the same pheriphery and thus the same vendor. Though using the same CPU the ARM based µCs can be quite different in the pheripery. How important the periphery deails are depends a lot on the applications: some only use the basics (and thus easy to port) and other care about the details or special features and are thus hard (possibly impossible) to port.