[AlotOfReading]

This comment baffles me. I don't find anything in the article to be remotely controversial. HALs, testability, and avoiding spaghetti are just straightforwardly good ideas that a significant number of embedded developers don't know about because they haven't read a programming article since they left college.

As an example, have you not seen virtually any embedded project that doesn't do something like this?

[contingencies]

FWIW, I actually work in the industry, coming from traditional software.

It is my experience that there is no need for architectural discussions on anything at the micro-scale because if you are implementing effectively for a commercial project you are likely to find that either (A) full abstraction is either overkill/infeasible (low end); or (B) you have a codebase to move with already, likely vendor backed (mid-range).

If you are above micro scale and dealing with a fully fledged RTOS or GPOS, then such abstraction will certainly be baked in.

My point was: this makes the article a bit strange, as such a general observation I wonder who the intended audience is. Perhaps my impression of the industry is unique, but I doubt it. Further, it seems the author is a consultant selling middle management sauce to big companies.

[AlotOfReading]

For context, I also work in the industry and have seen embedded codebases ranging from several thousand lines up to tens of millions.

The region where A is true for me is roughly about an 8051 whose entire codebase could be held in a single developer's mind at one time. That's an increasingly miniscule portion of the industry for many good reasons.

For B, my experience is that your codebase often long outlives the products and hardware it's shipping on and is doing very nontrivial things like wireless networking. The article is saying you should have a way to run the code without hardware (obviously useful for testing/CI/bring up) and with a HAL (which makes porting easier), among other common sense suggestions. Vendors don't always provide this, but my info might be out of date because I haven't been able to work in this space for some years due to my salary expectations.

If you have a full RTOS (e.g. FreeRTOS, RTEMS, etc) you definitely do not get the ability to do these things for free. You need to actually have an architecture and work to keep things like raw hardware accesses isolated. I've spent literal years of my life cleaning up codebases where this wasn't done, so I have strong opinions on the matter.

[contingencies]

We seem to be essentially in agreement, although I would say A is technically most products (both new, and ever produced) one might qualify that by saying they're likely not the sort of thing you would see volume on in a western embedded career. I think the other comment regarding scale being absent from the article hits the nail on the head.

[diydsp]

Working this industry my whole life, this brief article doesn't address scale. Embedded runs the gamut from sub kilobyte to multimegabyte, multi-dozen heterogenous architectures with het networks/interconnects. The level of arch described here is very nice to have but incompatible with program managers and customers in most - but not all - markets.

Most coding is done with HALs and platforms like STM32 make it easy with numerous portable APIs from libopencm3 and so on. So the chip shortage wasnt a disaster. 5-10 years ago was scarier but we have gleaned much info from general sw dev, from rev ctrl to sqa, security, unit tests, integration, regression, linting and my personal dislike: source formatting- no thanks for that one, guys! :)

Ofc im speaking mainly as a professional. There are still many prototypes on arduinos shipping....

Security tho is still a weakpoint, but blame short-term business needs for that 50%.

CI for embedded tho is still a huge opportunity. I see the wheel reinvented too often where a turnkey solution could win TTM and incr reliability.