The useful part of a silly idea
The visible result is a rickroll. The interesting part is the chain of network behavior that makes a phone open it automatically. The Pico creates an open network, leases an address, answers every DNS question with its own address, and redirects connectivity probes to a page stored in flash.
That makes the board a complete, intentionally tiny network appliance. There is no upstream router and no internet connection hiding behind it.
phone joins Free_WiFi
-> DHCP advertises 192.168.4.1
-> wildcard DNS points every host at the Pico
-> HTTP redirects the connectivity probe
-> the operating system opens its portal windowKeeping failure predictable
The server uses a fixed pool of eight connection slots and refuses excess work. Parsing and routing are kept outside the embedded SDK so they can compile and run as ordinary host-side C tests.
The first concurrent test exposed a subtler limit: zero-copy writes still consume lwIP segment metadata. Once that pool filled, a transfer stalled until the idle timeout. Increasing the pool and retrying stalled responses made pressure recoverable.
- No dynamic allocation in the HTTP path
- Eight bounded connection slots
- Host tests for parser and router
- Byte-exact checks on hardware
Flash lifetime is the trick
The GIF is larger than the Pico 2 W can hold in SRAM. It is embedded directly in the firmware image and served from the execute-in-place flash mapping. The immutable body can be passed to lwIP without copying because those bytes remain valid until acknowledgement.
The lesson is broader than the prank: data ownership and lifetime decide whether a zero-copy design is safe. Tiny systems simply make that contract impossible to ignore.