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

[coppice]

Long story short, vendor supplied libraries are the software equivalent to evaluation modules (EVMs).

I disagree. Vendors take EVMs far more seriously than they take their libraries. EVMs are a key marketing tool, so they are very important.

[Warhawk]

Long story short, vendor supplied libraries are the software equivalent to evaluation modules (EVMs).

I disagree. Vendors take EVMs far more seriously than they take their libraries. EVMs are a key marketing tool, so they are very important.

Yeah, you're probably right. EVMs are more than libraries, I guess.

[nctnico]

Long story short, vendor supplied libraries are the software equivalent to evaluation modules (EVMs).

I disagree. Vendors take EVMs far more seriously than they take their libraries. EVMs are a key marketing tool, so they are very important.

No. EVMs typically suffer from the same problems as many of the software libraries. They are not production ready circuits. More often than not essential things like protection and EMC filtering are missing.

[coppice]

Long story short, vendor supplied libraries are the software equivalent to evaluation modules (EVMs).

I disagree. Vendors take EVMs far more seriously than they take their libraries. EVMs are a key marketing tool, so they are very important.

No. EVMs typically suffer from the same problems as many of the software libraries. They are not production ready circuits. More often than not essential things like protection and EMC filtering are missing.

Protection and EMC are not usually relevant to achieving a design in. Such parts might be included in an EVM, to promote other products from the same vendor, but if the vendor doesn't make those types of parts themselves its not always a good idea to include and promote someone else's. Its better to leave the customer to select their own choice of parts.

[NorthGuy]

I don't think the libraries are bad. However I think they're useless. They don't provide any benefits, but there's always a possibility of bugs, restriction of your freedom, some extra bloat. So, it's easier to do without them.

[nctnico]

Long story short, vendor supplied libraries are the software equivalent to evaluation modules (EVMs).

I disagree. Vendors take EVMs far more seriously than they take their libraries. EVMs are a key marketing tool, so they are very important.

No. EVMs typically suffer from the same problems as many of the software libraries. They are not production ready circuits. More often than not essential things like protection and EMC filtering are missing.

Protection and EMC are not usually relevant to achieving a design in. Such parts might be included in an EVM, to promote other products from the same vendor, but if the vendor doesn't make those types of parts themselves its not always a good idea to include and promote someone else's. Its better to leave the customer to select their own choice of parts.

But that is what I'd call 'not production ready'.  After all you can't stick the schematic of an evaluation module in your design and expect it to work 100%. EMC is just one example; there are many other pitfalls. Just like the average vendor provided microcontroller libraries.

[coppice]

Long story short, vendor supplied libraries are the software equivalent to evaluation modules (EVMs).

I disagree. Vendors take EVMs far more seriously than they take their libraries. EVMs are a key marketing tool, so they are very important.

No. EVMs typically suffer from the same problems as many of the software libraries. They are not production ready circuits. More often than not essential things like protection and EMC filtering are missing.

Protection and EMC are not usually relevant to achieving a design in. Such parts might be included in an EVM, to promote other products from the same vendor, but if the vendor doesn't make those types of parts themselves its not always a good idea to include and promote someone else's. Its better to leave the customer to select their own choice of parts.

But that is what I'd call 'not production ready'.  After all you can't stick the schematic of an evaluation module in your design and expect it to work 100%. EMC is just one example; there are many other pitfalls. Just like the average vendor provided microcontroller libraries.

You may prefer complete solutions handed to you on a plate, but many other people are alienated by things like that. An EVM can't please everyone.

[alanambrose]

I think often the problem is that the suppliers want to have just one codebase to support a lot of their parts. The codebase therefore ends up having a lot if if/then/that logic as macros / multiple include files - which then makes the whole thing indecipherable. Also, the suppliers seem to recruit people who love to use abstraction to solve that kind of problem - so you also end up getting stupidly deep hierarchies and overly complex design patterns to try and cope with all the options from all the parts they're trying to support.

