Synthesis — Embedded & IoT

The evolving thesis. Spun out of the hub _inbox on 2026-07-27 from four sources: three hardware strays parked separately over six weeks — an MCU (nuvoton-nsc128l42-mcu, embedded-hardware), an edge SBC (up-wcl-wildcat-lake-sbc, edge-hardware), a DIY device (the-open-book-ereader, open-hardware) — plus awesome-iot, the field catalog that arrived and made them one subject instead of three.

Current thesis

Constraint is the organizing principle. Every design decision recorded here traces back to a limit: power, memory, cost, board area, or a real-time deadline. embedded-systems is the statement of that; the rest of the corpus is instances.

The field is a spectrum, and the word “embedded” hides it. A metrology MCU running bare-metal firmware in milliwatts and an x86 SBC booting Ubuntu at 30 W are both “small computers,” three orders of magnitude apart in power and completely different in software. The middle rung — an MCU dev board like the Pico in The Open Book — is where most projects actually live. Reading a source starts with locating it on that axis.

Integration is the competition at the bottom, compatibility at the top. Nuvoton sells a 24-bit ADC and an amplifier on the die, not clock speed: what matters is which analog the chip swallowed and how many external parts that deletes. UP WCL sells x86 in a Raspberry-Pi form factor: what matters is running the software the customer already has, at a cost in watts. Different ends of the spectrum compete on different axes.

Embedded plus a network is IoT, and the network brings the rest of the field. The protocol stack, the platform and middleware layer, the alliances, and the security surface all arrive with connectivity. The Open Book has no radio and is fully embedded — a useful reminder that the two words in this spoke’s name are not synonyms.

One of the things the network brings is a landlord, and that part is contingent. A device behind NAT can dial out and cannot be dialled (device-reachability), so something with a public address must hold the connection — and whoever runs it ends up owning the accounts, the subscriptions and the data. bitbang is the corpus’s first source arguing that the second half doesn’t follow from the first, and that IoT settled into Platform-as-a-Service by timing rather than necessity.

The shape of the field (early)

• Layering is real and contested. iot-protocols splits cleanly into radio, network and application tiers, but the middle tier holds several incompatible stacks (Thread, ZigBee, Z-Wave, 6LoWPAN), each with an alliance controlling its specification and certification. Fragmentation here is a governance fact, not just a technical one.
• Open hardware is two different practices. Publishing a design to grow a platform (Arduino, BeagleBoard) and publishing so the owner controls the object (the-open-book-ereader) share a license type and almost nothing else (open-hardware).
• Edge AI has become a spec row. An NPU with a TOPS number is now standard on an edge board. Nothing in the founding corpus measures what those numbers deliver on a real model.
• Refusing the middleman is a recurring move with two forms (added 2026-08-03). the-open-book-ereader drops the radio and gives up remote access; bitbang keeps the network and removes the cloud from the data path. Same discomfort — someone else’s server between you and your device — and two different prices paid for it (device-reachability). Neither is what the field shipped by default.

Substitution, and the replication floor

open-hardware held two motivations for publishing a design — platform building (a company makes the boards adoptable) and control over the object (the schematic is a right-to-repair argument). flopperziro is a third: substitution, publishing so a commercial product’s capability can be had without buying it.

The three differ in what they require. Platform building needs a company; control-over-the-object needs a position; substitution needs only that the product’s functions decompose into parts already on sale. Where they do, what the commercial product still owns is integration, firmware and industrial design — and FlopperZiro’s own bill of materials is the demonstration: an STM32, a 433 MHz transmit/receive pair, a PN532, an OLED, a microSD shield and a LiPo charger, every one a commodity breakout board with no custom PCB anywhere.

That gives the spoke a second axis it did not have: the replication floor. The Open Book publishes a board, so rebuilding it needs fabrication and reflow; FlopperZiro publishes a wiring diagram, so rebuilding it needs a soldering iron. Openness has usually been discussed here as a licensing and publishing question, with the standing note that copying hardware still costs money. It costs different money depending on whether a custom board is in the design, and that is a design decision rather than a licence one.

The pair tests it, and the boundary is form factor. flipper-zero-diy arrived minutes after FlopperZiro and attempted the identical substitution the other way — the vendor’s own schematic, a custom PCB, factory assembly — and its author abandoned it after pricing the build at roughly $220, above what the device costs to buy: “because of the form factor and factory assambling the price of creating a DIY Flipper would exeed the price of a bought one.” Two attempts at the same target in the same week, one at each rung of the replication floor, with opposite results.

So substitution is not a general property of open hardware; it has a stated boundary condition. It holds while you accept a bigger, wired, hand-assembled object and inverts the moment you try to match the form factor. Which says what the commercial product is actually selling: not the parts, not the function list, but integration — and integration is the one thing a build of one cannot buy cheaply, because custom-board and assembly costs do not fall at volume one.

The honest limits sit in the same BOM. Fixed-frequency OOK modules capture and replay simple codes; they are not the frequency-agile transceiver the commercial original carries. Substitution reproduces the function list far more cheaply than it reproduces the instrument — which is also why the author’s own framing (“not intended to serve as a replacement for professional diagnostic hardware”) reads as accurate rather than defensive.

Dual use, on the record. BadUSB, RFID emulation and RF replay are what make this class of device contentious, and the hub already carries a dual-use posture in ../osint-wiki and ../defensive-security-wiki. The seam this spoke settled with awesome-embedded-iot-security holds unchanged: the device as an object of study stays here, the practice of using one belongs there. The BOM adds one observation to it — the capabilities are reachable from generic modules with ordinary uses, so this object differs from a branded product in ways this corpus has no source on.

Hand assembly is a priced product decision

Three sources landed the same evening and they converge on something the spoke had only half-seen. flopperziro and flipper-zero-diy showed the replication floor deciding whether a design gets rebuilt — breakout modules and a soldering iron on one side, custom PCB and factory assembly on the other, with the second attempt abandoned above retail. raspberry-pi-pico shows the same axis from the vendor’s side of the counter.

Strip the wireless option from the Pico line and the remaining variants differ in exactly two things: presoldered pin headers, and a keyed JST debug connector instead of castellated pads. Raspberry Pi sells soldering as a SKU. Meanwhile the castellated edges on the base model exist so the module can be reflow-soldered into someone else’s board — the same part, priced for the professional integration path.

So open-hardware‘s note that “copying still costs money” resolves into something more specific: the cost that decides replication is usually assembly, and the whole market is organised around it — DIY projects avoid custom boards to stay rebuildable, and vendors sell headers, connectors and castellations to move builders between rungs.

A second observation from the same source, on the spoke’s fragmentation thread. The standing reading here is that the field’s fragmentation gets absorbed rather than argued about, with zephyr as the example: one kernel across a dozen architectures, the board as devicetree data. RP2350 does it a layer lower — one chip that boots either Arm Cortex-M33 or Hazard3 RISC-V cores. Arm-versus-RISC-V stops being a board-selection decision at all. Absorption is now visible at two layers of the stack, silicon and RTOS, which is a stronger claim than either instance alone.

And the ESP32 arrived hours later, which turns that caveat into a finding. The Pico page’s limit was that it says nothing comparative — “no comparison against ESP32 or STM32, the parts a buyer actually chooses between.” The corpus now holds both, and the useful difference is not in the numbers (520 KB SRAM each; 240 MHz against 150 MHz) but in what each vendor thinks a datasheet is for.

raspberry-pi documents boards: headers, castellated pads, debug connectors, which variant carries a radio. espressif documents silicon: a published CoreMark score, secure boot and flash encryption, a 40 nm process node, an errata reference, and a front page flagging parts NRND and EOL. Part-lifecycle status appears in no maker-board page in this corpus and is routine in a chip datasheet.

So the two vendors sell into one market and address different readers — one assembling something, one designing a product that must still be buildable in five years. That is a cleaner statement of this spoke’s MCU↔SBC-and-maker↔industry span than any spec table, and it came free with the pair.

The vendor-specs edge stands, slightly narrowed. Espressif at least runs a standard benchmark, which is more than a TOPS number or a clock speed; Raspberry Pi publishes none for the Pico. But a vendor running CoreMark on its own part is still self-reported, CoreMark says nothing about radio, power or real workloads, and nobody has run the two against each other. Two first-party datasheets are not a comparison.

The absorption reading gets its counter-example the same evening, from the ESP32 Wikipedia article (T2) read against the datasheet already here. Espressif’s family splits by instruction set, and the split runs one way: Xtensa stops at the S-series, and the C2, C3, C5, C6, H2 and P4 are all RISC-V, including the 360 MHz P4, the fastest part in the line.

Set beside RP2350 that is two vendors answering the same question in opposite directions. Raspberry Pi absorbs the choice into the silicon — one chip, either Arm or Hazard3 RISC-V, the buyer need not decide. Espressif decides once, at the vendor level, and ships the answer as the only option on every new part. So “the field’s fragmentation gets absorbed rather than argued about” holds for Raspberry Pi and zephyr and does not describe Espressif, which resolved the fragmentation by picking a side and migrating a product line onto it.

The interesting part is that neither vendor argues for its approach anywhere. You read Raspberry Pi’s position off one datasheet and Espressif’s off a list of part numbers, which is a reminder that this spoke’s sources are documents written to sell parts, not to explain strategy. What makes the ESP32 migration cheap for anyone downstream is ESP-IDF covering the ESP32, S, C and H series under one API — the ISA move is a recompile. Absorption did not disappear; it moved from the silicon to the SDK.

Open questions

• Does the RTOS layer deserve its own pages? Answered 2026-08-05 (research pass). Yes, and the gap is now open at the bottom instead of the top: zephyr‘s own documentation is the spoke’s first firmware source and first T1, and rtos pages the layer. What the answer turned up is that the RTOS is where the field’s fragmentation gets absorbed rather than argued about — one kernel across 10+ architectures, with the board expressed as devicetree data instead of a port. Residual: awesome-iot names FreeRTOS, mbed, Contiki, Mynewt and the MicroPython/TinyGo/Rust wave, and one instance is not a comparison.
• What do the TOPS figures actually buy? up-wcl-wildcat-lake-sbc claims 15–17 TOPS of NPU; no source here (or in ../llm-inference-wiki) connects such a number to achieved performance on a named model at a named quantization. Vendor peak arithmetic is all the corpus has.
• Where does device security land? Answered 2026-08-05 by awesome-embedded-iot-security, and the seam held. fraunhofer-fkie‘s catalog is ~100+ entries of firmware extraction, binary reverse engineering, JTAG/UART probing and side-channel work — all of it analysis of a device, done to find out what it runs and where it breaks. That is a different activity from the hardening-to-a-benchmark, SOC-triage, coordinated-disclosure practice ../defensive-security-wiki owns, which begins after somebody has done this. The device as an object of study stays here. Residual: the list has no section for the network tier, so iot-protocols-layer security is still unsourced either side of the boundary.
• Does peer-to-peer device access actually work in the field? (added 2026-08-03) bitbang‘s case rests on a direct browser↔device connection, and NAT traversal fails often enough that WebRTC ships TURN relays for the cases it can’t crack. The entry README doesn’t give a success rate or discuss fallback, and no source here measures one. Symmetric NATs and carrier-grade NAT are where this claim would be won or lost.
• Is the trustless-signaling argument sound? (added 2026-08-03) It rests on the browser verifying the device’s key against the URL and on the served JavaScript being inspectable — the document concedes the second is transparency rather than protocol. No independent review of the design exists, and the spoke has no cryptography source to judge it against. ../defensive-security-wiki is the natural home for that assessment if one arrives.
• How wide is “embedded”? Sensors, robotics, industrial control, automotive and RF design are all adjacent and unsourced. Per CLAUDE.md, broaden this spoke rather than fragment — but the boundary against ../loudspeaker-design-wiki and ../music-tech-wiki (audio hardware by purpose) should stay where it is.

Physical accessibility is one property with two names (2026-08-05). open-hardware is about publishing a design so anyone can build the thing. awesome-embedded-iot-security has a whole section of hardware tools — debug interfaces, wireless testing gear, a ChipWhisperer — because on an embedded target the pads on the board are part of the attack surface. Openness and analyzability are the same fact read from either end: a device you can hold is a device you can probe, whether the schematic was published or not. The spoke had both halves and no line between them.

The list’s shape says something else about the field. Case studies are a top-level category, sitting beside the papers — knowledge here lives in worked examinations of specific devices more than in general results, which is what embedded-systems’ constraint thesis predicts: a finding on one SoC frequently does not carry to the next. The corpus’s own reading of vendor specs as unmeasured snapshots is the same problem from the buyer’s side.

Growth edges

Ranked; each names the kind of source that would close it (see ../QUALITY.md → Growth edges).

1. Vendor specs are unmeasured. NPU TOPS and power figures are manufacturer claims, and nothing independent has landed. — needs: a T2 independent benchmark of edge-AI hardware.
2. Still no protocol standard. zephyr broke the zero-T1 floor on 2026-08-05, but it is project documentation, not a specification: the radio/network tier (iot-protocols) is described here only at second hand. — needs: IEEE 802.15.4, a Thread spec, or LoRa Alliance TS001. (The LoRaWAN L2 1.0.4 spec was located during the same pass and is behind a resource-hub gate; not fetched.)
3. One RTOS is not a comparison. zephyr answers what the layer is; nothing says what choosing it costs against FreeRTOS or a language-wave runtime. — needs: a second T1 project doc, or better, a T2 comparison with footprint/latency measurements — the numbers Zephyr’s own docs omit.
4. Entirely vendor-sourced. Closed 2026-08-05 — zephyr, T1. Superseded by #2 and #3, which name what the floor still lacks rather than that it lacked everything.

Coverage edges (added 2026-08-08, at the curator’s request for a wider backlog). These widen what the spoke covers instead of answering an open question above; one ordinary solid source closes any.

5. Arduino. The largest embedded ecosystem by number of users, absent while esp32 and raspberry-pi-pico both have pages. — needs: project documentation plus one comparison of its toolchain against the vendor SDKs.
6. The protocol candidates themselves. Growth edge 2 says no standard has won; the spoke holds iot-protocols as one overview page and none of Matter, Thread, Zigbee, BLE or LoRaWAN individually. — needs: the specifications, one page each.
7. Updating a device already in the field. OTA update, secure boot and rollback are where embedded projects actually fail, and no page covers any of it. — needs: a vendor’s update architecture doc or a published field-failure account.
8. The workload behind the NPU numbers. Growth edge 1 doubts vendor TOPS figures for a workload — on-device inference — that has no page. — needs: a TinyML paper or a measured on-MCU benchmark. Cross-spoke: the serving side lives in llm-inference-wiki.

Contradictions / tensions

No factual conflict yet — the sources describe different layers rather than competing claims. The closest thing is a disagreement about what the field’s default architecture is for: awesome-iot catalogues the platform/middleware layer as simply part of the stack, while bitbang treats that layer as an accident of timing that a peer-to-peer transport makes unnecessary. One is a map, the other is an argument, so they don’t contradict so much as sit at different altitudes — worth revisiting if a source defends the cloud pattern on its merits.

The standing external caution is source quality, now partly relieved and worth restating precisely. zephyr (2026-08-05) is the first source here that is not selling a part, and it moves the spoke off an all-T3 floor. It does not supply measurement: its own documentation declines to give a footprint figure or a board count, and names Common Criteria and FIPS 140-2 as schemes the project might pursue rather than holds. So the corpus now has an authoritative description of one software layer and still no independent number about anything. The rest of the caution stands: three of the four founding sources are vendor or author self-descriptions relayed by trade press or a README. Specs here are claims, and awesome-iot compounds it by listing long-dead hardware beside current parts without marking which is which.

Cross-spoke adjacency

• ../cloud-wiki — rented compute and its pricing; this spoke owns the physical board.
• ../llm-inference-wiki — how models are actually served; the NPU/TOPS spec line is the seam.
• ../platform-ops-wiki — operating production systems; device-fleet operations is the seam.
• ../defensive-security-wiki — blue-team practice, including for devices; the parked nvidia-doca-in-silicon-security (datacenter DPU silicon) stayed in the hub _inbox as a different layer and was deliberately excluded from this spin-out.
• ../dev-tooling-wiki — general build/ship infrastructure; embedded toolchains and RTOSes are the device’s own software and route here. bitbang is the standing boundary case: it reaches any machine, so its ngrok/Tailscale-shaped half is a general remote-access tool. Routed here on dominant substance (its argument, its origin in a robot kit, and its OctoPrint integration are all device-layer); the general-purpose framing is the runner-up reading, recorded rather than split.
• ../bit-manipulation-wiki — name collision only. bitbang is device connectivity, not bit-banging a protocol on GPIO and not bit twiddling. Never merge on the slug.

Index — Embedded & IoT Wiki

Catalog of every page, grouped by schema.org @type. Spine: synthesis (thesis), log.md (history), this file (catalog). Spun out of the hub _inbox on 2026-07-27 (4 sources). Board specs, prices and launch dates are dated snapshots.

DefinedTerm (concepts)

• embedded-systems — umbrella: computers built into things that aren’t computers; the MCU↔SBC spectrum and the constraint that shapes every decision on it · domain
• microcontroller — MCU: whole computer on a die, firmware not an OS; mixed-signal integration is the competition, Cortex-M the substrate · hardware-class
• single-board-computer — SBC: general-purpose OS on one board; the ARM template and the x86 counter-move; the NPU spec row · hardware-class
• iot-protocols — the three-tier stack (radio / network / application), why constrained links produced MQTT and CoAP, and the alliances that own the specs · standard-family
• device-reachability — a device behind NAT can dial out and can’t be dialled; the constraint the IoT cloud pattern is a workaround for, and the four things a broker can do once it has introduced two endpoints · constraint
• open-hardware — publishing a design so others can build it; ecosystem-building vs control-over-the-object; design for hand assembly; per-component licensing · practice
• rtos — the scheduler-with-deadlines rung between bare metal and a general-purpose OS; why “real-time” means bounded worst case, not fast; hardware-as-data as the layer’s recurring design answer · software-layer

Product (sources)

• raspberry-pi-pico — Raspberry Pi‘s first-party Pico docs: RP2040 (M0+, 133 MHz, 264 kB, 8 PIO) → RP2350 (Cortex-M33 or Hazard3 RISC-V from the same silicon, 150 MHz, 520 kB, 12 PIO); W variants add Wi-Fi 802.11n + BT 5.2, WPA3, soft AP for four clients. The non-wireless variants differ only by presoldered headers and a JST debug connector — assembly convenience sold as a SKU · source · T1 · raspberrypi.com

• esp32 — Espressif‘s Wi-Fi + BT combo SoC, from Series Datasheet v5.3: Xtensa LX6 single/dual core at 240 MHz, published CoreMark 539.98 / 1079.96, 520 KB SRAM + 448 KB ROM, 802.11b/g/n to 150 Mbps, BT 4.2 BR/EDR + BLE, deep-sleep 10 µA with a ULP coprocessor, secure boot + flash encryption + AES/SHA-2/RSA/RNG, 40 nm. Its front page flags parts NRND/EOL — a silicon-vendor document where the Pico’s is a board document. Refreshed 2026-08-08 from Wikipedia (T2) with the family lineup: Xtensa stops at the S-series and C2/C3/C5/C6/H2/P4 are all RISC-V, up to the 360 MHz P4 · source · T1 (+T2) · espressif.com / en.wikipedia.org

Collection (sources)

• awesome-iot — HQarroum’s curated IoT catalog (CC0, ~4.2k★): boards, RTOSes, frameworks, middleware, the full protocol stack, standards bodies, books; the trigger source, and an accreted archive that lists dead hardware beside current parts · source · T3 · github.com/HQarroum

• awesome-embedded-iot-security — Fraunhofer FKIE‘s embedded/IoT security list (CC0, 2.4k★, ~100+ entries): firmware-analysis frameworks (FACT, Ghidra, radare2, binwalk), hardware tools (Bus Pirate, ChipWhisperer), 13 books, 20+ papers, case studies, CTFs, Hardwear.io. Answers the spoke’s “where does device security land?” — the practice it catalogs is analysis of the device, not fleet defense · source · T2 · github.com/fkie-cad

BlogPosting (sources)

• microcontroller-side-business — stub, paywalled: Medium post (Andy Nguyen, 2026-08) whose one readable thesis is “It’s never the chip that sells. It’s the object you hide it inside.” Body unreadable via WebFetch and Firecrawl; no prices, revenues or evidence. Kept for the symmetry with mimiclaw‘s “$5 chip” headline in ../agentic-tooling-wiki · source · T4 · medium.com

TechArticle (sources)

• zephyr — the Zephyr Project’s own documentation (Apache-2.0): 10+ architectures under one kernel, EDF and preemptive scheduling, thread-level memory protection without an MMU, devicetree + Kconfig + west. The spoke’s first T1 and first firmware source — and it gives no footprint figure, no board count, and holds no certification · source · T1 · docs.zephyrproject.org

NewsArticle (sources)

• nuvoton-nsc128l42-mcu — All About Circuits: Nuvoton’s Cortex-M23 MCU with a 24-bit sigma-delta ADC, LCD driver and Class-D amp on one die; the analog-integration pitch, aimed at metrology (BP monitors, precision scales) · source · T3 · allaboutcircuits.com
• up-wcl-wildcat-lake-sbc — CNX Software: AAEON’s credit-card x86 SBC on Intel Wildcat Lake — 24 GB LPDDR5, Xe3 + a 15–17 TOPS NPU, ~30–36 W; x86 entering the Pi form factor for edge AI and industrial use · source · T3 · cnx-software.com

SoftwareSourceCode (sources)

• flipper-zero-diy — cbwhickstein‘s abandoned attempt at the same clone by the other route: vendor schematic → custom PCB → factory assembly, stopped after pricing it near $220, above retail (“because of the form factor and factory assambling…”). 96★, 19 commits, incomplete. Held for the negative result — it is the control case that turns the substitution motive into a boundary condition · source · T1 · github.com/cbwhickstein
• flopperziro — lraton‘s DIY Flipper Zero clone (GPL-3.0, 1.8k★, Arduino/STM32-L432KC): 433 MHz TX/RX, PN532 NFC, IR, BadUSB, SSD1306 + microSD, LiPo/TP4056 — entirely commodity breakout boards, no custom PCB, which makes it the spoke’s lowest replication floor (a soldering iron, not a PCB fab). Adds a third motivation to open-hardware: substitution — capability without the purchase. Dual-use recorded; parts-list limits (fixed-frequency OOK) noted as inference · source · T1 · github.com/lraton
• bitbang — Rich LeGrand’s MIT-licensed “turn any machine into a URL”: WebRTC data channels instead of a cloud data path, no account, no port forwarding, browser as the client; the trustless-signaling trust model and the claim that IoT’s Platform-as-a-Service pattern is an accident of timing. Not bit-banging GPIO · source · T3 · github.com/richlegrand
• the-open-book-ereader — Joey Castillo’s DIY open-hardware e-reader: RP2040 Pico + e-paper + hand-solderable PCB, libros firmware; a right-to-read argument in schematic form, and an embedded device that is deliberately not IoT · source · T3 · github.com/joeycastillo

Person (entities)

• lraton — GitHub handle behind flopperziro; no biography evidenced · maintainer · thin node
• cbwhickstein — published the costing that killed flipper-zero-diy; a negative result, which is rarer than a working build · maintainer · thin node

Organization (entities)

• espressif — Organization: fabless vendor of the ESP32/ESP8266 families and ESP-IDF; documents silicon (benchmarks, errata, lifecycle) where raspberry-pi documents boards · vendor
• raspberry-pi — Organization: maker of the Pico boards and RP2040/RP2350; the rare vendor sitting on both ends of this spoke’s MCU↔SBC axis · vendor
• fraunhofer-fkie — German applied-research institute (Cyber Analysis & Defense); publishes awesome-embedded-iot-security and FACT — an institutional curator with a tool of its own in the list · entity

Synthesis

• synthesis — the thesis: constraint is the organizing principle; the field is a three-orders-of-magnitude spectrum, and embedded + a network is what makes it IoT

Notes

• Entity nodes deferred at founding — Halim Qarroum (awesome-iot), Joey Castillo (The Open Book), Rich LeGrand (BitBang, and the Goby robot behind it) and the vendors (Nuvoton, AAEON, Intel, Espressif, Raspberry Pi Foundation) are named on their pages but not paged. Page one when it recurs or a query needs it; the vendors are the likeliest first, since this field’s sources are mostly vendor announcements.
• Deliberately excluded from the spin-out: the hub’s parked nvidia-doca-in-silicon-security (datacenter DPU silicon security). Two prior routing passes kept it on a separate layer from the edge/embedded strays and this spin-out preserves that call.
• Biggest founding gap: no firmware/RTOS source. awesome-iot names the layer; nothing here documents it.