Macropad Design Files


I controlli meccanici sono ora protetti. Sposto MCU verso l’angolo alto-sinistra e lascio USB/ESD/fusibile vicino al connettore per aprire un canale di routing centrale.
Ho eliminato quasi tutte le collisioni; restano due sovrapposizioni rame legate a un diodo/condensatore vicino al top-left. Le separo prima del pre-check routing.
Il placement ora è senza collisioni rilevate, ma il report di densità continua a segnalare congestione seria. Eseguo il pre-check dell’autorouter; se conferma il blocco, passo a 4 layer per tentare il routing senza cambiare la meccanica.
Il pre-check autorouter non ha trovato blocchi, solo avvisi su GND pour vuoti/da rigenerare. Avvio ora il routing completo mantenendo fissi i controlli meccanici.
Ho completato il placement elettronico: tasti, encoder e USB-C sono protetti/bloccati; MCU e passivi sono stati spostati per togliere collisioni, mantenendo fissa la meccanica. Il pre-check routing è passato senza blocchi gravi, ma il routing automatico non è partito perché l’account non ha ACUs disponibili.
Open item:
  • Routing non eseguito: serve disponibilità di ACUs per continuare.
  • Restano avvisi non bloccanti sui GND pour vuoti, da rigenerare/verificare dopo il routing.
Prossimi passi:
  1. Aggiungere ACUs.
  2. Riprendere il job di autorouting.
  3. Verificare airwires/DRC dopo il routing e fare cleanup mirato.
Rigenera GND e DRC
Mostra net congestionati
Strategia routing manuale

U1
U2
D11
SW10
D1
SW6
D2
D5
SW9
D4
SW4
D7
SW1
D6
SW3
SW11
D9
D12
D10
SW8
SW5
SW7
D3
D8
SW2
C6
Capacitance
1uF
R6
Resistance
5.1kΩ
F1
R5
Resistance
5.1kΩ
R2
Resistance
10kΩ
C7
Capacitance
4.7uF
C10
Capacitance
100nF
C8
Capacitance
22pF
C2
Capacitance
100nF
C1
Capacitance
100nF
C4
Capacitance
100nF
C3
Capacitance
100nF
ENC1
R3
Resistance
22 Ω
C5
Capacitance
100nF
C9
Capacitance
22pF
R4
Resistance
22 Ω
R1
Resistance
10kΩ
Y1
J1
SW_RESET
Project Specification
Project Overview
  • Status: Draft
  • Device: Standalone USB-C macropad based on ATmega32U4 in TQFP-44 package.
  • Goal: Production-intent schematic and PCB setup for a keyboard-style controller with 11 mechanical keys and one EC11 rotary encoder.
Intended Use
  • USB HID macropad for desktop use.
  • Designed for mass production rather than hand-wired prototyping.
  • Mechanical fit will be finalized from a case STEP model supplied later.
What the Device Should Do
  • Connect to a host over USB-C as a USB device.
  • Scan 12 key inputs: 11 Cherry-MX hotswap switches plus the EC11 integrated push button.
  • Read EC11 encoder A/B quadrature channels.
  • Support reset and boot/HWB configuration for ATmega32U4 firmware workflows.
Main Features
  • ATmega32U4 SMD TQFP-44 MCU.
  • 16 MHz external crystal with two 22 pF load capacitors.
  • RESET pull-up and reset pushbutton.
  • HWB 10 kΩ pull-down.
  • One 100 nF decoupling capacitor per VCC/AVCC pin plus 4.7 µF bulk capacitance.
  • USB-C 16-pin SMD connector, D+/D- 22 Ω series resistors, USB ESD protection, and 500 mA resettable PTC on VBUS.
  • 11 Cherry-MX hotswap switch footprints and EC11 encoder footprint.
  • 1N4148W SOD-123 diode for each key path including encoder pushbutton.
System Architecture

Diagram


USB-C Connector 500 mA PTC 5 V / VCC Rail USB D+/D- ESD 22 ohm USB series resistors ATmega32U4 16 MHz Crystal 11 MX Hotswap Switches + Diodes EC11 Push + Diode EC11 A/B Channels Reset Pull-up + Button HWB Pull-down
Hardware Subsystems
MCU and Clock
  • ATmega32U4 TQFP-44 with external 16 MHz crystal.
  • Load capacitors specified as 22 pF per user requirement.
Key Matrix / Inputs
  • 12 individual key inputs routed to Arduino-compatible ATmega32U4 pins: D2, D3, D4, D5, D6, D7, D8, D9, D10, D14/MISO, D15/SCK, D16/MOSI.
  • Each key path includes a 1N4148W SOD-123 diode.
Encoder
  • EC11 rotary encoder with integrated pushbutton.
  • Encoder A/B channels connect to Arduino D18/A4 and D19/A5.
  • Pushbutton is included in the 12-key diode-protected input set.
USB and Protection
  • USB-C device/sink connector with CC pull-downs required for USB-C VBUS attach.
  • D+/D- protected with USBLC6-2SC6-class ESD protection near connector.
  • 22 Ω series resistors between protected USB data lines and ATmega32U4 USB pins.
  • 500 mA PTC fuse in series with VBUS.
Interfaces and Connections

Table


InterfaceDetails
USBUSB-C 16-pin SMD, USB 2.0 device data, 5 V input
Keys11 Cherry-MX hotswap switch footprints
EncoderEC11 A/B plus integrated pushbutton
Firmware pinsATmega32U4 Arduino pin compatibility per pasted requirement
Power and Runtime Expectations
  • Powered from USB VBUS only.
  • No battery or charging subsystem specified.
  • Estimated system current is well below 500 mA for MCU plus passive keyboard inputs; LED lighting is not specified and not included.
Power Tree and Power Budget

Diagram


USB Host 5 V USB-C Connector 500 mA PTC Protected VCC / 5 V ATmega32U4 Pull-ups / passives
  • PTC requested: 500 mA resettable fuse.
  • Actual load expected: ATmega32U4 plus switches/encoder and leakage currents; no high-current loads specified.
Manufacturing and Assembly Expectations
  • SMD production-oriented design.
  • MCU package: TQFP-44.
  • Key diodes: 1N4148W SOD-123.
  • USB connector: 16-pin SMD Type-C.
  • Switches: Cherry-MX hotswap footprints.
Firmware-Relevant Hardware Requirements
  • Maintain Arduino pin mapping exactly as specified.
  • RESET and HWB circuits included for bootloader/DFU workflows.
  • USB data path supports ATmega32U4 native USB.
Physical Design Expectations
  • Board outline and switch/encoder positions will be defined after user provides the case STEP model.
  • Routing must not be performed until mechanical alignment is complete and locked.
Important Design Decisions
  • Use 5 V USB VBUS as VCC for ATmega32U4 unless later requirements require 3.3 V operation.
  • Add USB-C CC pull-down resistors even though not explicitly listed, because a USB-C sink needs them for normal host power attach.
  • Defer final board outline, mechanical placement, and routing until STEP model is available.
  • Initial PCB setup uses a temporary 160 mm × 100 mm 2-layer staging board with top/bottom GND pours. Final outline and exact component coordinates remain pending the case STEP.
  • The library did not provide an exact EC11 footprint match during selection; ENC1 uses a PEC11R EC11-style encoder substitute and must be mechanically verified/replaced if the case requires a specific EC11 variant.
  • Arduino D18/D19 were mapped using the standard ATmega32U4 Leonardo-style mapping: D18 = PF7 and D19 = PF6. The pasted text also labels them A4/A5, so firmware/mechanical documentation should verify the target board variant.
Assumptions
  • No LEDs, displays, or RGB lighting are included because they were not specified.
  • The macropad uses individual GPIO inputs rather than a row/column matrix because 12 exact Arduino pins were specified.
  • Encoder A/B pull-ups may be firmware/internal pull-ups unless ERC or firmware requirements drive external pull-ups later.
Change Notes
  • Initial specification created from the two pasted text attachments, which contained duplicate requirements.
  • Schematic implemented with ATMEGA32U4-AU, USB-C, USBLC6-2SC6, 0603L050YR PTC, 16 MHz crystal, 11 Kailh MX hotswap sockets, PEC11R encoder, reset switch, 12× 1N4148W diodes, CC pull-downs, USB series resistors, decoupling, UCAP, AREF, and GND pours.
  • ERC critical checks are clean; PCB has only unrouted airwires by design because routing is intentionally deferred until case STEP alignment.
  • Mechanical layout updated from the user's reference photo: 3 MX switches on the top row, EC11 encoder at upper-right, 4 MX switches on the middle row, and 4 MX switches on the bottom row. USB-C remains centered at the top edge. Routing remains deferred.
  • Project Overview

  • Intended Use

  • What the Device Should Do

  • Main Features

  • System Architecture

  • Hardware Subsystems

  • MCU and Clock

  • Key Matrix / Inputs

  • Encoder

  • USB and Protection

  • Interfaces and Connections

  • Power and Runtime Expectations

  • Power Tree and Power Budget

  • Manufacturing and Assembly Expectations

  • Firmware-Relevant Hardware Requirements

  • Physical Design Expectations

  • Important Design Decisions

  • Assumptions

  • Change Notes