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

[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

[Siwastaja]

Well, the "library" approach is for people who simply cannot write even a few lines of code, but still somehow manage to get something done by massive code copy-pasting and library call operations. I truly wonder how it's possible to build anything like that.

Case in point, for motor control, when you need to calculate exactly these, and only these, operations:

x = (1/sqrt(3)) * (y + 2*z);
d = Ia*cos(phi) + x*sin(phi);
q = x*cos(phi) - Ia*sin(phi);

- invariably, absolute in 100% of cases I have seen or read about, this set of operations performed maybe every 0.1ms, is called "computationally intensive" "math wizardry" "typically requiring DSP or FPGA" and will be hidden in a massive library behind multiple function calls.

Learning how to use the library easily takes days, though. In reality, it would be 1 table lookup, 6 multiplications, maybe 4 additions. But no, no can do. Need massive DSP and preferably a closed-source library just because they are even more wizard...ious?

Any appnote or tutorial discussing this makes extra sure not to reveal this math, only talk about its fanciness and complexity, because the library user could otherwise make difficult questions, such as "why?" or "oh but isn't that trivial?"

[nctnico]

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?

I have not used LPC controllers always. There was a world before ARM microcontrollers existed. I've run my library on various microcontrollers including the 8051.

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

You are way overcomplicating things. Why would a driver need to cover all cases at once? Just as long as you have a consistent API everything is OK.

[ehughes]

x = (1/sqrt(3)) * (y + 2*z);
d = Ia*cos(phi) + x*sin(phi);
q = x*cos(phi) - Ia*sin(phi);

Ha,   The first time I saw Field Orientied Control,  I wondered the same thing.    Why exactly do I need a large vendor library for this?


I used to do talks on DSP in embedded systems.  The 1st slide was that I can do DSP on anything.  An 8051 or an Abbacus.   

[SiliconWizard]

I do agree that quite often, software bloat and *excessive* use of third-party libraries is a sign of both laziness and lack of programming skills.

I'm all, as I often mention, for code reuse though, as much as reasonably possible. So every time that allows code reuse, using libraries is a benefit. Don't underestimate the time you may sometimes waste though, rather than save: as others have said, it may take you significant time to figure out how to use some library properly, and then some more if you ever run into bugs - and bugs are everywhere. And it's usually much easier to fix your own bugs than bugs in third-party code (assuming source code is provided - if not, don't expect most vendors to react quickly to bug reports). The reusability factor may also be hindered by nasty license issues, so beware of that as well.

General code reuse is a very vague idea. It makes sense within a company, sometimes even within some BUs in a company, but across every possible kind of projects/products/companies? Not necessarily so much. So, making your OWN code reusable (as much as possible, but not unreasonably either) is a good thing, but fully relying on third-party code for that doesn't always work, and is often a good excuse for not writing reusable/portable code yourself. Which I for one don't think is a good approach.

A "common" and universal API may sound like a great thing, but the road to hell is paved with good intentions. Ultimately it comes down to the typical idea of "the right tool for the job". If you want a relatively universal API and good low-level abstraction, use some OS. But that's not justified for small projects IMHO. nctnico mentioned network connectivity as an example of the benefits of a common API (or an OS as I said), but IMO it completely depends again on the project. If your product, apart from the network connectivity/internet access, wouldn't require any kind of OS or any high level of abstraction, unless you're going for very high volumes and very low cost, using third-party chips for the connectivity part is usually a better solution, with much faster TTM, fewer bugs and and a lot less frustration overall.


Anyway, to get back on topic, given the complexity of many modern MCUs, vendors have no choice but provide support libraries. I think they would lose a lot of potential customers if they didn't.
Now whether you or your team uses them for any particular project is entirely up to you, the known shortcomings and your company's policies.

[SilverSolder]

In practice, "code reuse" sometimes boils down to using some hardware (with embedded code) for some new purpose!

[SiliconWizard]

x = (1/sqrt(3)) * (y + 2*z);
d = Ia*cos(phi) + x*sin(phi);
q = x*cos(phi) - Ia*sin(phi);

Ha,   The first time I saw Field Orientied Control,  I wondered the same thing.    Why exactly do I need a large vendor library for this?

Yup.

But don't overestimate the math skills of a typical software developer. Absolutely not willing to start a flame war here, but just the result of my observations over the years. I have run into only a very few that would actually be able to fully understand the above.

[Siwastaja]

x = (1/sqrt(3)) * (y + 2*z);
d = Ia*cos(phi) + x*sin(phi);
q = x*cos(phi) - Ia*sin(phi);

Ha,   The first time I saw Field Orientied Control,  I wondered the same thing.    Why exactly do I need a large vendor library for this?

Yup.

But don't overestimate the math skills of a typical software developer. Absolutely not willing to start a flame war here, but just the result of my observations over the years. I have run into only a very few that would actually be able to fully understand the above.

Oh yes, for example I tend to be quite sucky with math, although I'm brave enough to at least partially blame the obfuscation built-in in both mathematics itself (300-year old notations do not always play well, and for someone who likes to talk in one's head, having ten different symbols pronounced the same and stylized in five different fonts to denote completely different things is nothing but obfuscation, when you could just use multi-character variable names like in programming), and especially in teaching material made by those who do not truly understand what they are teaching well enough to be able to teach it to a beginner. FOC is a great example of such obfuscation actually.

Still, as an embedded programmer, you absolutely must know how to implement a multiplication, summation, division, or sine function lookup. This should be basics. Dealing with numerical ranges in your code is something you can't avoid, except by buying the complete solution so that you do nothing.

So in any case, understand that math or not, the only sensible choice is to perform a few elementary school level math operations in your own code, even if you don't fully understand why they are there; compared to linking to a massive library and learning to use it to perform the same operations, which you still won't understand.

Can I get my name in history books for renaming bog-standard 2D vector rotation formula in my name whenever I come up with any application needing bog-standard 2D vector rotation? Some do have that privilege

I'm actually thinking it would be a nice joke to come up with a "Siwastaja transform" which would finally perform (x+y) through some large matrix operations. Then write it as a C++ library using every possible modern C++ feature available (and as many exceptions as possible); and a large bunch of dependencies to other libraries, obviously a matrix processing library at least. Make it a week-long process to install the specific versions of unstable library development packages and get it compile. Then add a ROS (Robot Operating System, the one that needs its own rcd, rls and so on command because cd, ls and so on are NIH) wrapper layer, again with similar complexity, so that users can easily perform said transform operations through the message bus. That would be great. I'm sure I could get people to actually use and promote it. If I could do it, that is. My C++ skills are greatly lacking.

[SiliconWizard]

Still, as an embedded programmer, you absolutely must know how to implement a multiplication, summation, division, or sine function lookup. This should be basics. Dealing with numerical ranges in your code is something you can't avoid, except by buying the complete solution so that you do nothing.

So in any case, understand that math or not, the only sensible choice is to perform a few elementary school level math operations in your own code, even if you don't fully understand why they are there; compared to linking to a massive library and learning to use it to perform the same operations, which you still won't understand.

I agree with that to some extent, but using some math you don't understand is not always the wisest thing to do. If you can't understand it, you may have a hard time judging whether this is the right thing to do in a particular context, to begin with. Or you may have found some resource that contains errors.

I'm actually thinking it would be a nice joke to come up with a "Siwastaja transform" which would finally perform (x+y) through some large matrix operations. Then write it as a C++ library using every possible modern C++ feature available (and as many exceptions as possible); and a large bunch of dependencies to other libraries, obviously a matrix processing library at least. Make it a week-long process to install the specific versions of unstable library development packages and get it compile. Then add a ROS (Robot Operating System, the one that needs its own rcd, rls and so on command because cd, ls and so on are NIH) wrapper layer, again with similar complexity, so that users can easily perform said transform operations through the message bus. That would be great. I'm sure I could get people to actually use and promote it.

Good one!

[IDEngineer]

I'm actually thinking it would be a nice joke to come up with a "Siwastaja transform" which would finally perform (x+y) through some large matrix operations. Then write it as a C++ library using every possible modern C++ feature available (and as many exceptions as possible); and a large bunch of dependencies to other libraries, obviously a matrix processing library at least. Make it a week-long process to install the specific versions of unstable library development packages and get it compile. Then add a ROS (Robot Operating System, the one that needs its own rcd, rls and so on command because cd, ls and so on are NIH) wrapper layer, again with similar complexity, so that users can easily perform said transform operations through the message bus. That would be great. I'm sure I could get people to actually use and promote it.

That sounds sadly familiar. Pretty sure I've already used that library! 

[NorthGuy]

You are way overcomplicating things. Why would a driver need to cover all cases at once? Just as long as you have a consistent API everything is OK.

If you only have one use case for I2C, you don't. If you have 20 different use cases, your driver must cover them all. Otherwise, you would be doing the same as I do - write a separate code for each use case.

If you a hardware vendor though, you may have millions of users, each of them with their own use cases, you you simply have to cover them all. Otherwise, your users won't be able to use your library and will complain - your library cannot do this, your library cannot do that. In practice, they create libraries which are both complicated and at the same time do not cover the case which you need at the moment - the library doesn't work with interrupts, the library requires RTOS etc.

[SilverSolder]

You are way overcomplicating things. Why would a driver need to cover all cases at once? Just as long as you have a consistent API everything is OK.

If you only have one use case for I2C, you don't. If you have 20 different use cases, your driver must cover them all. Otherwise, you would be doing the same as I do - write a separate code for each use case.

If you a hardware vendor though, you may have millions of users, each of them with their own use cases, you you simply have to cover them all. Otherwise, your users won't be able to use your library and will complain - your library cannot do this, your library cannot do that. In practice, they create libraries which are both complicated and at the same time do not cover the case which you need at the moment - the library doesn't work with interrupts, the library requires RTOS etc.

There are good reasons not to use a library in some cases.  E.g. I see Oracle developers rewrite queries with small variations all the time (rather than put them in a library in a more generic form) for performance reasons (i.e. using "tricks" that they know Oracle "likes") on large (read: slow!) databases.   In the embedded world, there are likely situations where you are looking for the last ounce of performance too.

[Siwastaja]

In my experience, I2C implementations in microcontrollers vary quite a bit, the level of their usefulness and brokenness, especially.

Some require so much register configuration and polling during a simple transfer that you are wasting almost as much CPU time as bit-banging the whole bus.

Some are so buggy and full of corner cases that you fight for days getting them work.

Couple that with some I2C devices having a buggy interface.

A generic driver for the most common microcontrollers, with stable API, sidestepping all these issues sounds great on paper, but I guess it's going to be almost impossible to do properly, and I doubt we'll ever see it.

I2C, though, is most often used to just set some configuration registers up or read some super-slow sensor at whatever rate, doesn't matter. A simple write-once "library" you can reuse yourself, that simply bitbangs the whole I2C without even trying to use the MCU peripherals, configurable for the specific GPIO access patterns with a few #defines, would likely hit the nail 95% of the time.

[bson]

The real problem is the libraries don't relieve you of the need to thoroughly read user guides and datasheets.  For example, if you want to set up a DMA channel to repeat a pattern on a port, you need to make sure this can be done, how it's done in the hardware, and for example if there are channel limitations, data size limitations, if it needs to be in a specific SRAM bank, whether it can be in NOR flash, etc etc.  Then timing, which clock base to use, how to configure the clock tree and timer channel, to trigger the DMA.  And, now, having read the hardware docs and having a clear notion of how to use it, you're stuck figuring out how to make a library that attempts to hide all these details behind an abstract interface do it.  You almost invariable end up having to reverse engineer it from the source code.  In short, you do about 5x as much work for no benefit, with tons of hairy debugging because the library abstractions are all intertwined in complicated ways.  That would be fine if it actually got you something in terms of portability and performance, but portability is STILL completely tied to the actual hardware and isn't just going to work on anything with the right functionality - it has to be EXACTLY the same.  And performance often suffers as the abstractions add tons of vectoring and sometimes totally bizarre stuff that looks like a first-year student's programming project.

[thm_w]

Well, the "library" approach is for people who simply cannot write even a few lines of code, but still somehow manage to get something done by massive code copy-pasting and library call operations. I truly wonder how it's possible to build anything like that.

Case in point, for motor control, when you need to calculate exactly these, and only these, operations:

x = (1/sqrt(3)) * (y + 2*z);
d = Ia*cos(phi) + x*sin(phi);
q = x*cos(phi) - Ia*sin(phi);

You are using an equation which forms a portion of the functionality of the library.
The library is massive because it supports other features that your three lines of code do not cover.

Closed source libs sure agreed, don't use those. I'm not aware of any STM32 libs that are closed, but, I'm sure they might exist.

The real problem is the libraries don't relieve you of the need to thoroughly read user guides and datasheets. 

