NanoSoC has 31 pads. Nineteen carry signals: sixteen GPIO pads P0 to P15, the active-low reset and the two crystal pads. Twelve carry power and ground. The UART and the SPI flash bus do not have pads of their own: they use P0 to P5, which are GPIO pads that a peripheral takes over when its enable bit is set. So the pads are muxed, and the mux is simple: there is no pad-control register, and a shared pad follows the CTRL.EN bit of its peripheral. This topic teaches the table that says which function owns each pad, what every pad does before software configures anything, and how the package and the board survive the result. The GPIO block registers from the peripheral topic are assumed; this topic owns the wires from the blocks to the board.
Lesson | After it you can... |
|---|---|
Write a conflict-free mux table for NanoSoC, explain the EN-follows rule and check the table with a script. | |
Set safe reset defaults and pulls so the board never fights the chip, and keep the pad quiet while EN toggles. | |
Count pads, size the supply pads from current and bound switching noise per supply pair. |
Suggested order: top to bottom. The mux table first, because everything else annotates it; then reset states, which are one column of that table with physical consequences; then the package view, which is where the table meets the board. All pad counts and pin assignments in this topic are NanoSoC teaching values: they are consistent across the whole course and labelled as such.
No block sees the conflict: the UART owner asks for two pins, the SPI owner for four and the GPIO owner for sixteen, and the sharing only appears when all requests land on one package. Only the integrator holds every request and the authority to say that P0 to P5 serve two owners and what decides between them.