Well yes, but "embedded" is a pretty broad category.
Some major cases are:
- High-volume and cost-driven: where a you're picking the cheapest MCU you can make work (often by a matter of cents).You want to squeeze every last bit of performance (or IO, or power consumption, or pinout, or whatever the drivers are).
- Real-time: where abstracting the hardware beyond a certain point is counter-productive.
In my experience it's much less common that you don't care about the hardware than the reverse.
Unfortunately yes. Lots of embedded software development is done by folks without a software background. EE's and electronics technicians dabbling in firmware.
To be honest I am not sure who those dabbling in software actually are. A lot of the embedded software running in safety critical environments on certified compilers and is build and tested to a much, much higher standard than most people would think. This is so much closer to software engineering than what can be observed by "software developers" who pull in unchecked dependencies like there is no tomorrow.
Sure there are also electrical engineers who don't actually know how to program and they indeed dabble in it in a very naive fashion, but you got those people in software developement as well and they are also naive — just in a different way.
I think a big part of the reason is that embedded software payscales seem to be closer to EE pay than typical SWE pay. I've never understood why but from what I can tell the more specialized EE knowledge is not valued very well. I had a colleague who moved out of embedded software to become a backend developer for this reason.
There's thankfully some room in the market for pay reasonably comparable to typical SWE payscales, but most embedded developers live in their own little worlds largely disconnected from trends in the rest of the software industry. They're often simply not aware of what they're worth to demand it and the kind of companies that need embedded developers tend to be both unable and unwilling to pay those rates.
That’s pretty much my situation, I originally did electronic engineering and firmware but have switched professionally to backend software. Partly because of the pay, but mostly because the tooling and quality of most embedded software is so painful to work with. I’d rather have an overgrown dependency tree than a debugger which crashes more often than not.
A bit of a generalisation, but I tend to find when a traditional EE writes firmware, they treat the firmware as controlling the hardware and are more direct with their instructions. i.e. if they need to set a gpio they will often do it directly rather than abstract it. So an EE will write gpio23 = 1, whilst a more software background person will create some type of function say, turn_amplifier_on which will then take the appropriate action.
For those tiny projects it doesn't matter too much. However it seems with demands for features/time to market we rely more on vendor supplied SDK's so this direct approach is becoming less common.
I do find the EE's to be great at bitbanging though, especially when timing is critical.
Historically? Definitely. It wasnt that long ago that bare assembly was still dominant in embedded, long after general computing. Somewhat obviously, assembly programs were closely coupled to the hardware.
Nowadays C is probably still dominant is C++ is starting to get widespread acceptance.
