code and electronics

updated 28 april 2019

pretty much everything i've ever done in the last 45 years has had electronics and code in it, though somehow little of it can be found on my website. starting around 2010? i started being more methodical about documenting it. code (and the electronics that code runs on) is a never-ending conversation, never complete.

i got more methodical about documenting my work "recently", most of it the roadster code and some sound projects, the libraries to support those, and the electronics that it runs on.


roadster code and electronics

most of my code and electronics effort in the last couple years has gone into my rambler roadster project, both the electronics (purpose-made but very generalized) and multi-processor code, and libraries to support it. the electronics is is geared towards controlling many high-power nasty motor loads (1 to 25A) and many analog and logical inputs; cars are wiring-heavy. the code uses a very simple but robust single-threaded multi-tasking strategy ("fastCode", or aDefiniteMethod) that is designed around a brutally simple and reliable messaging scheme designed for rapid error/reset recovery, and single- or multi-processor agnostic. it adheres to fairly straightforward anarchist principles of the Paul Goodman kind.

the roadster code largely adheres to the MISRA-C:2004 coding standard (but not the environmental or testing regime stuff).




external documents

MISRA-C:2004 has many great guidelines for writing C. the anti-C++ bias was relaxed in later years (// comments etc) but most of the good-practices suggestions are ways to avoid the pitfalls of some of C's behavior (eg. automatic type conversion).

half of the MISRA stuff is about testing and development environments and production accountability; those don't apply (much) to individual practitioners like me, but they sure do apply to folks at places like Toyota, where truly horrific coding practices caused actual deadly death. bad practice writ large: 10,000 global variables in multi-task code with life safety entangled. idiots.


how to write truly terrible and dangerous realtime code

just follow Toyota's example, as described below in a well-documented court case regarding the "unintended accelleration" (sic) debacle below. it's a fascinating and readable story, and is what got me interesting in the MISRA-C:2004 standard.

half of the MISRA stuff is about testing and development environments and production accountability; those don't apply (much) to me or individual coders, but they sure do apply to folks at places like Toyota, where truly horrific coding practices murdered some of their customers with actual deadly death. bad practice writ large: 10,000 global variables in multi-task code with life safety entangled. idiots. there's no excuse for that at all. ever.

because the U.S. court system is open and public the full transcripts of the highly technical evidence is now public record. and it is fascinating. i read it on a long air flight. the judge is no dummy, but he's not a nerd; talented consultants rendered the truly horrific coding practices of toyota's programmers visible.

reading this sent me down a long path that has culminated in me reading and modifying all of my Roadster code work to meet most of the appropriate MISRA-C:2004 coding standards. they're actually very good recommendations; in fact i found a number of errors in my own code simply reading it. (most were due to implied casts and size of variable issues).

here are copies of the Toyota disaster documentation: