Better Embedded Software

Yes, 11 lines of debugged, delivered source lines of code written per day is within the normal range. The basic COCOMO model used by David A. Wheeler's "SLOCCount" estimates person-months as 2.4 * (KSLOC**1.05), which was calibrated with painfully-won experience on a variety of software projects in the 80s. If you approximate that as 2.4 months per kSLOC, it works out to 13.7 lines of code per calendar day, or 18.5 lines of code per workday. Other studies found lower speeds. Like 10: https://softwareengineering.stackexchange.com/questions/450695/where-did-the-quote-or-study-of-developers-write-10-lines-of-code-per-day-come-f

Every programmer thinks this is stupid the first time they see it, because we can all remember times we wrote 50 or 100 or 200 or 300 lines of code in a day, and that code worked. But other days we write zero lines of code, because we spend them in meetings, or debugging code, or arguing about the protocol design, or testing hardware we need to support, or testing our code. And sometimes we'll spend a week refactoring the codebase to reduce the number of lines of code (https://www.folklore.org/Negative_2000_Lines_Of_Code.html) so those 200 or 300 lines of code may not end up in the delivered product—if they were ever intended to, since test stubs and test scripts also don't count as delivered code.

And that's how we get to Peter Naur's "Programming as Theory Building": https://ratfactor.com/papers/naur1 because writing the code clearly isn't the…

Personally I'm a fan of AVR-8 which has 32 8-bit registers so if you want to do 16-bit or 24-bit or 32-bit or 40-bit math you can do it just fine, it just takes longer. The biggest AVR-8 device has about 8k of RAM and about 240k of rewritable program ROM. Those are on different buses so it can suck down an instruction at the same time it transfers data, and clocked at 16 MHz it beats the pants off any of the 8-bit micros of 1980.

You're not going to create really large systems for it, but if you want to work a gas pump or a hot water heater or make a tester for 74xx chips or a display controller for persistence of vision displays it is great.

You can code for it in C but I feel like I'm strangling puppies when I do it because it is moving the stack pointer around and doing things to support C calling conventions that I don't really need for the programs I write [1] AVR-8 assembly is fun but I still write C for it because if I need a bigger device I can recompile it for ESP32 or ARM.

Something weird about AVR-8 is that it does not have a unified address space, so in the case of that display controller, it is easy to spool graphic data out of the ROM, not so easy to upload a small amount into RAM (via serial port) and combine that with data from the ROM. I've had the crazy idea of making a AVR-8 on AVR-8 emulator (would get me to A-rank if not S-rank on AVR-8 assembly) which would make it possible to upload tiny programs into RAM but that probably requires…

> I like my filesystems like I like my Toyota, reliable.

Not sure if you're deliberately joking or not, but the quality of software in Toyota cars is hilariously awful.

There was a stunning writeup by one of the people who got source code to investigate the unintended acceleration issue a few years back. [1]

IIRC, as part of the cruise control, if they decided the car was going too slow it'd be given a command to accelerate. There was a second process which checked the speed, and once the car was going fast enough, it'd kill the accelerate process. Except the check/kill process would regularly crash, so the car would be told to accelerate and then nothing would be there to tell it to stop. Don't worry though, there's a software watchdog process to catch this! Except the watchdog ran under the same process manager as the check/stop script, so when the stop script crashed it'd take the watchdog process down too - and this was only the top of the iceburg when it came to problems.

tldr: software quality in Toyota's was abysmal and there's little reason to believe it's gotten fundamentally better.

[1] https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf

[1.5] Actual Talk: https://betterembsw.blogspot.co.uk/2014/09/a-case-study-of-toyota-unintended.html

Errors in the software of the radiation therapy machine Therac-25 directly lead to the death or serious injury of six patients. Three patients died within weeks or months.
http://radonc.wdfiles.com/local--files/radiation-accident-therac25/Therac_UGuelph_TGall.pdf

Errors in the software of a MIM-104 Patriot resulted in failure to locate and intercept an incoming missile and the death of 28 soldiers.
http://www.gao.gov/products/IMTEC-92-26

Errors in the software of a Chinook helicopter may have lead to a crash that killed 29 people.
http://www.publications.parliament.uk/pa/ld200102/ldselect/ldchin/25/2504.htm

Errors in the software of Toyota's throttle control system may have lead to the death of 89 people.
https://betterembsw.blogspot.ch/2014/09/a-case-study-of-toyota-unintended.html?m=1

More: http://www.baselinemag.com/c/a/Projects-Processes/Eight-Fatal-SoftwareRelated-Accidents

(heh pointers)

I was in ECE in college (graduated in 2017) but do full stack software engineering for a bank now. AFAIK it's still C, but I wouldn't be surprised if Rust picked up due to the emphasis on memory safety- dynamic memory allocation and recursion are usually avoided in embedded.

Some of the lessons I got from embedded have carried over to my place of work- I found a repo that used floating point for money and immediately knew why that was a bad idea, because my embedded systems professor had spent an almost an entire lesson explaining why you don't use floating point for money or time.

side note: Said professor (Phil Koopman) was an expert witness in the Toyota unexpected acceleration lawsuit, he has a talk on it that can be found at https://betterembsw.blogspot.com/2014/09/a-case-study-of-toyota-unintended.html.

* unsafe makes it very easy for you to audit where data races or memory errors are possible, instead of needing to audit an entire c codebase

I have seen this argument a couple of times before. But I can't make myself buy it.
Because I always have to think about embedded systems in the car industry. Look at this list:

https://betterembsw.blogspot.com/2018/09/potentially-deadly-automotive-software.html

The argument is basically "the possible fail places are easily grepable", right?
I said in another comment in this thread (jokingly) "time is money". It seems for the devs in the car industry this saying is of utter most importance.

So how does Rust prevent something like this throughout the code base (and those are BIG code bases):

"LOL. I need to get this done.
unsafe {
...
}
"