I’m blocked before I can modify the project because execution credits are unavailable right now, so I cannot add components or generate the live schematic in Flux yet.
Current project state:
- Empty project
- 0 components
- 0 nets
- No schematic changes have been made
What remains to be done when execution is available:
- Rename/document the project for the calculator replacement PCB.
- Add the ESP32 NodeMCU DevKit V1 CP2102 module.
- Add the SSD1306 I2C OLED connector/module.
- Add 50 tactile switches arranged as a GPIO-efficient keyboard matrix.
- Use an 8-row x 7-column matrix, supporting up to 56 keys with only 15 GPIOs.
- Avoid ESP32 boot strapping pins GPIO0, GPIO2, GPIO12, and GPIO15 for keyboard scan lines.
- Connect OLED I2C:
- SDA → GPIO21
- SCL → GPIO22
- 4.7 kΩ pull-up from SDA to 3.3 V
- 4.7 kΩ pull-up from SCL to 3.3 V
- Connect OLED VCC to ESP32 3.3 V.
- Tie ESP32 GND, OLED GND, and keyboard matrix reference ground/common return together.
- Add schematic documentation for firmware pin mapping and key positions.
- Run schematic review/ERC before moving to layout.
Recommended GPIO mapping for the next pass:
- Matrix rows: GPIO13, GPIO14, GPIO16, GPIO17, GPIO18, GPIO19, GPIO23, GPIO25
- Matrix columns: GPIO26, GPIO27, GPIO32, GPIO33, GPIO34, GPIO35, GPIO36
- I2C OLED:
Important note: GPIO34, GPIO35, and GPIO36 are input-only pins on ESP32, so they are suitable for matrix column inputs, not row outputs. The firmware should scan rows as outputs and columns as inputs with pull-ups/pull-downs handled carefully; external pull resistors may be needed on input-only pins depending on the DevKit/module behavior.
For debouncing: I recommend firmware debouncing first, not one capacitor per key. A 50-key matrix with per-key capacitors can slow scanning and cause ghosting-like behavior. If reliable multi-key detection is needed, add one diode per switch; otherwise, firmware debounce is simpler and better for a calculator-style keypad.