Geekmagic & ProtoMach
I’ve been sketching a modular board that reacts to player moves via sensors. Think a mechanical version of chess with programmable pieces. What do you think?
That sounds epic—like a real‑life Rube Goldberg chess set! If each piece has a tiny microcontroller, you could program them to change tactics on the fly. Just watch out for timing glitches; you’ll need a solid power plan and maybe a fail‑safe to keep the board from spiraling into chaos. Still, it’s a killer idea for a hybrid of tech and board‑game strategy. What’s your first prototype piece going to be?
First prototype piece will be the pawn. Simple shape, straight lines, easy to mount a microcontroller and two push‑buttons for forward and capture. I’ll use a low‑power MCU, a small battery pack, and a fuse for the fail‑safe. No fancy paint, just a brushed steel frame and the old coffee mug for soldering flux. If it glitches, I’ll strip the board, fix the timing, and re‑assemble. That’s the plan.
Sounds like a solid starting point. A pawn’s simple movement keeps the code lean, and the steel frame will hold up to the repeated moves. Keep the battery low‑draw so the MCU can stay on between turns, and a tiny reset button can kill the glitch loop without pulling the whole board apart. Once the pawn talks back on a move, the whole board’s ready for the next level. Good luck, and let me know if you need a firmware tweak!
Thanks. I’ll wire the MCU with a 1.8V low‑drop regulator, run it at 8 MHz. Keep the I/O pins to a minimum, only a status LED and two inputs per pawn. If you spot a bug in the state machine, just send the hex. I’ll patch it, re‑flash, and test again. No fuss.
Sounds good—just drop the state machine code in a file, and I’ll run it through a quick audit. While you’re at it, test the promotion edge case too, just in case the pawn hits the other side and the LEDs get confused. Happy coding!
State machine for the pawn MCU (C‑style, no fancy libraries).
Just copy the code into your IDE, flash it, and test.
```c
// Simple pawn state machine
#include <stdbool.h>
typedef enum { IDLE, MOVE, CAPTURE, PROMOTE } State;
volatile State pawn_state = IDLE;
// Button flags set by external interrupts
volatile bool forward_pressed = false;
volatile bool capture_pressed = false;
// LED identifiers (wired to GPIO pins)
#define LED_MOVE 0
#define LED_CAPTURE 1
#define LED_PROMOTE 2
// Stub for LED control
void LED_on(int id) { /* set GPIO high */ }
void LED_off(int id){ /* set GPIO low */ }
// Stub for detecting pawn reaching last rank
bool pawn_at_last_rank(void) {
// Replace with real sensor check
return false;
}
// ISR for forward button
void ISR_forward(void) { forward_pressed = true; }
// ISR for capture button
void ISR_capture(void) { capture_pressed = true; }
// Main loop
int main(void) {
// Setup hardware, interrupts, GPIOs here
while (1) {
if (forward_pressed) {
forward_pressed = false;
if (pawn_state == PROMOTE) {
pawn_state = IDLE; // reset after promotion
LED_on(LED_PROMOTE);
} else {
pawn_state = MOVE;
LED_on(LED_MOVE);
}
}
if (capture_pressed) {
capture_pressed = false;
if (pawn_state == PROMOTE) {
pawn_state = IDLE; // reset after promotion
LED_on(LED_PROMOTE);
} else {
pawn_state = CAPTURE;
LED_on(LED_CAPTURE);
}
}
// Check promotion condition
if (pawn_at_last_rank()) {
pawn_state = PROMOTE;
LED_on(LED_PROMOTE);
}
// Small delay or low‑power wait here
}
}
```
Reset button: tie a pull‑up GPIO to an interrupt, clear all flags and set `pawn_state = IDLE` when pressed.
This keeps the LEDs from staying lit after a glitch and lets you test the promotion edge case without pulling the whole board apart.
Let me know if the logic needs tweaking.