Well, they do if you're just working on a basic project.
Call some "AnalogRead" function every 1s, and the chance that you would run into any issues is very low. All this without reading 65 pages on the ADC in the ref manual.

[Nominal Animal]

Most library interfaces are pretty much shit.

It is not because their writers are bad programmers, it is because when you design a library, you almost never know how it ends up being used.  It's like creating a tool, and then hoping it will be useful for something.

As an example, consider that analogRead() function.  Almost all ADC hardware nowadays works independently of the microcontroller processor itself, so actually there are three separate stages: setup (source/mux, gain, sampling options), trigger, and sometime later, a state change in some hardware register indicating the conversion is completed. analogRead() combines all three, with a busy-wait loop waiting for the conversion to complete; during which time the microcontroller processor could do other useful work, like scale/sum/square (for statistical details) the previous converted sample.

This is excarberated by vendor libraries having partial design goals opposite to user-developer needs.  One of them is the need to retain development effort within the vendor product: you don't want to make it easier for your clients to switch to your competitors products.  Another is that the vendor has little experience in the variance of how different use cases their products may be applied to.  (Sure, they'll sometimes work closely with their largest clients, but for every large client you have a hundred small clients, in todays world.  If you only work for companies who have that sort of ties to vendors, your experience is probably different.)
A yet another is that the vendor libraries are usually seen as a cost, and thus created and maintained with strict development resource limits, making them quite poor quality overall.  As the vendor portfolio grows, the complexity in the library increases, making them worse as time goes on, not better.

So, if you want code that works best for your own use cases, you'll have to develop or help develop the libraries yourself, in my experience.

None of this is unique or specific to embedded environments.  High-performance computing suffers from the exact same kind of issues.  If you think about it, even simple read()/write() interfaces could use splitting into submit/completed stages, allowing the thread to do useful work in between.  But for humans, this kind of async thinking seems to be too hard.

[SilverSolder]

[...]
  If you think about it, even simple read()/write() interfaces could use splitting into submit/completed stages, allowing the thread to do useful work in between.  But for humans, this kind of async thinking seems to be too hard.

In fairness, many Read/Write paradigm interfaces do come with Open(), Flush(), etc. commands...   which means the programmer has to think a little more, in return for an efficiency gain.

[Nominal Animal]

[...]
  If you think about it, even simple read()/write() interfaces could use splitting into submit/completed stages, allowing the thread to do useful work in between.  But for humans, this kind of async thinking seems to be too hard.

In fairness, many Read/Write paradigm interfaces do come with Open(), Flush(), etc. commands...   which means the programmer has to think a little more, in return for an efficiency gain.

No, I meant that when DMA is used or hardware uses latches/queues etc. to transfer blocks of data, it is silly to not have a native asynchronous interface where the call only triggers the transfer, and another call can be used to check or wait for completion.  Having library calls do busy-wait loops or loop until a hardware flag changes is a significant waste of energy.

This is particularly useful with networked/distributed computation (e.g. MPI_Isend() and MPI_Irecv()), but rarely used in HPC because async=hard, and it is easier to put more money in hardware and use blocking calls instead.

[SilverSolder]

[...]
  If you think about it, even simple read()/write() interfaces could use splitting into submit/completed stages, allowing the thread to do useful work in between.  But for humans, this kind of async thinking seems to be too hard.

In fairness, many Read/Write paradigm interfaces do come with Open(), Flush(), etc. commands...   which means the programmer has to think a little more, in return for an efficiency gain.

No, I meant that when DMA is used or hardware uses latches/queues etc. to transfer blocks of data, it is silly to not have a native asynchronous interface where the call only triggers the transfer, and another call can be used to check or wait for completion.  Having library calls do busy-wait loops or loop until a hardware flag changes is a significant waste of energy.

This is particularly useful with networked/distributed computation (e.g. MPI_Isend() and MPI_Irecv()), but rarely used in HPC because async=hard, and it is easier to put more money in hardware and use blocking calls instead.

Ah, I see what you mean.   -  yes, non-blocking calls are a total pain in the *rse for simple program flows.  The extra work needed to use a non blocking call is only worth it if you have to have the efficiency...  so we end up with these "lazy programmer" implementations that include the waiting, for the convenience and simplicity.

[station240]

