Why most people say "vendor supplied libraries are bad"?

[chancs]

I am pretty new to embedded programming. And only have worked on a few projects that utilized AVR and STM32 through uni and personal interest. Whenever I start a coding project, ill use the manufacturer code generator to get the template done, so when I need to send data through SPI, I can just use HAL_SPI_Transmit instead of setting up the register myself. So is the HAL library provided by ST bad? Also, is the FatFs library bad? And if so where can I find a proper library or is there any online course that teach you how to write a correct library?

[josip]

I am pretty new to embedded programming. And only have worked on a few projects that utilized AVR and STM32 through uni and personal interest. Whenever I start a coding project, ill use the manufacturer code generator to get the template done, so when I need to send data through SPI, I can just use HAL_SPI_Transmit instead of setting up the register myself. So is the HAL library provided by ST bad? Also, is the FatFs library bad? And if so where can I find a proper library or is there any online course that teach you how to write a correct library?

From my experience, vendor code is hard to read and understand, poorly commented, bloated and not-enough tested in the real life. Even if you find some bugs, and report this, they don't care.

uTasker (https://github.com/uTasker) for Kinets and ST is open and free, even with free device simulation (VS 2015 Community). With readable and good commented code.

[Siwastaja]

It's mostly an actual observation of the code actually being broken beyond usable, not a "principle" thing.

[SiliconWizard]

It's mostly an actual observation of the code actually being broken beyond usable, not a "principle" thing.

Yes. Not always completely objective though.

I've looked at the HAL code (STM32) thoroughly, and I don't find it broken beyond usable.
Sure some choices are debatable, but I also know almost no two developers would agree on a given function, so it's very relative.

And then it's often considered "bloated". But this bloat comes from the fact each function is written to cover the most cases possible. Of course if you write your own code, you're likely to write it adapted to your own needs and it will be much more efficient.

Beyond objective judgement of quality, one reason not to use vendor-supplied code is that it will just be inconsistent with your own coding style/rules. Which may be a severe problem in some projects/teams.

But vendor-supplied libraries (at least for basic support, such again as the HAL from ST) are not the worst overall IME. Much worse usually are any provided code/example projects outside of base libraries. They are often written poorly with little consistency, and the vendor usually clearly states that they shouldn't be used for production stuff.

[rstofer]

A company making widgets has to guarantee every aspect of the product including the chip vendor's code, if they use it.  Do they really want to ship code they didn't write?  Is the Tuesday version backwards compatible with last Monday's?

[donotdespisethesnake]

To be fair, most software is bad.

A particular problem for vendors is that the library code is general purpose, so tends to be larger and more complicated than required for a specific use case. It's impossible to test for every such configuration, so the code is inevitably buggy. Fixing and maintaining the code is a project in itself, whereas the vendor needs to direct effort to implementing support for new devices.

The way I see it is that vendor code is a "serving suggestion". Adapt it for your own needs, and don't blindly rely on it.

[IDEngineer]

The way I see it is that vendor code is a "serving suggestion". Adapt it for your own needs, and don't blindly rely on it.

This.

In my experience it's dangerous, and often impossible, to use vendor code for anything beyond familiarity. Remember, their real job is selling hardware. They probably view sample code as a necessary evil, which is evidenced by their often low quality and basically zero "support". If you or I were running a hardware manufacturing company we'd probably feel the same way, unless the code side of the business was self-sustaining. "Free" libraries and demo code have a hard time being self-sustaining.

The one time in the last ~10 years or so that I used canned vendor source code, I ended up having to debug literally every line, stepping through the source in real time to ferret out all sorts of (not so) edge conditions that hadn't been handled. The feeling I got was that the code demonstrated their hardware (likely their only goal), and worked when everything went as planned. I had to insert all sorts of error handling to make it survive even the simplest of fault conditions. To be fair, the code DID accomplish its mission: I became very familiar with the technology in question, and their specific implementation of it. I'm not sure if, when it was all over, I "saved" any time by starting with and fully debugging their demo code versus just reading specs and grinding out my own from scratch. But their code did get me started so it's hard to complain too much.

Other than this one instance, I can't remember relying on vendor samples or "libraries" or "frameworks" or whatever in at least the last decade. And that experience didn't warm me to the concept. I think the safest course is to presume you will have to roll your own, and if there's some demo stuff to get you started then consider it as an introductory course - not your final product.

[wizard69]

A company making widgets has to guarantee every aspect of the product including the chip vendor's code, if they use it.  Do they really want to ship code they didn't write?  Is the Tuesday version backwards compatible with last Monday's?

This isn't really valid in most cases these days.   This mainly due to projects often using some sort of embedded kernel or Real Time OS that wan't written buy the user.   On the larger scale you have Linux, WinCE or some other operating system embedded in the device.  If the project is so small that none of the above apply the usual reason is code space which is a different issue.

[nctnico]

I've looked at the HAL code (STM32) thoroughly, and I don't find it broken beyond usable.
Sure some choices are debatable, but I also know almost no two developers would agree on a given function, so it's very relative.

Perhaps the STM32 HAL is an exception to the rule. They even tout it is MISRA compliant. Still it is something you'll need to learn how to use it -like any library-.

[Siwastaja]

Note, there's a big difference between general purpose computer software, and microcontroller firmwares.

What a usual "software developer" person understands with a "library", is a thing that would take possibly tens of thousands of Lines of Code, and months of development time to replicate. Libraries are essential in any large software project so you don't need to reinvent the wheel every time. Examples include printf with all the formatting stuff, or larger things like computer vision algorithms.

In the microcontroller world, this is sometimes the case, but often not. Remember, even with the microcontrollers (except the very tiniest ones), the standard C libraries still exist (printf, math, etc...), as do the more specialized stuff (like OpenCV) if you have a beefy enough MCU.

That's why they ("most people" referred in the title) talk about vendor supplied libraries. The big question is, what purpose do these libraries serve? The obvious answer is, they most often abstract the hardware.

But, with microcontrollers, the hardware is designed from scratch to be simple to control. Often just some 2-5 lines of code to configure a peripheral, and 2-3 to use it. So now, obviously with little technical need for the abstraction layer, but a corporate policy need instead, the task of creating mostly unnecessary libraries are left to those who are not the brightest minds in that company.

As a result, it's usual to see the pattern that it takes 100 LoC and 5 hours of development time to do things X,Y and Z on a microcontroller. With libraries, it may take 200 LoC just to "configure" and "use" the library, and likely 10 hours of development time; if it's possible to do the combination of X,Y and Z using the libraries at all. Having to link in 10000 LoC of something likely buggy is an added non-bonus.

Usual examples include the GPIO and basic peripheral (thing about UART, SPI, ADC...) configuration using the STM32 libraries (easily 50 lines per peripheral, never written by the developer, always copy-pasted from Stack Overflow, example projects, or autogenerated) which provide no abstraction whatsoever - all the low-level details are exposed in the library "instantiation" code, but in a way which makes debugging harder. Naturally, any sane programmer does not use such practices, and will therefore say "vendor supplied libraries are bad", from experience of seeing such patterns.

This being said, I'm sure some good and usable vendor-supplied MCU libraries exist.

[coppice]

Perhaps the STM32 HAL is an exception to the rule. They even tout it is MISRA compliant. Still it is something you'll need to learn how to use it -like any library-.

Was the comment about MISRA intended as a joke, or was that serious?

[hansd]

I don't understand why you go on and on about MCU manufactures efforts to supply customers with some code and tools. Just write it yourself and publish it somewhere so it can be scrutinized.

[SiliconWizard]

Perhaps the STM32 HAL is an exception to the rule. They even tout it is MISRA compliant. Still it is something you'll need to learn how to use it -like any library-.

Was the comment about MISRA intended as a joke, or was that serious?

It's a fact. Quoting ST:

Both the HAL and LL APIs are production-ready and have been developed in compliance with MISRA-C:2012 guidelines with some documented exceptions (reports available on demand) and ISO/TS 16949. Furthermore, ST-specific validation processes add a deeper-level qualification.

The "some documented exceptions" (which you'll have to ask for) could be concerning, but outside of some specific domains, MISRA rules are often adapted to each individual project and/or company if they are enforced anyway.

I've also passed the HAL code through a couple static analysis tools that I routinely use (ST claims to be using CodeSonar), and didn't find any major issue with those.

As some of us said above, there are a number of reasons you wouldn't want to use those libraries, but they are not nearly as bad as it seems hype to say.

As hansd just said, please do not hesitate to publish your own libs so everyone can inspect them as we can do with vendor-supplied code and see if they are really that much better. I've seen alternative source code out there, and obviously it's different, but rarely objectively much better. Just a bit different.

It's ultra common among software devs to find other devs' code utter crap. As donotdespisethesnake said, most software is bad anyway - which is a relatively to-the-point way of summing it up.

The real main point IMO is the question whether it's worth it to use off-the-shelf, general-purpose libraries/code compared to writing it yourself (allowing you to have complete control over functionality, code style, compromises, etc.) The answer can't be general. It all depends on the size of your team, the project, the policies, the desired time-to-market, long-term maintenance, etc.

[coppice]

Perhaps the STM32 HAL is an exception to the rule. They even tout it is MISRA compliant. Still it is something you'll need to learn how to use it -like any library-.

Was the comment about MISRA intended as a joke, or was that serious?

It's a fact.

I wasn't questioning the factuality. I was questioning whether quoting MISRA compliance as a measure of quality was a joke.

[ajb]

A particular problem for vendors is that the library code is general purpose, so tends to be larger and more complicated than required for a specific use case.

And even then, it often misses certain use cases, and if it doesn't provide access to the functionality your application needs then you're back to square one.  Think about things like the advanced timers in many modern MCUs, there's no way they're going to be able to provide access to even a substantial fraction of the possible functionality in a clean and usable way.

The complaint about vendor libs being "bloated" are not just academic, or a matter of preference.  Atmel's ASF USB CDC implementation on the SAM D series is ~15kB, optimized.  Many parts in that line only have 16kB of flash!  For contrast, forum member ataradov has a full USB<->UART implementation that compiles to ~4kB and is no less readable.  There's also a DFU bootloader for the SAMD11/21 that only takes 1kB.

Also, is the FatFs library bad?

Assuming you're talking about the ELM lib everyone seems to use, that library is solid, AFAIK, it's slim, well documented, and pretty robust. 

[GromBeestje]

I've been looking at ST's libraries (the ones on github) and Nordic's nrfx. They seem quite good. Those are the microcontrollers I'm involved with, so I can't tell much for others.

However, when looking at an example project provided by ST for their S2LP wireless chip, there are a number of abstraction layers in there, that's horrible code. The driver itself, I guess it's okay, but the example project, pure horror.

[Sal Ammoniac]

The way I see it is that vendor code is a "serving suggestion".

This is a very good analogy. Ever see an ad for, say, a McDonald's Big Mac? It looks perfect. Go to McDonald's and buy one and it's squashed, the lettuce yellow-green and wilted, etc.

Vendor libraries as described in vendor marketing materials are like the Big Mac in the ad, while in reality the code is like what you get in an actual Big Mac.

[westfw]

On the one hand, it's nice that vendor libraries seem to be "improving."On the other hand, one advantage of using someone else's libraries is that they ought to be consistent, rather than changing significantly from release to release...  Which doesn't seem to be what is happening.

[IDEngineer]

This is a very good analogy. Ever see an ad for, say, a McDonald's Big Mac? It looks perfect. Go to McDonald's and buy one and it's squashed, the lettuce yellow-green and wilted, etc.

Agreed, but MY thought was of microwave meals (old name: "TV dinners"). Ever looked at their box photos? It looks like fine dining served up on a beautiful plate in a nice restaurant. Never in my life have I ever seen anyone plate out a microwave meal like the "serving suggestion" on the box (and yes, that's exactly the caption they use). That's presuming it's even possible to make it look like the photo after being injected/dispensed into the plastic tray and then frozen into semi-homogenous chunks that rattle when the box is shaken.

You're totally correct about Big Macs, but at least they generally resemble their advertisements. Microwave meals... well, let's just say the photos are "optimistic". Kinda like vendor supplied libraries! 

[lucazader]

At work we use the STM HAL and even the cube to generate the start of the project etc.
We have tested the parts of the HAL that we use quite a bit and they work well for us (with one or two bugs that we have worked around).
For us it has definitely been quicker to use their libraries than it would have been getting up and running from scratch.
Especially as we are now making new products with super similar product architectures. generating the project using the cube gets us about 75% of the way to a full bsp for the new products.

Another good sign that i see with the STM hal going forward is that they have put all of the code on github (easy to integrate as a submodule in git now, YAY!)
And they are also tracking bugs and user suggestions on github, so hopefully code quality etc will improve over time.

[nctnico]

Perhaps the STM32 HAL is an exception to the rule. They even tout it is MISRA compliant. Still it is something you'll need to learn how to use it -like any library-.

Was the comment about MISRA intended as a joke, or was that serious?

Serious. Not judging code style but I have looked through the code and it seems to adhere to at least the basic rules. Note that the MISRA rules are code style requirements like not using function pointers. Don't mistake MISRA as a measure of code quality; it is intended to avoid basic mistakes. And there are also several versions of the MISRA rules to make things even more complex.

[nctnico]

But, with microcontrollers, the hardware is designed from scratch to be simple to control. Often just some 2-5 lines of code to configure a peripheral, and 2-3 to use it. So now, obviously with little technical need for the abstraction layer, but a corporate policy need instead, the task of creating mostly unnecessary libraries are left to those who are not the brightest minds in that company.

In general I agree with this statement. A lot of vendor provided code is just crap written by interns. IMHO the reason why ST is an exception is because they have to provide a thick layer of abstraction because the peripherals in ST microcontrollers are allover the place and not always easy to configure. You can't simply port bare metal code from one controller to the other. Without portability ST would lose quite a bit of business because the NRE costs of using their controllers is too high (which I why I never use ST microcontrollers).

[coppice]

Perhaps the STM32 HAL is an exception to the rule. They even tout it is MISRA compliant. Still it is something you'll need to learn how to use it -like any library-.

Was the comment about MISRA intended as a joke, or was that serious?

Serious. Not judging code style but I have looked through the code and it seems to adhere to at least the basic rules. Note that the MISRA rules are code style requirements like not using function pointers. Don't mistake MISRA as a measure of code quality; it is intended to avoid basic mistakes. And there are also several versions of the MISRA rules to make things even more complex.

MISRA is a hotchpotch of very sensible measures to reduce silly mistakes, and dumb measures that force you to code in more obscure ways that promote errors. Most code that claims to be MISRA complaint comes with a bunch of caveats.

[Siwastaja]

Oh, MISRA is great. It's a style guide, mostly a good one, partially a disaster; but as a style guide only, it has very limited scope when it comes to code quality, where the correct design and verification are the keys, and whether some specific C keyword was used or not, is completely irrelevant.

But it serves an excellent indication purpose. Whenever someone claims that their code being "MISRA compliant" means anything about the code quality, usability or robustness, instantly proves zero understanding about what they are talkinga bout, completely disqualifying the code in one go. "MISRA compliant" is almost a guaranteed "no guarantee" thing.

STM32 HAL code is mostly acceptable, the code quality isn't the problem; the problem is that you don't need it, and it limits the possibilities of the capable hardware. The problem is that in many real-world cases you can't do what you want to do with the STM32 HAL because it fails to generalize and abstract most more sophisticated features (to be fair, it isn't easy to design such generalized abstraction), for which you still need to understand and write directly for the low level. Then you end up with a strange mix of HAL code and your own low-level code; and for that to work, you need to really read all the HAL code to understand what resources it uses and how it interferes with your own stuff.

Since most of the "HAL things" only take 5-10 LoC to DIY, it's more sustainable not to use it so you keep the understanding and maintainability.

[Warhawk]

• Our CEO said that we sell sillicon, not software. This gives you the impression how much effort we invest into libraries development.
• Quality sucks. Libraries are either outsourced or written by young engineers. Most of them have never been deployed to real product development.
• We used to do line-by-line review with my previous employer. Imagine doing this with STM32 libraries I do not like any extra code that is not used in the application.
• It is important to keep same style across the complete SW package. What's your favorite? unsigned char, unsigned int8, uint8, uint8_t, uint_fast8_t....
• When it becomes obsolete? When that single guy leaves or when the CEO changes? Who will support it? What do you do when you find a bug?

Long story short, vendor supplied libraries are the software equivalent to evaluation modules (EVMs). They are used for internal debugging, proto-boards and getting things done quickly. By no means they should be deployed in professional environment. Big companies, that are the significant source of income for semi vendors, do their development from the scratch. Nobody cares for small fish.

Sure, it's not black and white, but you asked why.

Stay away from it! 
PS: Code snippets are great though.

Just my $0.02