I don't need, I'm talking about drivers for peripherals that support every single feature that peripheral has, including ones that I don't use. It's hard to exclude that code because a lot of the vendor libraries I've seen have large functions that handle every single option a peripheral device has, often in a huge switch statement.
So to put it sarcastically: actually you are complaining that a peripheral has too many functionality that you don't need/use but then blame the vendor for supporting all these functions?
Either you have less functionality (different uC, different peripherals) or you support what is available from a vendor POV.
Yes sure you can write your own peripheral or just delete the part of the "spaghetti" you don't use but as Danny said the compiler can do this for you.
The risk you take is that you have a non-feature complete peripheral driver.and that a few years from now you do need some of that peripheral functionality you have not supported and someone in the company again has to dive in the datasheets to see how this is done. Probably the person who skipped it in the first place and at that time does not have room in his agenda to again spent time on this
A good practice if you want company (vendor independent) HAL is to write a company defined glue layer on top of the vendors HAL, but that will cost additional codesize.
It's often been speculated here that vendor libraries are written by summer interns. Based on most of this code I've seen, I believe it. While there may be exceptions that I haven't seen, what I have seen I would classify as utter crap.
Sure and risk the companies net worth on a couple of interns? That sounds what a billion$ company would do
No, what I could believe is that some of the early libraries from ST were build by HW engineers that have learned to write software instead of software engineers. Probaly the same team as responsible for part of the HW itself. The good thing is that at least they know how their peripheral should be configured to operate as expected so you can use at least this code as example.
BTW I have also seen HALs from experienced software engineers where most HW engineers/embedded SW engineers could not work with. To give an example we had this new uC prototype from the vendor (so nothing of any kind of SW available) and it had tiny ROM so each byte counted.
What a 20 yr experienced EE educated embedded SW engineer did was write the entire peripheral/clock/interrupt configuration in a very elaborate X-macro.
Actually this was mis using the X-macro principle to its fullest but hey the result was tiny!
Now this worked great if you did exactly how it was supposed to work.
Then came these SW educated SW engineers and all they did was complain because they could not understand the concept of the X-macro, the SCA tool could not understand it and if you made a tiny mistake (a , or ; missed) the whole x-macro would explode but did not show exactly where the problem occurred in that macro. So brilliant, but a nightmare to work with unless you knew exactly what you were doing.
IMO SW is a field of work where you can bitch about much more than HW.
In SW it is very easy to change things, get used to a specific style of coding you personally prefer and if you put 5 SW engineers in a room and tell them to write a simple program they all do it their way and if you ask them to choose the best one there will be a catfight. There are lots of "best practices" some contradicting eachother, newer insights and on and on. If you are used of working in a 30 man SW team you are tired of the coffee corner discussions about this.