I've had 'fun' with one library for TI's DSP micros.
One communications library has a whole set of filters for incoming traffic bitmasks and stuff.
While it's good at filtering out errors and data you elected not the receive, when things go wrong, there is no way to read any of the errors as they have already been wiped from the buffer by the library.
It's as if someone wrote the library as an example of how to do everything you need, then hid it inside a private class so you cannot access anything.

One day I should take that library, and separate the protocol code and the filters/error handler code into separate functions.

[Kasper]

Years ago I took a course on making portable device drivers in C.  I enjoyed the idea of separating the MCU specific details from the rest of the code and dreamt of the day I had a large repo of clean and solid code modules of my own to be dispersed as needed.

Fast forward to last week, I make a little IOT prototype for a software / networking guy who has his own business and seems to know what he's doing.  He requests I just make half of the hardware and write minimal FW just for testing.  He buys the other half of the HW (4-20mA to I2C converter) from a website for $40 usd.  I get 2 boards running, show him the button and LEDs work and leave it with him.  Later he invites me over to help troubleshoot, my LED 'doesnt work' and he has other errors.

I expected he would add my LED code to the arduino library supplied by the vendor.  He didn't, he just used their library and complained my LED was acting weird.  Back to the topic: the libraries supplied by the vendor was just a link to some random github example for the 4 channel ADC on their board.  The board was built using 2 channels single ended. But the supplied library printed all 4 channels and had different versions for single or differential.  My client was scratching his head, trying to figure out what code to use, what channel to look at and expecting something more refined than a raw ADC value.  I don't think he even glanced at the libraries.  The maker site didn't even bother to cut out the 2 channels they aren't using or the differential code.  They didn't supply schematic either so I ended up reverse engineering the board to figure out how the ADC was connected and what mods to do to make it work for our application.  It was not compatible with the 4-20 sensor he wanted to use.

The best part, their hardware sucked too: resistor networks very close to PCB edge despite having lots of spare room. One resistor was not thermally balanced and ended up skewed and not soldered. 

In this case, the vendor supplied library and the vendor supplied hardware both sucked and I enjoyed telling my client he should just have me do everything next time.

[Bassman59]

I've had 'fun' with one library for TI's DSP micros.
One communications library has a whole set of filters for incoming traffic bitmasks and stuff.
While it's good at filtering out errors and data you elected not the receive, when things go wrong, there is no way to read any of the errors as they have already been wiped from the buffer by the library.
It's as if someone wrote the library as an example of how to do everything you need, then hid it inside a private class so you cannot access anything.

One day I should take that library, and separate the protocol code and the filters/error handler code into separate functions.

I'm having "fun" with TI's USB device library for one of their ARM families. It is a mess of abstractions and pointers pointing to pointers to structures, and structures of pointers pointing to ... well, who the fuck knows. Their code "works" for the device classes their support. But writing support for a class they don't is mind bending, because following what was done on a "similar" class is painful. Their "goal" as such was to provide a "driver" your "Application code" can hook into, but I'm trying to write the "driver" and I don't need the extra shit they piled into their code.

I got the thing to enumerate, with an LED that lights up in response to the set-configuration request and goes out with a disconnect. And I made a change -- dunno what, exactly -- to add some more of the design functionality and now the interrupt for device disconnect no longer gets asserted. It's arsed, as they say across the pond.

Otherwise, their TivaWare library is straightforward enough and usable. And it's also burned into ROM in the chip, saving flash space.

Hilariously, the NXP USB library for LPC55xx devices is worse. It's opaque. And their support people say, "Start with an existing class design and modify it to suit."

I will say that Silicon Labs USB stack is a lot easier to get working. It's just that they don't have any plans to do High Speed USB, so ... blecccch.

[Sal Ammoniac]

It is a mess of abstractions and pointers pointing to pointers to structures, and structures of pointers pointing to ... well, who the fuck knows.

That's the major issue I have with vendor libraries. Ever try to debug that crap? You spend all of your time following pointer after pointer until you finally get to code that actually does something. Keeping track of all that abstraction is distracting and annoying. 

[Bassman59]

It is a mess of abstractions and pointers pointing to pointers to structures, and structures of pointers pointing to ... well, who the fuck knows.

That's the major issue I have with vendor libraries. Ever try to debug that crap? You spend all of your time following pointer after pointer until you finally get to code that actually does something. Keeping track of all that abstraction is distracting and annoying. 

This is worse, because it's an unholy mess of globals, static globals and then those things are passed as arguments in functions. Object disoriented programming.

One of the TI support people who deals with this parts says, "I wouldn't have written it that way," which is one way of admitting that the library is a disaster without saying such.

[dietert1]

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.

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. It's a lot of searching, trying to understand to some level what others did before.

Regards, Dieter

[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.

[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.

[NorthGuy]

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.

You're making my point. If you worked on the hardware level, there wouldn't be so much of a change.

People want libraries because they don't know what's inside of them. They believe there's something inside which is guaranteed to be done properly, perhaps giving some kind of moral support, or perhaps even some kind of magic.

But then you get bugs, you start to dive into the library code, and you see that there are many things that you don't need, which perhaps, may be removed. After you remove them and look at what's left, you see that you can remove more. Finally, when you dig to the end, what's left is so small - no magic, nothing like that, just a small amount of code which actually do things, and even that small piece can be improved. Then you wonder, why did I ever need to dig through all that while I could just write few lines of my own code instead. This happened to me so many times in the past.

Of course, there are bigger libraries which provide useful services, such as lwIP, which you probably should use. However, I don't think that if you spent couple days writing your own TCP implementation, it would be inferior to the TCP implementation in lwIP. But you would get something in return - such as you could choose your own storage model - fixed circular buffers, linked list of fragments, or whatnot. You would also get full control over the window advertisement, get better speed perhaps. You would be way ahead of that guy who tries to make his TCP work faster by tweaking parameters of the library he doesn't know anything about. And you would be able to do special things which the library simply can't - such as acking a lost packet if it is already obsolete to your app, instead of stalling the connection. But if you just want the library for your latest IoT project, you would never know how TCP really works and you would continue to believe that whatever library you have chosen provides the most efficient access to the Internet.

[dietert1]

Concerning the UART example: More recent MCUs include hardware to protect hardware settings after the init phase, during normal software execution. So when using things properly you cannot just write a baud rate register without unlocking that hardware protection first. Also you have a choice of about ten clock sources, each one with its specific frequency and power saving behaviors. Also you want to configure wake-up by the UART receiver. So that UART gets a bit more tricky.

The ATSAMC21 Canbus quickstart example included a UART connection via the debugger CDC channel. I just had to find out the actual baud rate and setup a Hyperterminal window. Then a menu appeared on the terminal. That worked on the Explained Pro kit i got for development, hope i can wire it up on the first prototype with the other MCU i will be using. One of the difficulties i had was finding out actual pinouts for the SPI connection. Those MCUs have two levels of pin multiplexing for the Sercom pads/pins.

Concerning optimization: That's a beginner's mistake to get trapped into optimization before getting results. If there are performance issues, it is usually very easy to solve by rewriting a small piece of the application later on.

The use case i was proposing as an example was Atmel Studio 7.0 with ASF3. It is outdated but that's what i already had on the laptop. Maybe i will install Harmony and see what that is. I definitely want open source.

Regards, Dieter

[thm_w]

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.

Keep in mind DMA UART functionality would take more than 10 lines of setup, but its still a single line library call + callback.
STM32 lib with cube will do all the clock configuration for you btw.

People want libraries because they don't know what's inside of them. They believe there's something inside which is guaranteed to be done properly, perhaps giving some kind of moral support, or perhaps even some kind of magic.

But then you get bugs, you start to dive into the library code, and you see that there are many things that you don't need, which perhaps, may be removed. After you remove them and look at what's left, you see that you can remove more. Finally, when you dig to the end, what's left is so small - no magic, nothing like that, just a small amount of code which actually do things, and even that small piece can be improved. Then you wonder, why did I ever need to dig through all that while I could just write few lines of my own code instead. This happened to me so many times in the past.

Or you know, they want the library because they know whats in there but realize they cant write all of those features in a matter of hours that it would take to understand the API?
There is zero reason to start stripping out code from a library unless you are starved for space or you want to modify the functionality of the library.
If you are working on a space constrained project, trying to keep costs low, then of course that is another valid reason to not use vendor libs.
But for $3 you can get a micro with 256kB of flash. Its not worth saving 50c on a one-off project if your goal is getting something working asap.

[NorthGuy]

There is zero reason to start stripping out code from a library ...

If you interested in my reasons, I wanted to understand how things work. I was young and inexperienced and had a great deal of admiration for the software around me. Now I don't