Typically a programmer using just one part goes 'why do I need 50 source files / 8 hierarchy layers / and 5 different design patterns just to flip a GPIO line when it's just 3 instructions for the uP I'm using? - maybe I'll just junk all the supplied libraries and write my own very condensed and efficient code for my particular application...'

Alan

[IDEngineer]

Typically a programmer using just one part goes 'why do I need 50 source files / 8 hierarchy layers / and 5 different design patterns just to flip a GPIO line when it's just 3 instructions for the uP I'm using? - maybe I'll just junk all the supplied libraries and write my own very condensed and efficient code for my particular application...'

Exactly the same as the classic high- vs. low-level language tradeoff. Purists want to write everything in Assembly because it's the most efficient and compact. Doe-eyed fresh CS graduates want to create a fully architected, fully object oriented, "completely abstracted with zero globals" object d'art. I've had many an argument with both kinds of people. The key is to recognize that while writing everything in Assembly or pre-documenting things like you're applying for a hospital building permit may stroke one's OCD, it may actually take more time than the "savings" are worth for a commercially viable project.

The solution is usually somewhere in the middle. For the architecture case, get it running in a high level language, profile it, and hand-optimize the low-hanging fruit that yields 90% of the benefit for 5% of the effort. For the vendor framework case of this thread, maybe use the part(s) that get you up and running and THEN decide if it's worth the time to write your own vs. debugging the vendor's code.

[Sal Ammoniac]

Typically a programmer using just one part goes 'why do I need 50 source files / 8 hierarchy layers / and 5 different design patterns just to flip a GPIO line when it's just 3 instructions for the uP I'm using? - maybe I'll just junk all the supplied libraries and write my own very condensed and efficient code for my particular application...'

I've been in the embedded industry for 37 years and have worked for lots of companies developing (and managing) embedded products using various microprocessors and microcontrollers. You know how many projects I've worked on that used vendor libraries? Zero.

We always wrote all of our code from scratch. The only time we didn't was when evaluating microcontrollers and needed a quick turnaround, but that was throwaway code anyway. We never found a combination of the MCU features we needed and vendor libraries that weren't complete crap.

Most of the time all we used from the vendor was a .h file that defined all of the MCU's registers and sometimes a linker file.

[IDEngineer]

I've been in the embedded industry for 37 years and have worked for lots of companies developing (and managing) embedded products using various microprocessors and microcontrollers. You know how many projects I've worked on that used vendor libraries? Zero.

I'll second that, with the one caveat that I've often used the compiler's libraries for commonplace things like floating point, etc. And sometimes the compiler is sourced by the the MCU vendor (example: Microchip).

In other words, we don't freshly write our own FP libraries, etc. However, for things like peripheral control, not a chance. The other comments in this thread about them being too cumbersome and buggy are spot-on.

[westfw]

I think there are three main problems:

• Silicon Vendors sell chips, not Software.  It's an attitude.
• the libraries don't get the resources they need.  The accusations are "written by interns or consultants", which might be an exageration. but the reality is probably "written by people/teams who aren't around for the next 10 years listening to customers, refining, improving, fixings, adding, simplifying, and etc.
  "Next Gen" libraries (Atmel Start vs ASF vs libsam) appear to go off in different directions.
• The sort of abstraction that would be most useful for end "users" would also result in functions that were more portable between different vendors' chips, and that is NOT a "desirable outcome" for the vendor.

[Warhawk]

I think there are three main problems:

• Silicon Vendors sell chips, not Software.  It's an attitude.
• the libraries don't get the resources they need.  The accusations are "written by interns or consultants", which might be an exageration. but the reality is probably "written by people/teams who aren't around for the next 10 years listening to customers, refining, improving, fixings, adding, simplifying, and etc.
  "Next Gen" libraries (Atmel Start vs ASF vs libsam) appear to go off in different directions.
• The sort of abstraction that would be most useful for end "users" would also result in functions that were more portable between different vendors' chips, and that is NOT a "desirable outcome" for the vendor.

That's practically what I described couple posts back. I agree.

[AkiTaiyo]

Working with mostly microcontrollers I've had a mixed bag of result with libraries from the hardware vendors. 
I often find that with peripherals of more complexity than GPIO, its often easier to work through the datasheet and write my own driver to do the job rather than using the library.  There a couple of advantages to this.  One, I know how the code works, and two I know how the hardware works, and this makes fault finding a heck of a lot easier.
Often vendor libraries are designed to be very general purpose, and I've seen it before where some libraries do simple things (like toggling an IO) taking several times the number of instructions as it needs to (even on optimised builds), just because theres extra checks for certain conditions.
Most 'simple' hardware (i2c, spi, adc etc) on microcontrollers only require a few registers setting up to be able to use, and once you have read the relevant parts of the data sheet and programmed the registers manually, you'll wonder what the heck all the code does in the vendor library!
Going another step, I do tend to use libraries for more complicated features such as ethernet drivers.  Having said that, however, I did huge issues with bugs in the STM32H7 ethernet library when that family was first released, ended up re-writing most of the driver in the end, but this highlights an issue with libraries that aren't mature. 
In terms of good vendor libraries I’ve worked with, the EFMLib suite for the EFM32 Gecko micros from Silicon Labs are very simple, and usually get straight to the point.  But as a counter argument, the hardware is also very easy to work with, which makes writing your own drivers easy too!
I’ve come across a lot of microcontroller developers who have no concept of how the hardware works, and have never looked at a microcontroller datasheet due to an over-reliance on libraries.  One particularly bad example used a library that worked entirely with floating point numbers, and then complained about not having any space (or performance) on an ATMega..

[Sal Ammoniac]

I’ve come across a lot of microcontroller developers who have no concept of how the hardware works, and have never looked at a microcontroller datasheet due to an over-reliance on libraries.

 
I've also come across of lots of people like this. As a hiring manager, I find it strange that people apply for jobs as embedded engineers yet have no real knowledge of how peripherals work at the hardware level. These people typically also don't know how to use hardware debugging tools (oscilloscopes and logic analyzers), nor do they know the hot end of a soldering iron from the cold end. They also typically don't know any assembly language, even enough to interpret a disassembly let alone write any. They tend to rely on canned libraries and want everything abstracted out for them. 

[IDEngineer]

When I find people like this, they're often CS graduates who drifted into embedded work "because it's all just software". IMO the best embedded developers come from a hardware background and picked up software along the way. That kind of person understands how to effectively balance doing things in hardware vs. software/firmware. Said differently, they know how to optimize the overall architecture.

[NorthGuy]

They tend to rely on canned libraries and want everything abstracted out for them.

If you write a program for OS (such as Windows or Linux), you do not know what hardware your program is going to run on. For example, if you read a file it may be on HDD, SSD, or even a remote server thousand miles away. Therefore, an abstraction layer (which is a part of the OS) is needed, and you must use OS-supplied libraries. Typically, if you try to write something hardware specific, this is bizarre because your program will not work on PCs with different hardware.

This way of thinking has been transferred without changes to the embedded world. Even though you select the MCU by yourself and the underlying hardware is well known and documented, many people believe that the software for MCU must be written as if you don't know the hardware, and therefore  abstraction layer is a must. I'm sure there are people who would even consider bizarre studying the underlying hardware, or even knowing anything about it. As time goes by, there will be more of this.

[schmitt trigger]

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.

I knew a studio photographer whose specialty was making food-related ad photos.

As you have noted, the food company requesting the photos, would provide "samples" which were not only bigger, but had been tweaked (in the hamburger example, more sesame seeds would be sprinkled on the bun)

Additionally, there were things that were definitively non-edible but look good on a photo. The hamburger patties were spray-coated with clear acrylic, and fruits and vegetables were waxed with liquid auto wax.

There were other tricks, but this is what I recall from memory.

[nctnico]

They tend to rely on canned libraries and want everything abstracted out for them.

If you write a program for OS (such as Windows or Linux), you do not know what hardware your program is going to run on. For example, if you read a file it may be on HDD, SSD, or even a remote server thousand miles away. Therefore, an abstraction layer (which is a part of the OS) is needed, and you must use OS-supplied libraries. Typically, if you try to write something hardware specific, this is bizarre because your program will not work on PCs with different hardware.

This way of thinking has been transferred without changes to the embedded world. Even though you select the MCU by yourself and the underlying hardware is well known and documented, many people believe that the software for MCU must be written as if you don't know the hardware, and therefore  abstraction layer is a must. I'm sure there are people who would even consider bizarre studying the underlying hardware, or even knowing anything about it. As time goes by, there will be more of this.

Yes and no. Yes it makes sense and no, we aren't there yet. For starters there is no standard API among vendors. Vendor libraries have evolved to somewhat useful levels only recently. All in all it will take quite a bit of time before we will see some kind of standardisation. Probably at the cost of quite a bit of bloat but by then it won't matter anyway. I can imagine that somewhere in the future the API may look like how Linux accesses SPI, CAN, I2C, etc busses. That concept has been proven and the performance is actually not bad.

[NorthGuy]

I can imagine that somewhere in the future the API may look like how Linux accesses SPI, CAN, I2C, etc busses. That concept has been proven and the performance is actually not bad.

You're right. During last 25 years I have witnessed how tremendous progress in hardware technology has been eaten by equally great software bloat. Now, I see exactly the same process in MCUs. Similarities are striking.

[IDEngineer]

Typically, if you try to write something [PC] hardware specific, this is bizarre because your program will not work on PCs with different hardware.... This way of thinking has been transferred without changes to the embedded world. Even though you select the MCU by yourself and the underlying hardware is well known and documented, many people believe that the software for MCU must be written as if you don't know the hardware, and therefore  abstraction layer is a must. I'm sure there are people who would even consider bizarre studying the underlying hardware, or even knowing anything about it. As time goes by, there will be more of this.

I certainly hope not. The two use cases are radically different. PC's are a mix-and-match hardware environment controlled by the constructor/user. Embedded systems are generally 100% controlled by the manufacturer. The choice of MCU is (or should be) intimately linked to the job it is asked to perform, unlike the PC which is a general purpose computing platform. MCU's have wildly differing complements of (on-chip) peripherals, which are not cross-brand compatible at the software and generally the hardware level. That's often true of PC's but the key difference is that the embedded manufacturer and software author knows about the hardware when they select it, implement it, and program for it.

To introduce abstraction into that environment is to follow PC's down the path of extreme wastefulness of cost and CPU cycles. If I don't need floating point hardware in my embedded application I certainly don't want to pay for it. If I can optimize for a 28 pin package I certainly don't want to pay for a 100 pin BGA nor the PCB design rules to support it. Embedded environments should be the very essence of proper architecture and optimized design.

Abstraction in embedded environments is a Very Bad Idea. Hire better Engineers instead.

[ice595]

My biggest gripe with vendor supplied SDKs or libraries is that sometimes they're already pre-compiled and closed sourced.
You can't easily dig under the hood and add a slight mod or fix bug if you find any.

[SilverSolder]

Typically, if you try to write something [PC] hardware specific, this is bizarre because your program will not work on PCs with different hardware.... This way of thinking has been transferred without changes to the embedded world. Even though you select the MCU by yourself and the underlying hardware is well known and documented, many people believe that the software for MCU must be written as if you don't know the hardware, and therefore  abstraction layer is a must. I'm sure there are people who would even consider bizarre studying the underlying hardware, or even knowing anything about it. As time goes by, there will be more of this.

I certainly hope not. The two use cases are radically different. PC's are a mix-and-match hardware environment controlled by the constructor/user. Embedded systems are generally 100% controlled by the manufacturer. The choice of MCU is (or should be) intimately linked to the job it is asked to perform, unlike the PC which is a general purpose computing platform. MCU's have wildly differing complements of (on-chip) peripherals, which are not cross-brand compatible at the software and generally the hardware level. That's often true of PC's but the key difference is that the embedded manufacturer and software author knows about the hardware when they select it, implement it, and program for it.

To introduce abstraction into that environment is to follow PC's down the path of extreme wastefulness of cost and CPU cycles. If I don't need floating point hardware in my embedded application I certainly don't want to pay for it. If I can optimize for a 28 pin package I certainly don't want to pay for a 100 pin BGA nor the PCB design rules to support it. Embedded environments should be the very essence of proper architecture and optimized design.

Abstraction in embedded environments is a Very Bad Idea. Hire better Engineers instead.

You could argue that having some kind of API makes it easier to port the code from one processor to another (even in the same family)?

Also, is a PC really "extreme wasteful of cost and cycles" when you think how general purpose a PC has to be - meaning, it cannot really be optimized for a single task?

[nctnico]

Typically, if you try to write something [PC] hardware specific, this is bizarre because your program will not work on PCs with different hardware.... This way of thinking has been transferred without changes to the embedded world. Even though you select the MCU by yourself and the underlying hardware is well known and documented, many people believe that the software for MCU must be written as if you don't know the hardware, and therefore  abstraction layer is a must. I'm sure there are people who would even consider bizarre studying the underlying hardware, or even knowing anything about it. As time goes by, there will be more of this.

I certainly hope not. The two use cases are radically different. PC's are a mix-and-match hardware environment controlled by the constructor/user. Embedded systems are generally 100% controlled by the manufacturer. The choice of MCU is (or should be) intimately linked to the job it is asked to perform, unlike the PC which is a general purpose computing platform. MCU's have wildly differing complements of (on-chip) peripherals, which are not cross-brand compatible at the software and generally the hardware level. That's often true of PC's but the key difference is that the embedded manufacturer and software author knows about the hardware when they select it, implement it, and program for it.

To introduce abstraction into that environment is to follow PC's down the path of extreme wastefulness of cost and CPU cycles. If I don't need floating point hardware in my embedded application I certainly don't want to pay for it. If I can optimize for a 28 pin package I certainly don't want to pay for a 100 pin BGA nor the PCB design rules to support it. Embedded environments should be the very essence of proper architecture and optimized design.

Abstraction in embedded environments is a Very Bad Idea. Hire better Engineers instead.

That is old way thinking. Modern embedded projects need all kinds of connectivity. Even refridgerators and washing machines are connected to the internet nowadays. That means tons of code and lots of development time. Suddenly the embedded firmware represents a boatload of money. One way to protect investment in software is making sure it is re-usable and cross-platform. So yes, a universal API makes all the sense of the world. Processing power is cheap anyway nowadays (without needing BGA packages).

Come to think of it... I already have my own API with underlying functions which is cross-platform across many microcontrollers. And it isn't bloated at all. In the end an I2C interface from manufacturer A doesn't do anything different compared to the one from manufacturer B.

[NorthGuy]

Come to think of it... I already have my own API with underlying functions which is cross-platform across many microcontrollers. And it isn't bloated at all. In the end an I2C interface from manufacturer A doesn't do anything different compared to the one from manufacturer B.

Why would you waste your time making it compatible across manufacturers when you (by your own words) always use LPC?

There are different situations. You may need to read I2C only at the beginning (such as memory SPD, or some sort of boot EEPROM), or you may have a dozen devices on the same I2C bus which you car read relatively fast, so that you need to master some kind of arbiter or queue to make sure your tasks don't interfere to each other. You may decide that you need to use interrupts or not. You may use DMA or not.  You may need to deal with 7-bit addresses vs 10-bit addresses. By the time you write the "driver" which covers all the situations, it will be

1. relatively big, representing substantial amount of bloat
2. difficult to use, because it is designed to cover huge number of situations
3. complex, which means potentially more buggy
4. expensive, because you spent time making sure it works for all situations, even the situations you will never encounter
5. useless, because all you need to do without it is just write few registers, which cannot really be simplified by much