We now have:
* A hardware lead – A&D regular Eric Baskin – with thirty years of experience as a power and signals engineer. He is so superbly qualified for this gig that my grin when I think about it makes my face hurt.
* A high-level system design (about which more below) that promises to be extremely capable, scalable, flexible, and debuggable.
* A really sharp dev group. Half a dozen experts have shown up to help spec this thing. critique te design docs, and explain EE things to ignorant me.
* Industry participation! We have a friendly observer who’s the lead software architect for one of the major UPS vendors.
* A makerspace near me where the owner recruited himself onto the project and is looking forward to donating bench time and skilled hands to the hardware build.
All this helpfulness almost – but not quite – fills in my deficits as a designer/implementer. I don’t really know from hardware design, so I’m attacking the problem with the modularity and information-hiding principles I know from software.
Here is how the design looks:
An I2C bus that ties together a “forebrain” which is a Unix SBC, almost certainly at this point an Olimrx LIME2, with a “midbrain” that is an Arduino-class microcontroller.
The midbrain is mechanism – a simple state machine whose job is to control the high-power subsystem (inverters, battery, AC input and output). Policy decisions and stuff like battery state modeling will live in the forebrain. It will also run the USB and Ethernet interfaces, and host the development environment for the firmware
The forebrain will talk to a 20×4 LCD panel over I2C, and various other controls like alarm mute and self-test buttons via GPIO pins.
I’ve actually written the spec for the I2C bus messages already. And here’s your cute hack for the day…
I realized early on that one of the first things I needed to do was draw a state/action diagram for the system so I could pin down its behavior in response to any given transition in its environment (mains power up, mains power down, battery dwell limit approaching, those sorts of things). So I reached for one of my favorite tools, a graph-drawing DSL called dot.
Only when I write the first version of the graph, I found the dot markup cluttered and repetitive. So I wrote a couple of cpp macros named “state” and “action” that expand to dot markup, and expressed the graph as a sequence of macro calls.
Then I blinked, looked again, and realized…hey, I could compile these calls to C source code for a state machine! And now it is done – I can already generate the tricky part of the application logic for the midbrain directly from the state/action diagram. (The action functions are stubs but the control flow is all there.)
(If the fact that I just solved a design problem by writing a DSL to generate code in another DSL and provably correct equivalent C application logic seems weird to you, you must be be new here. This is how I think all the time. It is obedience to the Unix wisdom: never hand-hack code you can generate from a higher-level description.)
This, however, does not solve the entire firmware problem by any means. The midbrain’s going to need system logic to do things like receive and send I2C messages, poll A2D converters from sensors watching the mains and battery voltage, and so forth.
Accordingly, we need a firmware developer. I’ll learn how to do this if nobody steps up (which is why I said “wants” in the post title) but the whole process will doubtless go faster and more smoothly if we have someone with experience. So:
WANTED: One firmware hacker. Must be familiar with AVR-class microcontrollers and the Linux toolchains for them. Experience with I2C and low-level programming of USB endpoints would be a plus. Perks of the job include getting one of the first UPSides made, your name in lights, and working with a dev crew that is impressive even by my elevated standards.
EDIT: Well, that didn’t take long. A&D regular Jay Maynard has signed on.