13 ms·
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. Hi
by petra 10y ago
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 ?
- robotjosh 10y agofreertos or projects like that could help. They need different drivers anyway so good rtos support would mean you can ignore the official sdk.
- user5994461 10y agoI 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 10y agoIn 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-final 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 10y agoAssuming 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 10y agoMaybe. 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.