Log — Embedded & IoT Wiki

Append-only history. Entries start with ## [YYYY-MM-DD] <op> | <title> (split · ingest · query · lint).

[2026-07-27] split | embedded-iot-wiki created from the hub _inbox (4 sources)

Spun out by the hub router when awesome-iot arrived and completed a cluster of hardware strays that had been parked separately: nuvoton-nsc128l42-mcu (embedded-hardware, 2026-07-15), up-wcl-wildcat-lake-sbc (edge-hardware, 2026-06-18), the-open-book-ereader (open-hardware, 2026-07-14).

Why now, when two earlier passes said no. Both prior routers looked at these strays and declined to cluster them, on the grounds that a mixed-signal MCU, an x86 edge SBC and a DIY e-reader “share only hardware” and sit in four different sub-domains. That was a fair call on the evidence then: three unrelated-looking objects with no source describing the field they belong to. awesome-iot is that missing source. Its taxonomy puts bare MCUs, MCU dev boards, Linux SBCs, the RTOS layer and the protocol stack in one structure, which is what turns three strays into three points on one axis (embedded-systems). The spin-out is the hub rule applied (≥3 cohering sources, trigger counts), with the coherence supplied by the trigger.

Deliberately not migrated: the hub’s parked nvidia-doca-in-silicon-security — datacenter DPU silicon security, a different layer from edge/device hardware. Two earlier routing passes kept it separate and this one agrees; its _inbox record was updated with an adjacency note pointing here.

Founding pages: 4 sources + 5 concepts (embedded-systems, microcontroller, single-board-computer, iot-protocols, open-hardware) + spine.

Corpus honesty note recorded in synthesis: three of the four founding sources are vendor or author self-descriptions, and nothing here is independently measured. Entity nodes deferred at founding (see index.md notes). Biggest gap named on day one: no firmware/RTOS source.

avoid-ai-writing run over the founding prose. Site rebuilt + verified at the clean rung, as the hub requires for a split.

[2026-08-03] ingest | BitBang (richlegrand) — device connectivity without the cloud

Routed from the hub (Telegram). New: bitbang (T3 source summary), device-reachability (DefinedTerm/constraint). Updated: iot-protocols (the tier above the three tiers), synthesis (thesis addition + a shape-of-the-field bullet + two open questions + a first tension + two adjacency lines), index. Name warning recorded on the page, in the index and in synthesis: this is not bit-banging a protocol on GPIO and has nothing to do with ../bit-manipulation-wiki. Substance: bitbang serve prints a URL; a browser opens it and gets a shell, a file browser and an HTTP proxy to that machine over a WebRTC data channel. The signaling server authenticates the device by RSA challenge and brokers ICE/SDP, then leaves the data path. Device UID = hash of its public key, in the URL; 64-bit access code in the URL fragment, which browsers never send to a server, so the server can route a connection but not initiate one. Four repos incl. an OctoPrint integration (3D printer UI + H.264 camera behind one URL) and a WSGI/ASGI wrapper. MIT, 27★. Why it earned a concept page: it supplies the constraint the spoke was missing above iot-protocols — a NATed device can dial out and can’t be dialled, so something with a public address must hold the connection, and whoever runs that ends up owning accounts and data. device-reachability records that plus the project’s four-way broker taxonomy (cloud platform / tunnel / mesh VPN / introduction-only), which is a useful map independent of whether BitBang works. Best connection: the spoke now has two refusals of the middleman — the-open-book-ereader drops the radio and gives up remote access, BitBang keeps the network and removes the cloud. Same discomfort, different price. First tension in the spoke, recorded as altitude rather than contradiction: awesome-iot catalogues the platform layer as part of the stack; BitBang calls it an accident of timing. T3 justified — author’s own README plus two design docs, MIT and readable, but no independent audit, no benchmark, and no P2P success rate (symmetric/CGNAT and TURN fallback are undiscussed). Entity Rich LeGrand deferred per the spoke’s founding practice; noted in index. Verify deferred per hub policy (content-only). avoid-ai-writing run.

[2026-08-05] ingest | Zephyr RTOS documentation (research pass)

Via the hub research pass against growth edge #3. zephyr — the Zephyr Project’s own reference documentation, T1, the spoke’s first T1 and its first firmware source of any kind. Paged rtos alongside it as the concept, which answers the open question “does the RTOS layer deserve its own pages?” with a yes.

Gap-relevance: this was the spoke’s self-declared “most obvious gap” — a hardware-only corpus with nothing about the software running on it. It also retires the zero-T1 auto-edge that has sat on the hub ## Most wanted list since it was added.

What the ingest changed in the thesis rather than merely adding: the RTOS turns out to be where the protocol-tier fragmentation iot-protocols records gets absorbed — one kernel across 10+ architectures, the board expressed as devicetree data rather than a port. That is the first argument in the corpus that the fragmentation is survivable, and it comes from a project with no radio stack to sell.

Recorded weaknesses, because T1 here means authoritative and not disinterested: the docs give no footprint figure and no board count — the two numbers a reader would actually use — and name Common Criteria and FIPS 140-2 as schemes the project might pursue, holding neither. So the spoke still has no independent measurement of anything. Growth edges re-ranked accordingly: the vendor-sourced edge closes, and “still no protocol standard” plus “one RTOS is not a comparison” replace it.

Also located but not fetched: LoRa Alliance TS001 LoRaWAN L2 1.0.4, behind a resource-hub gate. Left as the named target for edge #2 rather than substituted with a summary of it.

[2026-08-05] ingest | awesome-iot (re-seen — refreshed in place)

The same URL arrived again via Telegram. Per the edge rule this refreshes awesome-iot in place; no new page, no _inbox duplicate. Changes since 2026-07-27: ~4.2k → ~4.4k★, 507 → 520 forks, and GitHub reports the licence as MIT where the page recorded CC0. Both licence readings are kept and the conflict flagged on the page — unresolved. Taxonomy and the accretes-rather-than-prunes caveat are unchanged; tier stays T3.

[2026-08-05] ingest | Awesome Embedded and IoT Security (Fraunhofer FKIE)

Routed from the hub (runner-up: defensive-security-wiki). New pages: awesome-embedded-iot-security (source, T2) and fraunhofer-fkie (Organization). CC0, 2.4k★, ~100+ entries across software tools, hardware tools, 13 books, 20+ papers, case studies, CTFs and conferences.

Graded T2, above the hub’s other curated catalogs: the curator is a publicly funded research institute with an academic record, not an anonymous individual. Noted that it also lists its own tool (FACT).

It closes the standing open question “where does device security land?”, and the answer keeps the seam where the spoke put it. Everything in the list is analysis of a device — firmware extraction, binary RE, JTAG/UART, side channels — which is a different activity from the fleet-defense practice defensive-security-wiki owns and which precedes it. Residual gap recorded: no network-tier section, so protocol-layer security remains unsourced on both sides.

Synthesis also gained the connection the spoke had been missing: open-hardware and hardware-based attack tooling are the same physical-accessibility property read from opposite ends.

[2026-08-08] ingest | FlopperZiro (lraton/FlopperZiro)

Routed from the hub (Telegram). T1 (official project repo), GPL-3.0, 1.8k★, Arduino/STM32. New pages: flopperziro, lraton. Updated open-hardware — this source earns it a third motivation.

Why it matters here rather than in a security spoke. The subject is a build: a parts list, a wiring diagram and firmware. The established seam (awesome-embedded-iot-security, 2026-08-05) already says the device as an object of study stays in this spoke while the practice of using one belongs to ../osint-wiki / ../defensive-security-wiki. Dual use is recorded on the page rather than argued.

The finding is in the bill of materials. STM32-L432KC, FS1000A/RXB12 433 MHz pair, PN532, SSD1306, microSD shield, TP4056 + boost, IR, six buttons — all commodity breakout boards, no custom PCB. Two things follow:

1. Substitution as a third reason to publish open hardware, beside platform-building and control-over-the-object. It needs neither a company nor a principle — only that the product’s functions decompose into parts already on sale.
2. The replication floor. the-open-book-ereader needs PCB fab and reflow to rebuild; this needs a soldering iron. The spoke had discussed openness as licensing and publishing, with the standing note that copying hardware costs money. It costs different money depending on whether a custom board is in the design.

Limits recorded, and labelled as inference from the BOM: fixed-frequency OOK modules replay simple 433 MHz codes and are not a frequency-agile transceiver, so the project reproduces the function list far more cheaply than the instrument. The author’s own disclaimer — “not intended to serve as a replacement for professional diagnostic hardware” — reads as accurate rather than defensive.

Entities: 1 created.

[2026-08-08] ingest | Flipper_Zero_DIY (cbwhickstein) — the negative case

Routed from the hub (Telegram), minutes after flopperziro and about the same target. T1 (official repo) and deliberately thin: 96★, 19 commits, no licence, “A NOT FINISHED Flipper Zero Clone.” New pages: flipper-zero-diy, cbwhickstein.

Ingested for the negative result. The author worked from the vendor’s published schematic toward a custom PCB, priced fabrication and assembly, and stopped: “because of the form factor and factory assambling the price of creating a DIY Flipper would exeed the price of a bought one” — roughly $220, above retail.

Why this matters more than the code. Paired with flopperziro it is a natural experiment on the replication floor this spoke named the same day. Two attempts at the same substitution, one rung apart: breakout modules and no custom board (works, 1.8k★) versus schematic-faithful custom PCB (abandoned, above retail). The deciding variable is form factor, and the author states it.

So the substitution motive added to open-hardware this morning gains a boundary condition rather than a caveat: it holds at the breakout-board rung and inverts at the custom-PCB rung, because what the commercial product sells is integration, and custom-board plus assembly costs do not fall at volume one. Folded into open-hardware and synthesis.

Recorded as a limit: one quote, one fab, one board, undated, no BOM published to check it against. That it stopped the project is the durable fact; $220 is indicative.

Entities: 1 created.

[2026-08-08] ingest | Raspberry Pi Pico series documentation

Routed from the hub (Telegram), third embedded source of the evening. T1, first-party. New pages: raspberry-pi-pico, raspberry-pi. Updated microcontroller, which had carried the Pico as a one-line example since 2026-07-27.

Dedup finding worth recording: the Pico was referenced on four pages (microcontroller, embedded-systems, awesome-iot, the-open-book-ereader) and had no page of its own — a recurring node the corpus used without owning. Created rather than refreshed.

Two things in the docs earn synthesis space.

1. RP2350 boots two instruction sets — “dual-core Arm Cortex-M33” or “dual-core Hazard3 RISC-V processor”, same silicon. The spoke’s fragmentation-absorption reading (zephyr: one kernel, a dozen architectures, board-as-devicetree) now has an instance one layer lower, in the chip. Absorption at two layers is a stronger claim than either alone.
2. The product matrix is mostly assembly. Strip wireless and the variants differ only by presoldered headers and a JST debug connector — soldering sold as a SKU — while castellated edges on the base model serve reflow into someone else’s board. That closes a loop with flopperziro / flipper-zero-diy from the same evening: the replication floor is an axis the vendors price too, not just a property of hobby builds.

Specs recorded: RP2040 M0+/133 MHz/264 kB/2 MB/8 PIO → RP2350 150 MHz/520 kB/4 MB/12 PIO; W variants Wi-Fi 802.11n + BT 5.2, WPA3, soft AP for four clients.

Standing caveat unchanged — first-party docs are authoritative for what is offered and give no power, throughput or comparative figures, the same limit the spoke records against up-wcl-wildcat-lake-sbc.

Entities: 1 created (raspberry-pi).

[2026-08-08] ingest | ESP32 (Espressif Series Datasheet v5.3)

Routed from the hub (Telegram), fourth embedded source of the evening. T1. New pages: esp32, espressif. Updated microcontroller, which had named the part since 2026-07-27 without linking one.

Source substitution, recorded: the link that arrived was the espressif.com product page, which is positioning with almost no figures. Ingested from the Series Datasheet v5.3 instead — same vendor, same product, actual numbers. The page’s url: points at the datasheet and says so.

Dedup: same shape as raspberry-pi-pico earlier tonight — ESP32 was referenced on three pages (microcontroller, awesome-iot, the-open-book-ereader) and owned by none.

Figures recorded: Xtensa LX6 single/dual core at 240 MHz on TSMC 40 nm; published CoreMark 539.98 (1 core) / 1079.96 (2 cores); 448 KB ROM, 520 KB SRAM, 16 KB RTC SRAM, QSPI to external flash; 802.11b/g/n to 150 Mbps with four virtual interfaces; BT 4.2 BR/EDR + BLE at +9 dBm; deep sleep 10 µA with a ULP coprocessor; secure boot, flash encryption, 1024-bit OTP, hardware AES/SHA-2/RSA/RNG.

The finding is the document, not the chip. Against the Pico the raw numbers are closer than reputation suggests (520 KB SRAM each, 240 vs 150 MHz) and the vendors diverge on what a datasheet is for: Raspberry Pi documents boards (headers, pads, connectors), Espressif documents silicon (benchmark, security blocks, process node, errata, and parts flagged NRND/EOL). Lifecycle status appears in no maker-board page here and is routine in a chip datasheet. Folded into synthesis as a statement of the spoke’s maker↔industry span.

Growth edge 1 narrowed, not closed. Espressif publishes a standard benchmark, which beats a TOPS figure; but it is self-reported, CoreMark ignores radio and power, and nobody has run the two parts against each other. Two first-party datasheets are not a comparison — that sentence is now on the page and in synthesis.

Entities: 1 created (espressif).

[2026-08-08] ingest | ESP32 (Wikipedia) — the family, and the RISC-V migration

Telegram source, en.wikipedia.org/wiki/ESP32, T2 (encyclopedic coverage of an established product). Dedup: esp32 already existed, ingested from the Series Datasheet v5.3 hours earlier, so this refreshed that page in place rather than creating a second one. No new pages.

What it adds over the datasheet, which is the whole reason it was worth reading: the launch date (6 September 2016, succeeding the ESP8266), the full variant lineup, and the architecture split. Xtensa stops at the S-series; C2, C3, C5, C6, H2 and P4 are all RISC-V, including the 360 MHz P4. Where the two sources overlap on specs the datasheet wins and the Wikipedia figures were not used.

Reads on the spoke’s absorption thread, and against it. RP2350 absorbs the ISA choice into the silicon; Espressif makes the choice once at the vendor level. Recorded in synthesis as a counter-example rather than folded into the existing reading. espressif updated with the one-directional branch; esp32 gained the lineup table and the ESP-IDF note.

No entity discovery — espressif is already a node and Wikipedia names no author.

[2026-08-10] ingest | “$5 microcontroller as a side business” — a paywalled stub

Routed here by the hub. Source: https://medium.com/@andy25/how-a-5-microcontroller-could-quietly-become-your-side-business-1c55ec2a50e2, T4. Page: microcontroller-side-business.

Body never read. WebFetch returned a truncated preview; the firecrawl fallback hit Medium’s members-only regwall outright. Per ../HUB.md, that exhausts the escalation, so this is an honest stub built from the preview rather than a summary pretending to be a reading.

What survives: the thesis “It’s never the chip that sells. It’s the object you hide it inside,” the “exactly one job” design rule, and three examples (weather station, electronics in a handbag, cereal box as a game console). No prices, no revenues, no evidence any such business exists. Author has 457 followers and no stated credentials.

Kept for one reason. It states plainly what this spoke’s corpus keeps demonstrating silently — the esp32 is in nearly every project here and is never the subject of one (the-open-book-ereader, flipper-zero-diy). And it pairs with mimiclaw in ../agentic-tooling-wiki, routed hours earlier: that project’s “$5 chip” headline hides a ~$10 board and metered API calls per turn. Two sources in one day pricing a product at its cheapest component; this one at least admits the chip is not the product.

Refresh in place if the article ever becomes readable.