I currently work at an embedded boards company as (technical) marketing, and using a lot of the boards outside of work too. I'm asking the same things myself too for a long time, and so far I figured about these comments to try to answer (at least in part).
Getting software right is bloody hard work! Especially with ARM where you need to redo a lot of things for every new piece of hardware.
Most companies (and most PMs/engineers) I think perceive boards as the end-products themselves, and any software development after the initial release (and maybe some bug fixes) is more of a burden than value add. This attitude needs to change, because it results in very-very few boards actually being used to their full potential. What good is a great hardware if nobody can make it work? Maybe this will change, but need good thought leaders inside companies to make that happen.
I see that upstreaming is often not considered, or couldn't be done. The quality of code is just awful, because that's not a design goal. Being part of an ecosystem, helping your future self doing a better job (not needing to start from scratch every time if things are upstreamed) is not part of the thinking for many. These things are (or thought to be) outside of the PMs responsibilities.
Resource constraints come in a lot, many companies try to support way too many products, and end up with a level of "barely" making it work, which is good enough for many traditional customers. Doing a good job needs a lot more resources. I remember reading that RPi spent about $5million worth of development on just the Linux support. Can't imagine lot of other companies putting that much into any single product.
And there's a lot of the traditional "trade secret" thinking. Lot of places are more afraid of losing sales doe to being copied than not selling boards because of lack of interest. The main goal is never really "enabling the customer/user" or giving options, but the first thing is protecting the IP because of the thinking stuck with the ways things use to work.
Also, the "software ecosystem" is highly fragmented, all projects rely a lot on volunteers, and require a lot of specialized knowledge. I don't know if it's even possible to bring people together, but whoever would achieve that would do a big service to both sides...
These are just some thoughts, I'm sure not the whole picture (and definitely, definitely do not reflect the opinion of my employer:)
> Especially with ARM where you need to redo a lot of things for every new piece of hardware.
So true. There's a reason some people are simply writing 'available' drivers from scratch.
> any software development after the initial release (and maybe some bug fixes) is more of a burden than value add.
Quite right. For example: ST's STM32F4 is a nice chip. The drivers in both the 'standard peripheral' and the 'HAL'[1] versions are a mess. The 'HAL' version looks like a junior developer who would rather move into management had the 'std. peripheral' version dropped onto his desk and proceeded to split it into parts without knowing or caring about what abstraction means.
Compared to that, Atmel's code is a dream. (Irrespective of whether you approve off the number of (thin) layers used to implement their HALs, you have to admire the amount of thought that went into the design. Unfortunately Atmel was slow in getting onto the ARM wagon.)
>Resource constraints come in a lot, many companies try to support way too many products, and end up with a level of "barely" making it work, which is good enough for many traditional customers.
Getting back to redoing a lot of things:
TI has some strong low power wireless connectivity products. Looking at pages like
Evaluating a few RTOSs, some proprietary and requiring NDAs, in detail, for specific hardware etc. - not a job for a junior engineer and not done over a weekend.
[1] Calling the ST 'HAL' drivers a HAL is a stretch, and let's not even get into what a monumental - the whole thing is.
I don't know how much pull you have within your company and with the SoC/etc suppliers that you use, but please please please preach the mainline mainline mainline, upstream upstream upstream mantra.
Getting software right is bloody hard work! Especially with ARM where you need to redo a lot of things for every new piece of hardware.
Most companies (and most PMs/engineers) I think perceive boards as the end-products themselves, and any software development after the initial release (and maybe some bug fixes) is more of a burden than value add. This attitude needs to change, because it results in very-very few boards actually being used to their full potential. What good is a great hardware if nobody can make it work? Maybe this will change, but need good thought leaders inside companies to make that happen.
I see that upstreaming is often not considered, or couldn't be done. The quality of code is just awful, because that's not a design goal. Being part of an ecosystem, helping your future self doing a better job (not needing to start from scratch every time if things are upstreamed) is not part of the thinking for many. These things are (or thought to be) outside of the PMs responsibilities.
Resource constraints come in a lot, many companies try to support way too many products, and end up with a level of "barely" making it work, which is good enough for many traditional customers. Doing a good job needs a lot more resources. I remember reading that RPi spent about $5million worth of development on just the Linux support. Can't imagine lot of other companies putting that much into any single product.
And there's a lot of the traditional "trade secret" thinking. Lot of places are more afraid of losing sales doe to being copied than not selling boards because of lack of interest. The main goal is never really "enabling the customer/user" or giving options, but the first thing is protecting the IP because of the thinking stuck with the ways things use to work.
Also, the "software ecosystem" is highly fragmented, all projects rely a lot on volunteers, and require a lot of specialized knowledge. I don't know if it's even possible to bring people together, but whoever would achieve that would do a big service to both sides...
These are just some thoughts, I'm sure not the whole picture (and definitely, definitely do not reflect the opinion of my employer:)