updated 01 may 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.
I don't use github. It's a fine thing, but I'm uninterested in adapting to it's requirements. I know how to work in a shared project environment, but since I code for myself only I'm sticking with my own idiosyncratic methodologies. It's creative writing to me, I don't track all my revisions. I fork at large changes (new hardware, etc). I had some of it up on github but I kept getting out of sync and honestly, not once did anyone use it, so what's the point? Github took all the fun of coding for me!
I'll post snapshot copies of complete source and libraries inside the project folders above, I'm fine with it all being Creative Commons 4.0, I'm not being secretive, just lazy and enjoying coding. On the off chance you want to see something up to date, just ask.
Here is a ZIP copy of my Arduino folder, complete with one-offs, test hacks, and legitimate projects. I'll try to post significant snippets in project-specific pages but for the latest source you'll have to ask.
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: