Arduino Nano board contract (Phase 9)

The Nano is the Arduino Uno's chip on a board that fits a breadboard. One kernel component (nano in crates/parts) wraps the same ATmega328P SoC model (crates/atmega328p) the Uno does, on the same AVR core (crates/avr-core). Nothing about the chip changes: the registers, the timers, the USART, the ADC, the interrupt vectors and the cycle counts are the ones docs/uno.md sets out, and that document is the contract for all of them. This one says only what is different, which is the package and the holes.

The catalog type is nano (Arduino Nano v3). Everything in docs/uno.md applies unless a section here says otherwise.

1. Board pins (catalog order)

Top view, the mini-USB socket at the top. Two fifteen-pin headers 0.6 inch apart, so the board pushes into a breadboard and straddles the center channel with three spare holes on each side.

Left column, top to bottom (board pins 1 to 15): 1, 0, RESET, GND, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12.

Right column, top to bottom (board pins 30 down to 16): VIN, GNDb, RESETb, 5V, A7, A6, A5, A4, A3, A2, A1, A0, AREF, 3V3, 13.

30 pins. The ICSP header is not a pin.

Electrical, where it differs from docs/uno.md section 1:

• Port mapping is the Uno's: 0..7 = PD0..PD7, 8..13 = PB0..PB5, A0..A5 = PC0..PC5. There is no IOREF and there are no separate SDA/SCL holes, so A4 and A5 are each one hole rather than two.
• A6 and A7 are ADC channels 6 and 7 and nothing else. The Nano is the TQFP-32 package, which bonds ADC6 and ADC7 out as analog inputs with no port pin behind them: no output driver, no pull-up, no PINx bit, and no digital read. The board reads the net voltage at each of those two holes and hands it to the ADC; the digital input mask never carries a bit for them. ADMUX values 6 and 7 select them. On an Uno (a 28-pin DIP) there is no pad at all, so the same ADMUX value reads 0.
• RESET and RESETb are one piece of metal. The board brings the reset trace out at both ends. Both holes carry the 10 k pull-up to 5 V, pulling either below 2.5 V holds the CPU in reset, and each hole shows what the other one's net is doing through R_STRAP, exactly as the Uno's A4/SDA pair does. GND and GNDb are likewise the same rail, and both simply drive 0 V.
• 5V drives 5 V at R_SUPPLY, 3V3 drives 3.3 V, VIN is an input the board ignores (always USB powered).
• Pin 13 has the on-board L LED through 1 k to ground, as on the Uno.

2. Memory map

Unchanged from docs/uno.md section 2: 32 KB of flash, 2 KB of SRAM at 0x0100..0x08FF, 1 KB of EEPROM, SP at 0x08FF out of reset. It is the same die.

3. Peripherals

Unchanged from docs/uno.md section 3, with one addition: the ADC's multiplexer has eight external channels rather than six. MUX3:0 of 0 to 5 select A0 to A5 as before; 6 and 7 select A6 and A7. 8 is the temperature sensor, 14 the 1.1 V bandgap and 15 ground, as before. DIDR0 still covers only bits 0 to 5: ADC6 and ADC7 have no digital input buffer to switch off on silicon either.

4. Host channel

host = "utf-8 bytes on USART0", as the Uno.

5. Time model and the part

Unchanged from docs/uno.md section 5: 16 MHz, 10 us slices, pin changes at their exact cycle, SLEEP parks the core.

Probe: the same bitmask. Bit 0 running, bit 1 sleeping, bit 2 the on-board LED on pin 13, bit 3 TX activity in the last 20 ms, bit 4 RX activity. Poke: 2 = press RESET, 3 = release. Crash handling is the same.

6. Firmware (firmware/nano/)

There is no second runtime. firmware/nano/build.sh runs firmware/uno/build.sh with BOARD=nano, which adds one flag, -DMOKXI_BOARD_NANO, and that flag does three things in firmware/uno/include/uno.h and nothing else:

	Uno	Nano
MOKXI_BOARD	"uno"	"nano"
NUM_ANALOG_INPUTS	6	8
A6, A7	not defined	20, 21

A6 and A7 are past NUM_DIGITAL_PINS, so pinMode, digitalWrite and digitalRead ignore them and analogRead reaches them as channels 6 and 7. Every other line of the runtime, including crt0.S and link.ld, is the same file, so an image built for one of these boards runs on the other, which is what the two boards being one chip means.

Examples under firmware/nano/examples/<name>/sketch.ino, built to web/public/firmware/nano/<name>.elf with web/public/firmware/nano/index.json: blink (pin 13), button (pin 2 INPUT_PULLUP to pin 13), serial, dial (a potentiometer on A7 fading an LED on pin 9 with hardware PWM).

The index's program field is "elf32 avr atmega328p nano", and the catalog entry says the same. It differs from the Uno's "elf32 avr atmega328p" only so that the editor offers each board its own example list; the ELF format behind the two strings is identical.

7. What is not modeled

Everything docs/uno.md does not model, and one more: the Nano's USB-to-serial bridge (an FT232RL on an original, a CH340 on most clones) is not a part. Serial reaches the serial monitor through the host channel, as it does on every other board here, and pins 0 and 1 stay plain GPIO rather than being wired to a bridge.

8. What this model is sure of, and what it is not

The chip is the Uno's, so docs/uno.md section 7 is this board's sorting too: the same data sheet, the same register map, the same tests, and the same list of behaviors that are approximations rather than data sheet numbers: an ADC with no error in it, an exact 16 MHz clock with no drift, three pad states and a threshold, an ideal supply that cannot brown out, a one-microsecond start-up, and a 10 us slice.

Two things are this board's own and neither is a guess: the thirty-pin header order in section 1, and A6/A7, which are ADC channels 6 and 7 on the TQFP package and are analog only. They have no port bit, so digitalRead, digitalWrite, pinMode and the internal pull-up do nothing on them, exactly as on a real Nano. Section 7 lists what is absent on top of the Uno's list.