[robotjosh]

The vendor SDKs are the weak link, not the compiler or language. Development could go 4x smoother if the vendor code were solid. Every single project I bump into sdk bugs that make it clear they have shipped code that was not tested. Its like they expect us to debug their code that they had developed on the cheap. Lately my philosophy is to just take the vendor header file and write my own low level drivers because it takes a more predictable amount of time. Our industry could use 3rd party SDKs.

[petra]

There's a big conflict in mcu development:On the one hand, you have developers who want reliable and comfortable libraries so they can develop well and fast. Higher-level is a word to describe that(it's only partially accurate).

On the other hand, mcu companies make a significant amount of their profit based on lock-in(since mcu's are mostly commodities). And the higher level the API's and the rapid development is, the less lock-in companies get.

That together with the fact it costs a lot to develop quality libraries are the main reason to the state we're in today.

As for solutions:

1. ARM did face that problem once, with cores, and played it hand well , they came to mcu vendors and told them - the carrot: using our core will save you money on development(core/compilers/etc). The stick: a startup called luminary-micro , who could do cheap mcu's since all that was free.

- So can this move be played again, today, with peripherals ? maybe build a nice peripheral set, with libraries, well tested, etc - and offer it cheaply to the risc-v guys , and other mcu vendors, including Chinese mcu vendors ?

- Maybe the place to look for quality libraries is at mcu startups ? the last one was the acquired energy-micro , are their libraries better ?

2. The IOT is a big shift. Shifts create different leverage points sometime. Is there something that open-source community can do together to push the vendors towards great libraries in that niche , even if vendors don't like it much?

For example, what if the open-source community focused on one of the hardest building block of the IOT - security ? what if we created a highly proven security IP, proven by the community to a great extent, but used it licensing to push mcu vendors ?

Are there any other ideas how to solve this conflict ?

[user5994461]

I don't think they need software lock-in. They already have hardware lock-in, which is easily 10 times stronger.

Rewiring and redesigning all electronics around a new MCU is just an insane undertaking. Irrelevant of API change in the software.

[petra]

In the EBM embedded survey 2013, regarding microcontorllers[1], they asked the question "why did you use the same processor", pg 56:

https://www.slideshare.net/MTKDMI/2013-embedded-market-study...

Many of the reasons we're regarding software, indicating that software lock-in is a significant factor.

[1]they called it microprocessors , but pages 54, 60 hint we're talking about mcu's.

[user5994461]

Assuming there was a bit of standardisation around the basic API. There is still significant lock-in by other factors.

It could be that the software is the thing they think first, if you ask the people writing it.

[petra]

Maybe. But you have to consider that such surveys(and similar tools) could make semi company managers believe that software lock-in is important, and that's all it takes.

[robotjosh]

freertos or projects like that could help. They need different drivers anyway so good rtos support would mean you can ignore the official sdk.

[user5994461]

Agree. Hardware SDK and tools are utterly terrible.

That's the major reason I stay away from embedded development.