Spokes.wiki Search About

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)

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.

The constraint has an exchange rate

The thesis at the top says constraint organizes everything here. input-multiplexing-make is the first source that shows a constraint being traded, with prices attached in each currency.

The problem is banal: six switches, two pins left. The six answers are not variations on one technique but conversions between different scarce things. An I²C expander converts pins into program store — 190 bytes to read an 8-bit part, on an ATtiny with 1–2 kB total. A resistive ladder converts pins into analog headroom, and the number is the gap between adjacent codes: 59 mV worst case at 3 V on a 10-bit ADC. A diode ladder converts them into thermal stability, drifting −2 mV/°C. Matrix scanning and Charlieplexing convert them into capability, giving up simultaneous presses unless a diode per switch buys it back. Matrix scanning also barely pays below 4×4: six switches in a 2×3 saves one pin.

This gives microcontroller's integration reading its mirror. That page says vendors at the low end compete on what analog the die swallowed, because integration deletes external parts. Input multiplexing adds external parts to delete pins. Both are the same movement across the package boundary, run in opposite directions, and neither is generally correct — the direction is chosen by whichever of die area, board area or flash is binding this month. input-multiplexing holds the table.

And the source shape is new here. The standing caution below says this corpus has no independent number about anything. This one compares alternatives against each other on declared assumptions (3 V, 10-bit ADC, E12 resistors, 1–2 kB parts), which is checkable arithmetic rather than a spec sheet. It also arrives with a conflict the corpus has not met before: the comparison's winner is the author's own circuit, measured by the author, replicated by nobody. Vendor marketing was the failure mode this spoke learned to watch for. Author self-interest is a different one, and it looks more like evidence.

The radio was already a sensor (2026-08-15)

wifisense-pi opens a layer the spoke had listed as absent: sensing. It does it in the way that makes the fewest additions to the parts bin — an ESP32-S3, a Raspberry Pi 4, and the Wi-Fi router already in the room. No camera, no PIR, nothing worn, and it detects a motionless person by the 6 mm their chest travels while breathing.

The mechanism reframes something this corpus has taken as settled. Every page here treats the radio as the thing that makes an embedded device an IoT device — the link that brings the protocol stack, the platform layer and the landlord with it. wifi-sensing reads the same radio as an instrument: the multipath pattern across sub-carriers is a measurement of the room, and communication is only what the hardware was sold for. Capability here comes from signal processing over hardware that was already installed, not from what a vendor integrated on a die (microcontroller) or from parts added to the board (input-multiplexing). It is a third source of capability, and the cheapest of the three.

The instrument has to make its own stimulus, which is the detail worth keeping. CSI exists only when a packet arrives, so passive listening yields about 1 Hz of irregular samples and is useless. The Pi therefore sends the node 100 UDP packets a second for no reason except to be measured, and the sample rate becomes chosen rather than discovered. A device that floods the network purely to observe it is not the sensor-then-uplink pattern the rest of this corpus describes.

And it is the first source here that can be proved wrong. The standing caution below has moved twice: from "no independent number about anything" to "no number from anyone without a stake." This source does not close it — the author measured his own build — but it changes what the number is. Breathing rate is reported against known ground truth (14.1 bpm against 14.0; 22.0 against 22.0), the empty-room floor is stated (+1.1 dB motion, +0.0 dB vitals), and tools/validate_dsp.py drives the whole detector chain with synthetic CSI of exactly known rate — 81 checks, run by CI on every push, and named by the author as the only falsifiable part of the pipeline. A stranger can run it. Nothing else in this corpus offers that; the vendor datasheets do not, and input-multiplexing-make's arithmetic is checkable on paper but has no harness.

Limits published before features. The README's second section is "What it cannot do, and why", written because "most WiFi-sensing claims online are describing a different instrument" — no imaging (20 MHz of bandwidth gives 7.5 m of range resolution, larger than the room), no localisation from one path, no people count, no identity, no sleep stages. It also names its confounders: fans, curtains and pets register, and that is the instrument working. This is the third time the corpus has been served best by what a source admits — flipper-zero-diy was kept for a build that failed on cost, bitbang concedes its signalling is transparency rather than protocol. The pattern is now firm enough to state as a reading habit: in a field where specs are marketing, the sections about failure carry the most information.

Reuse as a fourth open-hardware pattern (2026-09-27)

suutari20, a DIY modular macro keyboard, adds a fourth thing an open-hardware project can inherit besides a licence: shared component footprints. Its PCB does not design its own key-switch or audio-jack footprints; it imports them from two other published keyboard projects (ScottoKeebs, the kbd library), the way software imports a package instead of rewriting it. That is a cheaper path than anything else this spoke has recorded — cheaper than The Open Book's from-scratch board and cheaper than flopperziro's breakout-module route, because the designer is not even redrawing the part, only assembling files someone else already verified against a fab house.

It still sits at the custom-PCB rung of the replication floor — building one means ordering a board, same as The Open Book — so the saving is in design time, not in build cost. And it arrives with the practice's usual candor about its own state: five of the project's seven wiki pages are one-revision placeholders reading "more information coming soon," and the README says outright that a YouTube video, not the documentation, currently holds most of what there is to know about it. A thin, honest hobby project is still evidence of the reuse pattern; it just isn't evidence of much else yet.

