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

[Bassman59]

Yesterday i unpacked a ATSAMC21 explained pro kit to start development of a simple adapter board that is to conver/transmit I2C messages from a Sensirion SHT35 sensor and SPI data to a Can bus. So i spent about 20 hours on that and the application layer still needs to be refactored.
Without using Atmel Software Framework that wouldn't have been possible. I can tell you that i got furious yesterday when i lost about four or five hours trying to import the generated project into IAR. For the time being i gave up, because i got hard faults.

ASF, for all of its indirection and that it covers too many devices, is ultimately "reasonable." But still, figuring out how to implement a standard USB Device class that they don't support is really not Xplained in any reasonable manner. (DOxygen is NOT documentation!)

Of course the same devices in MPLAB X? Fuck that noise.

(Edit: ugggh, just checked. ASF examples in Atmel Studio 7 have links to API references and QuickStart guides and all sorts of stuff -- and Microchip shitcanned all of that stuff and the links just go to the Microchip home page.)

[dietert1]

I mean this is what it is. Software work isn't fun unless you are free to follow your fantasies of self written HAL layers and the like.

Sure, if your goal is a quick and dirty project (or, heaven forbid, product), and you don't have time to do it right, then using vendor libraries may be a time saver. In my opinion, a well-engineered product practically demands the use of custom-written peripheral drivers.

I guess you are completely wrong. You will rather end up in a quick and dirty project, if you don't master the vendor supplied framework. You will forget to initialize hardware registers that need initialization and so on and so on. You will misunderstand specs. The very claim that you can do better than the engineers working at the vendor, is to be considered "quick and dirty".

Regards, Dieter

[nctnico]

I mean this is what it is. Software work isn't fun unless you are free to follow your fantasies of self written HAL layers and the like.

Sure, if your goal is a quick and dirty project (or, heaven forbid, product), and you don't have time to do it right, then using vendor libraries may be a time saver. In my opinion, a well-engineered product practically demands the use of custom-written peripheral drivers.

I guess you are completely wrong. You will rather end up in a quick and dirty project, if you don't master the vendor supplied framework. You will forget to initialize hardware registers that need initialization and so on and so on. You will misunderstand specs. The very claim that you can do better than the engineers working at the vendor, is to be considered "quick and dirty".

In the end it depends greatly on the quality of the vendor library whether it is suitable to use or not. While reading this thread I see several people clinging on to a past where vendor libraries where just half-assed code examples. Things have improved since then. ST's more recent libraries are actually useful and look to be well written. You have to be really careful to not fall for the 'not invented here syndrom'. What looks like a quick protect at the beginning can balloon into a really large project. Also trying to create a truly universal library is not very useful; it becomes a useless quest for the holy grail. The most (time) efficient way forward is to find a middle ground between using a vendor library & learning to use it versus writing your own.

[Sal Ammoniac]

I mean this is what it is. Software work isn't fun unless you are free to follow your fantasies of self written HAL layers and the like.

Sure, if your goal is a quick and dirty project (or, heaven forbid, product), and you don't have time to do it right, then using vendor libraries may be a time saver. In my opinion, a well-engineered product practically demands the use of custom-written peripheral drivers.

I guess you are completely wrong. You will rather end up in a quick and dirty project, if you don't master the vendor supplied framework. You will forget to initialize hardware registers that need initialization and so on and so on. You will misunderstand specs. The very claim that you can do better than the engineers working at the vendor, is to be considered "quick and dirty".

I am not wrong--quite the opposite. Forgetting to initialize hardware registers and misunderstanding specs is the mark of a careless engineer, not someone who doesn't use vendor libraries. And why can't I do better than the engineers working at the vendor? Have you seen some of the garbage they've generated? I have, and it ain't pretty.

If you want to drink the vendor libraries Kool-Aid, be my guest, but don't imply that doing so is the only correct way to implement an embedded project because it's not. 

[dietert1]

There is a difference between writing a software framework and an embedded project. Some people just don't get it.

Today i found a PDF manual of the Atmel Software Framework that i used as an example before. It has 800 pages. Which means the idea to do something like that for an embedded project is plain nonsense. With modern silicon there is no other chance but using IP. If you can't get it from the vendor, try to get it somewhere else, but don't start DIY. It's a waste of time and you won't get anywhere except blinking a LED. Better spend the time to master the vendor framework.

