Mochi Devlog 01: Early Development

What This First Devlog Covers

This is the first real devlog entry for Mochi. The introduction article explained why Mochi exists as a product exercise. This one is about the actual early decisions: what hardware questions came up first, what firmware choices were made before any of it was proven, and what already broke.

Nothing here is close to final. The point of writing it down now is to keep an honest record before memory smooths the rough edges over.

If you are building a first prototype too, I hope these imperfect decisions help you spot a few things worth checking early.

Early Hardware Questions

The first hardware question was not "what sensors does Mochi need" — it was "how will Mochi tell someone something is wrong?" Before adding any sensing, I wanted a status signal that works even when nothing else does: a single LED wired directly to a GPIO with no dependency on firmware initialization order.

The second question was power. Mochi will eventually run on battery, but the first board is powered over USB during development on purpose. Debugging power issues and firmware issues at the same time makes both harder to isolate. USB power removes one variable while the core logic gets sorted out.

The third question was the MCU choice, and it came down to available debugging support rather than raw specs. A chip with good UART logging and a simple flashing workflow saves more time early on than slightly better performance would.

First Firmware Decisions

The first firmware milestone was intentionally boring: blink the status LED, print a boot message over UART, and confirm the board resets cleanly. No sensors, no motors, no logic yet. If this baseline is not reliable, nothing built on top of it can be trusted either.

From there, the firmware was split into two rough layers early: a small hardware abstraction layer for pins and peripherals, and a separate layer for anything resembling behavior. This split is not sophisticated, but it already made one thing easier — when something behaves incorrectly, the first question becomes "is this a hardware read issue or a logic issue," and the code structure makes that question answerable.

The real prototype photo shows why cable routing and connector placement still needed another design pass.

What Went Wrong Already

The status LED wiring was correct on paper but wrong in practice: it shared a pin that conflicted with the programming interface, so the board could either be flashed or show status, not both at the same time. It is a small mistake, but it is exactly the kind of mistake that early hardware notes are meant to catch before it repeats on the next board revision.

Separately, the first UART logging attempt used a baud rate that did not match the debug adapter's default, which produced garbled output that looked like a hardware fault for longer than it should have. The actual issue was a one-line mismatch in configuration.

Neither problem is dramatic. Both are the kind of thing that is obvious in hindsight and easy to lose without a written note. A third, smaller issue: the first enclosure mockup assumed a connector position that turned out to sit exactly where a mounting screw needed to go. It cost an afternoon of redrawing rather than a redesign, but it is a reminder that mechanical and electrical decisions need to be checked against each other earlier than felt necessary.

Next Steps

The next hardware pass will move the status LED to a pin that does not conflict with programming, and add a second test point near the power input so voltage can be checked without touching a component leg. On the firmware side, the next step is a minimal command interface over UART, mostly so later devlogs can report actual behavior instead of only boot messages.

Mochi is still far from doing anything interesting. The goal for this stage is a board and firmware base that is boring enough to trust, so the more interesting decisions later have a stable foundation to sit on.

Related reading

• What Mochi is
• Mochi ESP32-S3 hardware
• Mochi 3D model resources