updated 22 jan 2023
new june 2019
Navigation pulldown in upper right corner.
Pretty much everything I've ever done in the last ~50 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.
The code here all derives from a new path I started around 2015 using
Arduino type hardware and what I thought was the obvious solution given the
strategy implicit in the IDE's "New Sketch" -- the event loop. But not one
example program provided followed through, and the dreadful
delay() is everywhere. Anyway I'll get to that next.
The major impetus for a serious, portable take on event-loop programming was my rambler roadster project, ancient mechanicals nicely tuned and driven with robust realtime code in three networked computers. Automobiles are a very harsh environment for computers and reliability requirements of hardware and software are utmost. This project is discussed here. The roadster implementation of the ideas in these pages drives difficult loads (motors and pumps, hot fluids) and simple sensors to run an automobile at speed, closed-loop engine cooling, maintaining a common database across three computers.
A recent project, Flock, little self-contained solar and battery powered, sound-playing, human- and environmentally-sensing, radio-networked little boxes, uses these ideas to respond 24 hours/day to light and motion, build a heirarchy-free low power mesh radio network and coordinate event activity across the mesh network.
More of my embedded controller projects, some using this scheme, are covered here.
NOTE: THIS PAGE IS A WORK IN PROGRESS. The items marked STUB are missing documentation here, only; the code is in use now.
Here is a short illustrated how to use
software timers instead of the dreaded delay() function that
ruins every novice's idea. For non-novices this shows a succinct way to
incorporate four of the most fundamental concepts in real-time programming:
state machines; timers; eent programming; non-blocking code. Usable examples
are provided and the library to support it.
I've developed some very compact and fast libraries for supporting real-time event loop programming on Arduino-like controllers. I
STUB: Using SRMessages generate, decompose, store, etc brief messages, that form the basis for inter-process-communication (IPC) in realtime processes and boxes. SRMessage provides seamless messaging inter-process within the same box, or across serial or radio networks. It is also human-readable and you can type it in on the IDE serial monitor to provide a manual command line interface.
STUB: SRSmooth and SRSMPID provide most of the basic calculus functions for smoothing, filter, process control, motor and other PID loops, etc. These are extremely compact and lightweight. PID, integration, differentiation; smoothing is done via exponential smoothing; there is single and double-exponential functions available. The PID defaults are such that it will extract usable event information directly from a CdS cell attached to an input pin with no other supporting hardware.
STUB: Flock is a heirarchy-free radio mesh networking system for NRF24L01+ radio chips. Two or more devices ("birds") will locate each other on any channel, negotiate a tick clock synchronized across the flock. A built-in optimization (Peep) uses the tick clock to restrict communications to about 10&percent; of the tick the tick interval, allowing the radio to be powered off the rest of the time (Peep is "broken" as I revamp it, jan 2023). Flock requires an event-loop programming model.
STUB: The roadster code supports a serial-networked three processor automotive system for reliable realtime management of a little sports car. There is no EFI code; the roadster is carbureted. The cooloing system is as far as I know, entirely unique: the I.C. engine is cooled by two small pumps with no traditional thermostat, temperature held to 1 degree F long term with 5 degree F excursions shorter than 20 seconds. Eac
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: