added homing.

gemini.md

@@ -91,8 +91,9 @@ Name:     WijiBoard
 | `S2-<n>` | Move motor 2 CCW by n steps |
 | `SPD:<n>` | Set max speed (steps/sec) for both motors |
 | `ACC:<n>` | Set acceleration (steps/sec²) for both motors |
-| `HOME1` | Zero motor 1 step counter |
-| `HOME2` | Zero motor 2 step counter |
+| `HOMEALL` | Home both motors simultaneously |
+| `HOME1` | Home motor 1 |
+| `HOME2` | Home motor 2 |
 | `POS` | Request current positions (triggers NOTIFY) |
 
 ### Status notifications (firmware → browser)
@@ -424,10 +425,9 @@ To add a new section:
   assume a specific physical motor orientation. If the real arm moves in the wrong direction
   when clicking a target, negate the step delta for that motor in `moveToXY()`.
 
-- **Home position**: `steps1 = 0, steps2 = 0` is wherever the firmware powers up (no homing
-  routine implemented yet). The arm must be manually set to a known starting configuration
-  before the IK will be accurate. Suggested home: arms roughly parallel, EE near centre of
-  the working area.
+- **Home position**: Stall homing is fully implemented matching the original C++ routine but adjusted to align with `PositionControl.cpp` motor mappings. Homing pushes the motors against their physical limits and sets `steps1 = 0` (0°, points right) and `steps2 = -1024` (-180°, points left). This corresponds to the arms folded OUTWARDS.
+  - The initial web simulation starts with these coordinates, meaning the UI assumes the arm has already been homed before the browser connects.
+  - Homing can be triggered individually per-motor (`HOME1`, `HOME2`) or combined (`HOMEALL`) from the web UI.
 
 - **LIMITS tuning**: All values in `LIMITS` in `kinematics.js` are estimates based on the
   original project's data. They need physical verification: