Firmware already runs on the bare board. An LED comes on, a button counts, USB opens. That board is still in air. The moment the case goes on, the same code becomes a different object.
This piece does not publish a pin map. It writes, from the floor, where firmware and case drift on a small-batch device, and the order we close that drift.
The first fit is not the pin
Before we open the case drawing we look at three things with the board.
- Where the hand presses — where the button center is from outside the case
- Where the light comes out — whether the LED has to pass case thickness, and whether a light guide is needed
- Where it plugs in — whether USB, power, and sensor holes sit at the same height as the board connectors
If those three positions are missing from the sketch, the firmware pin numbers can be right and the finished piece still misses. Code looks at pins. A user looks at holes.
Dry fit, before power
The first meeting is not a light. It is putting the board in the case. If a screw boss hits a USB shell, or a button cap hits a switch stem, we fix the plastic before we fix the code.
- Board only. Seat it with no wires and no battery
- Close the lid and see whether the board shifts when USB goes in
- Set the button cap and check the switch is not already down
If the cap is pre-pressed, firmware takes input from boot. That is mechanism, not a bug. Start a debug week from there and you spend the week in code.
Button stroke
Click feel outside the case is not the switch spec. It is cap thickness, boss height, and the compression of a rubber kit added together. Firmware debounce is set after that mechanism is fixed.
Debounce too short becomes a double press on a bouncy cap. Debounce too long swallows a press in a short-stroke case. That is why the same code feels different in a printed housing and a machined one.
We do not test buttons in air on the bench. Close the case. Twenty presses in the direction a finger actually uses. That record is the basis for debounce.
When light has to pass a wall
An LED on the board is bright. Inside a case it dies. Paint, thickness, internal bounce, and whether there is a light guide outweigh the firmware brightness value.
In small batches people often crank PWM to max and then shave the case. We reverse the order. Fix the window in the case, then put the min and max brightness that window can read into the firmware. With no window, a firmware animation does not exist for the user.
USB, heat, and reset
Layout inside the case changes the firmware reset path. A boot button with no hole means a field update is opening the case. On a small-batch device, opening the case makes scratches and lost screws.
- Decide first: an update hole, or open-and-plug
- Keep the reset pin off a case rib that would press it
- Keep a wall that a finger rests on off a part that heats while charging
A watchdog in firmware does not help if the reset switch is held by the case. The device starts from the beginning, again and again.
One sheet of fit notes
The firmware repo and the case drawing live in different folders. We leave only the meeting point on one sheet.
- Case coordinates for buttons, LEDs, connectors
- Measured stroke and debounce with the case closed
- How many brightness steps read as distinct through the window
- How we update — hole, open, or neither
With that sheet we do not start by doubting the code on the next housing. Firmware meeting the case means two drawings become the sequence of one object.