Embedded Artistry is a consultancy blog on embedded systems, firmware, software practices, and hardware product development.
Commenters call it the single best resource on embedded development and cite its post on what happens before main() in C programs.
There are some better lists for laws of Software Development:
[1] http://www.globalnerdy.com/2007/07/18/laws-of-software-development/
[2] https://exceptionnotfound.net/fundamental-laws-of-software-development/ (not so good but with solid discussions from HN https://news.ycombinator.com/item?id=11574715 )
And more:
[3] https://embeddedartistry.com/blog/2018/8/13/timeless-laws-software-development (a whole book titled Timeless Laws of Software Development)
[4] https://www.red-gate.com/simple-talk/opinion/opinion-pieces/some-laws-of-software-development/
[5] https://www.netobjectives.com/blogs/some-laws-software-development
[6] http://www.methodsandtools.com/archive/softwarelaws.php
Nope. But you should check out Embedded Artistry[1], its the single best resource I've seen on a field that's mysterious even to most professional programmers.
Have you spent any time doing Arduino projects? While not representative of real-world firmware work, Arduino is very accessible/cheap and will teach your transferable skills (e.g. C programming for interfacing with HW). I'd encourage you to really put some time in before you commit to anything embedded - because the amount of jobs and the range of companies you can work at is much, much lower than "mainstream" development (say, building web applications).
[1] https://embeddedartistry.com/beginners/
The Therac-25 used a PDP-11 computer. So I assumed the software was written in C. It wasn't?
I would also assume that most embedded software (e.g. in cars, spaceships, weapons, etc.) is written in C. But I see now it's indeed hard to come up with definitive sources.
A few failures can be found here (and it's easy to google some more):
https://embeddedartistry.com/fieldatlas/historical-software-accidents-and-errors/
But sadly no reference to the used languages anywhere there.
So I forward the question as I'm now also unsure: Has anybody definitive sources that prove the absence of C code in the known fatal accidents?
It's easy to overlook for those who program mostly on higher level systems. There was a recent HN thread that I think pointed to this article on what happens before main() in C programs:
https://embeddedartistry.com/blog/2019/04/08/a-general-overview-of-what-happens-before-main/
On microcontrollers, there are often some preliminaries that are programmed into nonvolatile settings of the hardware, such as the type of clock oscillator. On a microprocessor like the Z80, your circuit was supposed to ensure that things like the clock oscillator and power supplies were stable before releasing the RESET pin.
i actually wrote that down as side project idea yesterday! glad to see someone doing it.
i have a different set of documents in mind though. my list is more developer oriented. here's the kind i wanted:
- project readme (from simple to very involved)
- pull requests
- open source licenses (i think GitHub does this right?)
- code of conduct
- code testing template
- benchmarks
i also bookmarked these links:
https://embeddedartistry.com/templates
https://www.sans.org/security-resources/policies (this one is an old one i had not sure how i even stumble upon it...)
Today, probably not.
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.
The best way to decouple the HW and SW is still a topic of active discussion from what I can tell. For example, https://embeddedartistry.com/blog/2022/07/11/how-our-approach-to-abstract-interfaces-has-changed-over-the-years/