Regards, Dieter

[Sal Ammoniac]

There is a difference between writing a software framework and an embedded project. Some people just don't get it.

Today i found a PDF manual of the Atmel Software Framework that i used as an example before. It has 800 pages. Which means the idea to do something like that for an embedded project is plain nonsense. With modern silicon there is no other chance but using IP. If you can't get it from the vendor, try to get it somewhere else, but don't start DIY. It's a waste of time and you won't get anywhere except blinking a LED. Better spend the time to master the vendor framework.

But when I do an embedded project with an MCU my goal is not to write a complete software framework for the part! Far from it...

Here's an example. For my last project I used an STM32 MCU. I needed UART, GPIO, and CAN for this project. I wrote peripheral drivers* for these peripherals and used them in my project. This MCU also has I2C, SPI, Ethernet, USB, timers, ADC, DAC, LCD and camera interfaces, and more, but I used none of them so I didn't need to write drivers for any of them.

My point here is that you don't need to write a full software framework for a part to use it in a project because you probably won't be using all of the peripherals the part supports. Another point is that the drivers I did write did not need to support every possible option supported by the hardware--I only support the specific features I needed.

You say that with modern silicon there's no choice but to use IP. This is an exaggeration that's not true in the real world. Using my own career as an example, I've worked at several companies over 35 years developing embedded products, and at none of them did we use vendor libraries--we wrote peripheral drivers from scratch. There were many reasons to do so, but the main reasons were quality and control. Many of these were large, complex projects and this experience disproves your assertion that by not using vendor libs we'd wouldn't get anywhere except blinking an LED.

I'll continue to stand by my opinion that using vendor libs is for lazy and/or inexperienced engineers who don't have the skill to write proper peripheral code themselves.

*Actually, I didn't even need to write the drivers for this project because I wrote them for previous projects. I just adapted them as required, which was a trivial task.

[IDEngineer]

Here's an example. For my last project I used an STM32 MCU. I needed UART, GPIO, and CAN for this project. I wrote peripheral drivers* for these peripherals and used them in my project.

This is very interesting. You actually write discrete drivers? When I'm doing embedded MCU code the control of the peripheral in question is sort of interleaved with the code that manipulates the data associated with that peripheral. I find this yields smaller code that often allows overlapped/parallel operations without having to create a psuedo-RTOS type environment. It never occurred to me to write "standalone" drivers and then invoke them. I understand their value in terms of reusability but generally when interacting with a given peripheral the things you want/need to do are very similar anyway so "porting" the code has never incurred much effort.

[Bassman59]

There is a difference between writing a software framework and an embedded project. Some people just don't get it.

Today i found a PDF manual of the Atmel Software Framework that i used as an example before. It has 800 pages. Which means the idea to do something like that for an embedded project is plain nonsense. With modern silicon there is no other chance but using IP. If you can't get it from the vendor, try to get it somewhere else, but don't start DIY. It's a waste of time and you won't get anywhere except blinking a LED. Better spend the time to master the vendor framework.

I agree. Spending timing dicking around with register access is one thing on an 8051, but it's something else entirely on a Cortex M4F. I really want the vendor to give me a function that does all of that for me.

I just want the vendor libraries to be well-documented and well-supported.

ASF is an interesting example, as the libraries are decent (except for USB). But the problem is that the code covers all/most of their device families, hence the bloat. I understand the perspective of the vendor. They want to have only one library to support. They want to present only one API so their customers don't have to re-learn something entirely new with each device family.

Seems to me that rather than putting a shit-ton of #ifdefs and exclusions and such in the body of the code to support the disparate device families, instead they should provide libraries that each support only one device family. To support portability, the headers/API for common functions should be the same across different families. It's just the underlying implementation that should be specific. Don't give the user extra code that the compiler will sort out.

The SiLabs EFM32 libraries seem to strike a good balance between clarity and device support and I haven't had a problem getting them to work in short order. The one thing I did on an LPC55S28 went easily enough using their peripheral library.


There is always these assertions that "vendor libraries are written by summer interns," and that "support and software are just expenses for the chip vendors, and they want to eliminate those expenses." As attorneys like to say, "those assertions are based on facts not in evidence." I think that the vendors provide libraries because they need to. They want to sell chips, so the best way to do that is to help the customer by making it easier to use the chips. And it's obvious that a potential customer will see, "vendor XYZ has a free toolchain, why should I pay $1000 a seat for yours?" So it's incumbent on the chip manufacturers to provide tools that actually help their customers. Whether they do so or not is a different discussion.

[Bassman59]

Here's an example. For my last project I used an STM32 MCU. I needed UART, GPIO, and CAN for this project. I wrote peripheral drivers* for these peripherals and used them in my project.

This is very interesting. You actually write discrete drivers? When I'm doing embedded MCU code the control of the peripheral in question is sort of interleaved with the code that manipulates the data associated with that peripheral. I find this yields smaller code that often allows overlapped/parallel operations without having to create a psuedo-RTOS type environment. It never occurred to me to write "standalone" drivers and then invoke them. I understand their value in terms of reusability but generally when interacting with a given peripheral the things you want/need to do are very similar anyway so "porting" the code has never incurred much effort.

The word "driver" is ambiguous. A driver can mean something as simple as "thin layer of API functions to make register accesses more readable to the human writing the code." It can be as complex as dealing with an HTTP server.

I mean, for the former, who wouldn't prefer something like

Code: [Select]

newbyte = UART_Read(UARTNUMBER); instead of a list of register accesses?

[Sal Ammoniac]

I suppose vendor libraries are very popular with the crowd who learned to code by cutting and pasting from Stack Overflow.

[IDEngineer]

That is an AWESOME photo. Sad that only a thin sliver of the population would understand the humor.

[thm_w]

I suppose vendor libraries are very popular with the crowd who learned to code by cutting and pasting from Stack Overflow.

Its a simple difference of: time available and skill.

You are clearly an experienced embedded developer, who has the time and ability to write their own quality low level drivers. Majority of the people on this forum are not at your level, and do not have "pre-existing libraries" that they've written already that can be re-used. The way you speak is if everyone else is you, which is fine, if you acknowledge as such.

Keep in mind, the OP is a beginner, and possibly even a hobbyist. It could take them weeks to write a working UART driver, which may be a useful learning experience, or may just be weeks of time that could have been spent on some other aspect of the design.

That is an AWESOME photo. Sad that only a thin sliver of the population would understand the humor.

Its not sad at all.

[dietert1]

From my own business i have a different perspective on what you have to do to earn money: Produce IP. Now selling IP is very difficult or near impossible, because it gets lost easily, just by explaining it. There are many clever people in this world.
So the chip vendors are trying to make something that is specific to their collection of chips. In the case of ARM MCUs that means specific to peripherals. Somebody, who learned to use the software framework, will then likely stay with their chips so they can make money. But the value isn't the silicon, it is the vendor library.

The processor boards i am selling in the thousands are like CDs. The value is the firmware, which is "execute-only", with the hardware a mere license protector. For that product i also wrote a system from scratch, but that was in 2004. Now we are in 2020. And those ARM MCUs we have today are a lot more complex than the MSP430 i used in 2004. Sixteen years of Moore's law make a factor 16384 +/-

Regards, Dieter

[NorthGuy]

Without using Atmel Software Framework that wouldn't have been possible.

How's that? You dealt with these devices before, so you would just go to one of your old project and copied the code from there, except the code wouldn't contain the library calls and therefore would be easier to modify to fit your current project. So, I don't think the Foundation saved any time for you.

I can tell you that i got furious yesterday when i lost about four or five hours trying to import the generated project into IAR. For the time being i gave up, because i got hard faults.

You wouldn't have to if you didn't add any extraneous things to your project. You would only have a set of C files which you can compile practically anywhere.

[dietert1]

No, i learned about ASF after unpacking the kit and i have never been using Atmel Studio 7.0 before except for a look and feel test.
Yes, we have a lot of stuff for Kinetis and STM32, but not for ATSAM.
In fact i first found that i could create a new I2C Quickstart project in ATMEL Studio 7.0. Only today i learned how to turn on advanced settings in ATMEL Studio 7.0 and how to use ASF Explorer and ASF Wizard. Today i also found that huge ASF book.
Just found a bug in SPI driver (slave with callback). It fools around with the transmit interrupt after submitting a receive job. But now it works.

