state machine

3 Jul 2021

A few things are clear today:

• I should dev on the RPi 4, so I can remote SSH in with VS Code
• The next software hurdle to cross is the modal architecture. To that end I’ve worked up an interface and implementation that uses a guitar pickup switch as a SP5T instead of its normal operation (three digital outs, five positions: 100, 110, 010, 011, 001)
• This modal idea is about to get a little hairier. I’m coalescing ideas about different sets of components, that get read at different times. The program essentially has to go through a state machine. Perhaps I should build the state machine as a first-class entity. The first step is probably to graph it out.
• During development of this machine, I should keep a close eye on how reliable the experience is. Are there intermittent errors with pin lines unable to open or close? etc. If it becomes unreliable, I need to start keeping a reliable version printed and ready to install in the chassis. I don’t mean to use this policy to encourage breaking things, but rather to mitigate against what I know has been my pattern with software as a whole…

Oh gosh, I just realized a SP4T won’t work to do both power and data, unless I do some fancy diodes and voltage step-downs. No, let’s keep it simple and use two admin keyswitches. For the admin touchpoints, I wonder if I can fit them all (2 keyswitches and a USB…and an HDMI?) in the expansion slot. Or if I should just make them regular slide switches behind a screwed-on panel. Hmmmm, no, that’s too much touching, and what if the panel loses threads and falls off? For that HDMI question, I wonder if RPi can connect to phone hotspot and I can ssh in through that? New ticket!

So, next step is to mock this up using the guitar pickup switch as the “mode”, and assume power switch is on. Then, set up at least two different mode games, that each use the same toggle and LEDs, but with different behavior (e.g. test mode flashes an led while the toggle is held, but the landing mode latches the led).