The firmware is also a new stack for this spoke: QMK with Vial on top, a purpose-built keyboard framework with graphical remapping, distinct from Zephyr's general-purpose, many-architectures RTOS. The corpus does not yet hold enough of either lineage to compare them; this is recorded as a fact about the source, not a claim about the layer.

verodesigner names the rung reuse and custom PCB sit above: stripboard. The spoke had two points on the replication-floor axis — flopperziro's bare breakout modules and the custom-PCB rung The Open Book and suutari20 both sit on. Point-to-point construction on pre-drilled stripboard is a third, older rung between them: no fabrication step, but no ready-made modules either, just cut tracks and jumper wire on generic board. What VeroDesigner adds is a tool that automates the layout-planning step of that rung from a drawn schematic, the same kind of saving suutari20's footprint reuse gave the PCB rung — cheaper design, not a cheaper object. Its component library (vacuum tubes, op-amps, an echo chip, a VCA) is skewed toward audio-DIY parts that belong to ../music-tech-wiki's domain rather than this spoke's; the tool itself is general-purpose, so the source lands here on dominant substance, with that facet recorded rather than duplicated as a page there.

Open questions

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. (Narrowed 2026-08-15: wifisense-pi supplies ground-truth-checked figures and a re-runnable validation harness, so the edge is no longer "nobody measures anything" — it is that nobody without a stake in the result has measured, and no vendor's number has been checked by anyone at all.)
  2. Still no protocol standard. CLOSED 2026-09-03 (research pass) by 6lowpan (T1) — RFC 4944 and RFC 6282, IETF Standards Track, read from the primaries. Not one of the three documents the edge named: IEEE sells 802.15.4, (wrong; corrected 2026-10-04, see 2a) the LoRa Alliance gates TS001, and the CSA routes Thread and Matter through a download-request form, so the free specification turned out to be the layer directly above — how an IPv6 packet crosses an 802.15.4 link, which is the part a device implements. It corrected iot-protocols's second-hand "127-byte frame" to the 102-octet MAC payload RFC 4944 actually states. Original text: zephyr broke the zero-T1 floor on 2026-08-05, but it is project documentation, not a specification. 2a. HALF CLOSED 2026-10-04 (research pass) by ieee-802-15-4 (T1, IEEE SA's own listing): the premise was wrong. IEEE gives 802.15.4-2024 away through the GET program (free account), so the radio tier is not bought. It is still not read: the page holds the scope and the access route, not the normative PHY/MAC text. Successor 2b below. The cross-spoke "sold standards" pattern loses its embedded-iot instance; loudspeaker-design (IEC) and cryptography (ISO/IEC) still hold. Original text: The radio tier itself is still bought, not read. New 2026-09-03, successor to the above. 6lowpan specifies what rides on 802.15.4 and takes the link's properties as given; the PHY and MAC — channel access, frame format, the 127-octet PHY limit, link-layer security — remain behind IEEE's paywall, and Thread, ZigBee and Wi-SUN are all gated too. This is the same wall ../loudspeaker-design-wiki hit on IEC 60268 and the curator has already ruled on there: a wiki built from freely-readable sources cannot hold a document that is sold. — needs: a freely-published equivalent (an IETF or ETSI document, or a standards-body overview with normative detail), or the observation stands as a property of the field. 2b. Read 802.15.4 itself. New 2026-10-04, successor to 2a. The 2024 PDF is free but sits behind an IEEE account login, which a research pass cannot create. — needs: the curator to download 802.15.4-2024 from IEEE GET into raw/, then an ingest of the MAC frame format, CSMA-CA and the link-layer security clauses. T1. One human action unblocks it.
  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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Circuit-level practice, beyond the one article. input-multiplexing opened the I/O layer, and the ordinary things around it — contact debounce, ESD protection, resistor-tolerance stacking, analog behaviour over long wire runs — are named as absent by that source and covered nowhere here. — needs: an application note (Microchip/TI) or a reference text, which would also give the spoke a number nobody selling anything produced (added 2026-08-15).
  6. Sensors as parts. wifi-sensing opened the sensing layer from an unusual angle; the ordinary layer beneath it — a transducer with a datasheet, an interface, a calibration curve and an error budget — has no page. — needs: a sensor datasheet or an application note on conditioning and calibration, which would also test whether wifisense-pi's MQ135 air-quality caveat generalises (added 2026-08-15).

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. Amended 2026-08-15: input-multiplexing-make supplies numbers that compare options against each other — millivolts of noise margin, bytes of flash — on stated assumptions, which is the first quantified comparison in the corpus. It is not independent either: the author's own design wins it. So the floor moves from "no numbers" to "no numbers from anyone without a stake." Amended again 2026-08-15: wifisense-pi adds the missing half of that sentence, which is method. Its figures are stated against ground truth and its detector chain ships with 81 CI-run checks a stranger can execute, so the corpus now holds one claim that is reproducible and none that is independent — two different things, and the gap between them is exactly what a second party running the harness would close. 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

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)

Product (sources)

Collection (sources)

BlogPosting (sources)

TechArticle (sources)

NewsArticle (sources)

SoftwareSourceCode (sources)

Person (entities)

Organization (entities)

Synthesis

Notes

Related pages

Links to

Linked from