Concerning IAR: It's not that simple. I did not give up when sys/types.h wasn't found in IAR. But when it finally compiled it threw a hard fault ("0C4" in IBM terms). Will analyse that after the application works as expected. Also i need to go from ATSAMC21J18 of the kit to a 32 pin ATSAMC21E18 and make that work with the debugger of the kit...

Regards, Dieter

[Sal Ammoniac]

You are clearly an experienced embedded developer, who has the time and ability to write their own quality low level drivers. Majority of the people on this forum are not at your level, and do not have "pre-existing libraries" that they've written already that can be re-used. The way you speak is if everyone else is you, which is fine, if you acknowledge as such.

Almost everything I write in this forum is from the perspective of a professional embedded engineer. I realize that hobbyists are in a different position, and if they want to use vendor libraries, I have no problem with that. I do recommend, however, that they learn the underlying hardware at the register level, just to gain an understanding of how the hardware works, if nothing else.

[Bassman59]

You are clearly an experienced embedded developer, who has the time and ability to write their own quality low level drivers. Majority of the people on this forum are not at your level, and do not have "pre-existing libraries" that they've written already that can be re-used. The way you speak is if everyone else is you, which is fine, if you acknowledge as such.

Almost everything I write in this forum is from the perspective of a professional embedded engineer. I realize that hobbyists are in a different position, and if they want to use vendor libraries, I have no problem with that. I do recommend, however, that they learn the underlying hardware at the register level, just to gain an understanding of how the hardware works, if nothing else.

I write from that same perspective.

I have no problem using vendor-provided code, or some third-party library (who doesn't use lwip for Ethernet, right?), as long as I understand it. I mean, if I can look at a library and understand it without too much effort, that's good. And when I look at it I can ask myself, "Is it worth my time to write my own library, when it would look substantially like this?" I know to not bother reinventing this particular wheel.

I's the spaghetti that passes for "code" as provided by some vendors which rightfully leads to the assertion of "vendor code is crap."

[NorthGuy]

Majority of the people on this forum are not at your level, and do not have "pre-existing libraries" that they've written already that can be re-used.

And they never will if they always use third-party libraries.

IMHO, it doesn't take long until you start bumping into situations where you have already written something similar to what you're going to write at the moment. Then you start re-using your own code. Eventually you get to the point where everything you do is somewhat similar to something you have already done in the past.

[SilverSolder]

Majority of the people on this forum are not at your level, and do not have "pre-existing libraries" that they've written already that can be re-used.

And they never will if they always use third-party libraries.

IMHO, it doesn't take long until you start bumping into situations where you have already written something similar to what you're going to write at the moment. Then you start re-using your own code. Eventually you get to the point where everything you do is somewhat similar to something you have already done in the past.

...And then you get bored, find another job, and start the process all over again!

[dietert1]

The idea to prevail in IT by experience is far from reality.

Again, if i use the Atmel ASF as an example once more: It first became Atmel Start (ASF4) which became MPLabX which became Harmony, all this within maybe 4 or 5 years, i don't know. It also happened to ST frameworks. So there is a continuous need for rapid update.

Now some elders claim they get things done reusing their own code "since 35 years". No sorry, the original poster should not get confused, he is doing the right thing.

Regards, Dieter

[westfw]

You folks saying nice things about ATMEL ASF...  are you talking about ASF3, or about the new ASF4 (aka. “Start”)?


I hear most of what you learned in asf3 is useless for Start, but the new chips aren’t going to get asf3.
(On the good side, Start seems to make better use of inline and other modern concepts, and the code comes out smaller.  At least as object files; the amount and tiers of source code has gone up. :-(

[Siwastaja]

But the elephant in the room is that a typical UART peripheral usage implementation, even in a modern ARM MCU, is below 10 lines of code!

Maybe three lines of turning the peripheral clock on, and connecting the UART to the IO pins. Which is something a library does not magically do for you; you need to still know how to do it, with another library call which is very likely more than 3 LoC.

Then approx. two lines to configure the UART: enable, set baud rate register.

And finally, 2 * 2 LoC to use it: check if byte is available, and read it.  Check for tx empty flag, write byte.

Yes, a total beginner cannot do it in 5 minutes, but 2 weeks is a ridiculous claim, unless they are struggling with very basics of C language which prevents them to use any library, as well.

I have been through this as a beginner, as well. I tried to access a standard character parallel LCD using a library, tried it for 5 hours, no success, wrote my own code in 30 minutes. As a beginner hobbyist.

I tried accessing one wire thermometers using a library, tried it for 5 hours, no success, wrote my own code  in 2-3 hours. As a beginner hobbyist.

Most of those who do instead of talking all theoretical have the exact same experience. Note, this applies to trivial things, like UART, GPIO, SPI, ADC...

Beginners often struggle to configure things. They can write crappy C code by trial and error and often like to do it. It being crappy doesn't matter to them or anyone else, it's the way to learn.

If "using a library" means you get an easy-to-install Windows IDE which includes said library by default and hitting "compile" produces a working project, this means development is easy. But it is not because of the library. It could equally well be an UART example project of that 10 lines-of-code! As a result, the beginner could actually learn what is happening, and still have that easy learning curve.

But no, that would not result in the nice vendor-lock-in aspect that the manufacturers are so keen on.

The "library is needed because library is needed because library is needed because otherwise NIH" argument is just ridiculous. How many layers of abstraction do you need? Why stop at n when you can have n+1? You do need a library to calculate Clarke transform, which is two multiplications by constants and an addition. Do you need an RMS library to calculate RMS? Some think you do. Finally, where is the limit - do you need a separete library to calculate a + b, while the C language has built-in "+" operator?

I propose that instead of such extremist principled position, we would use more pragmatic metrics to decide library usage, such as:
* The complexity of doing it yourself
* The complexity of using an available library, including the time that it invested in finding and installing that library
* The required level of customization. A math processing library, for example, could work with pure functions and compile to any CPU architecture just fine. An MCU peripheral library needs to interact with the interrupt system, other user code in said interrupts, other peripherals, and so on, and hence the libraries only tend to cover simplistic cases.
* Licensing...

[SilverSolder]

But the elephant in the room is that a typical UART peripheral usage implementation, even in a modern ARM MCU, is below 10 lines of code!

Maybe three lines of turning the peripheral clock on, and connecting the UART to the IO pins. Which is something a library does not magically do for you; you need to still know how to do it, with another library call which is very likely more than 3 LoC.

Then approx. two lines to configure the UART: enable, set baud rate register.

And finally, 2 * 2 LoC to use it: check if byte is available, and read it.  Check for tx empty flag, write byte.

Yes, a total beginner cannot do it in 5 minutes, but 2 weeks is a ridiculous claim, unless they are struggling with very basics of C language which prevents them to use any library, as well.

I have been through this as a beginner, as well. I tried to access a standard character parallel LCD using a library, tried it for 5 hours, no success, wrote my own code in 30 minutes. As a beginner hobbyist.

I tried accessing one wire thermometers using a library, tried it for 5 hours, no success, wrote my own code  in 2-3 hours. As a beginner hobbyist.

Most of those who do instead of talking all theoretical have the exact same experience. Note, this applies to trivial things, like UART, GPIO, SPI, ADC...

Beginners often struggle to configure things. They can write crappy C code by trial and error and often like to do it. It being crappy doesn't matter to them or anyone else, it's the way to learn.

If "using a library" means you get an easy-to-install Windows IDE which includes said library by default and hitting "compile" produces a working project, this means development is easy. But it is not because of the library. It could equally well be an UART example project of that 10 lines-of-code! As a result, the beginner could actually learn what is happening, and still have that easy learning curve.

But no, that would not result in the nice vendor-lock-in aspect that the manufacturers are so keen on.

There is some truth to this idea:   that in order for a library to "pay off", it has to do something that is not so easy to do from scratch. 

So, for example, a library of tested and debugged code that does FFT is probably more worth learning (more likely to save time overall) than one that turns on PWM on a pin.

[Siwastaja]

FFT library is also more portable. FFT does not interract with io peripherals, it just accesses memory.

[nctnico]

I propose that instead of such extremist principled position, we would use more pragmatic metrics to decide library usage, such as:
* The complexity of doing it yourself
* The complexity of using an available library, including the time that it invested in finding and installing that library
* The required level of customization. A math processing library, for example, could work with pure functions and compile to any CPU architecture just fine. An MCU peripheral library needs to interact with the interrupt system, other user code in said interrupts, other peripherals, and so on, and hence the libraries only tend to cover simplistic cases.
* Licensing...

I agree with this.