updated 19 mar 2021
new june 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.
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).
19 mar 2021 I've abandoned my github repositories. I'm an infrequent user/updater, the Git Desktop falls out of sync with the repo. I use the Arduino environment, shared across two computers, and that seems to confuse the git stuff. I'm simply unwilling to exert the effort to debug every time I use it, and literally no one has ever downloaded the code. If you're actually interested contact me. In the mean time I'm driving on it, it's reliable as space craft even if no one else ever sees it.
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).
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 after reading it. (most were due to implicit casts and size-of-variable side effects).
here are copies of the Toyota disaster documentation: