With the AI chat docked, the canvas header ran out of room and the Camera
and Microphone buttons overlapped the icons before them (visible as
"…Camera" colliding on a XIAO-S3-Sense board). Serial and Scope already
collapse to icon-only via the `@container unified-toolbar` query
(font-size: 0 hides the label, the fixed-size SVG stays), but Camera/Mic
carried their layout in INLINE styles, and an inline font-size beats the
class rule so the query could never reach them.
Move the two toggles' static layout into a shared `.canvas-cam-mic-btn`
class (only state-driven styles — background, border, colour, the pulse
animation — stay inline) and add that class to the same collapse rules as
Serial, in both the container query and the mobile media query. Also drop
the header button gap from 8px to 4px once the toolbar is narrow so all
four (Serial/Camera/Mic/Scope) pack in without overlapping.
Side effect: the toggles now share Serial's 28px height, so the toolbar row
lines up (they were a touch shorter before).
b02aab9a picked up frontend/src/pro — a symlink to a private-overlay
checkout that only exists on one machine; every other clone got a
dangling link. The ignore patterns had a trailing slash, which matches
directories but not symlinks — that is exactly how it slipped past.
Drop the slash so both forms stay ignored.
New lib/newsEvents.ts registry (same pattern as newsSource.ts): OSS
default is a no-op sink; an extension overlay can register one to
forward the signals to its own analytics. NewsAnnouncer reports the
toast impression and modal opens (toast vs Help menu); NewsMarkdown
grows an optional onInteract callback fired on body link clicks and
YouTube preview plays — the admin authoring preview passes nothing, so
authoring never counts as engagement.
c201f5d9 guarded the property-sync effect, but the mount effect has its
own raw Object.entries(properties) loop that runs first and assigned the
saved imageData: '' onto the fresh element — so the firstUpdated
putImageData crash survived. Same guard, second call site.
Saved projects carry imageData: '' in the SSD1306's properties (the
generated metadata lists it as a text prop). The property-sync effect
assigned that string onto the web component, replacing the element's
live ImageData and crashing wokwi-elements' firstUpdated with
'putImageData: parameter 1 is not of type ImageData' on every project
load. Only a real ImageData may pass through now.
The bridge was a passive sniffer that never drove the ACK bit. That
worked by accident: avr8js seeds a pin's external input value to 0, so
when TinyWireM released SDA for the ACK slot the master read 0 (ACK)
and kept transmitting. Commit eb3b04ef (seed INPUT_PULLUP pins to their
resting level) now sets that external value HIGH at init, so every ACK
slot read back NACK and TinyWireM aborted each transmission right after
the address byte: 239 address frames, zero data bytes, zero STOPs, and
a permanently blank SSD1306 on every ATtiny85 + Tiny4kOLED project.
Fix: capture each byte's ACK through the bus master callbacks (the
bridge owns the master slot on the ATtiny85) and hold SDA's external
input low for the whole ACK slot. Timing matters: TinyWireM strobes the
USI with USICS1|USICLK (avr8js clockSrc 3), which samples DI at the top
of the FALLING USITC write, one toggle after the 9th rising edge, so
the drive is released only on the falling edge that closes the slot.
Unowned addresses now read back NACK like real hardware.
Regression test replays TinyWireM's exact register sequence (from the
ATTinyCore disassembly) against a real AVRSimulator.
The canonical MicroPython connect idiom is `while not wlan.isconnected():
pass` — a pure Python busy-wait, and most gallery WiFi examples use it.
The emulated CPU only fast-forwards through WAITI idles, so a busy-wait
pins the sim at real execution speed (~2% of the chip in a browser tab).
Measured on the classic-ESP32 engine with a marker-bracketed harness: the
connect+DHCP phase costs ~1.5M busy instructions under a sleepy poll loop
and ~194M under the busy-wait — same firmware, same radio, 130x apart.
At browser speed that is close to a minute of wall clock for the connect
alone, which reads as "WiFi hangs" and got diagnosed as exactly that.
The proxy now sleeps 20ms per unanswered isconnected()/status() poll,
turning the user's busy loop into an idle loop without touching their
code. Re-measured end-to-end with the real prelude: 226.8M -> 64.3M busy
steps, and the made-up-SSID example connects with a 10.13.37.x lease on
the in-browser engine.
Deploy verification of the #262 fix caught a backend split the issue
could not see. The reporter runs the OSS Docker image, where MicroPython
executes under the QEMU worker — there the real driver works and their
fix verification (DHCP on 192.168.4.x, DNS, TCP) holds. But velxio.dev
routes a plain ESP32 MicroPython run to the in-browser esp32js engine,
and the engines' P4 WiFi (which serves Arduino fine) does not yet cover
MicroPython's v1.20 / esp-idf-4.2 vintage esp_wifi blob: handing it the
real module stalls esp_wifi_init with NO output — observed live as four
minutes of dead serial after the raw-REPL paste, strictly worse than the
stub's fake-but-responsive answers.
So the prelude now asks the bridge: an overlay bridge that keeps the
MicroPython run in-browser declares micropythonWifiSupported=false and
keeps the stub; the QEMU path (every OSS install, and ?esp32sim=qemu in
the overlay) gets the real driver + SSID-rewrite proxy. When an engine
gains MicroPython WiFi it flips its declaration and this file needs no
further change.
Property is duck-typed and optional; the plain OSS Esp32Bridge does not
define it, and undefined means supported — OSS behavior is exactly the
reporter's verified environment.
The serial monitor turns printed device URLs into IoT-gateway links —
but only when the sketch printed a full http:// URL. That matched the
Arduino idiom and missed MicroPython's: `print("Open:",
wlan.ifconfig()[0])` emits a bare "192.168.4.15", which rendered as
plain text. The address is unreachable from the host by design (it only
exists inside the emulated network), so exactly the users who just
gained real WiFi were handed an IP with no way to open it.
The scheme is now optional; a negative lookahead keeps longer
dotted strings (192.168.4.15.99) from half-matching. ifconfig() tuples
linkify every same-subnet address they contain — all of them route to
the same gateway root, so the extra links are harmless.
Follow-up to the #262 fix. Handing MicroPython the real driver exposed a
population the stub had been quietly carrying: sketches that connect to
an SSID that simply does not exist in the emulated radio. The AP tables
(QEMU esp32_wifi_ap.c and the esp32*js engines — same four networks in
both) associate by MAC/channel, so an unknown SSID scans to nothing and
`while not isconnected():` spins forever. Most 100-days gallery examples
ship their author's home SSID, so "real driver, no shim" would have
frozen them on the connect loop.
So when a NIC is attached the prelude now injects a thin proxy around
the REAL network module: connect() to any SSID outside the emulated set
is redirected to Velxio-GUEST (announced on serial, so nobody debugs a
connection they didn't make); known SSIDs pass through untouched; every
other attribute delegates to the native module. Result: made-up-SSID
sketches get genuine DHCP/DNS/TCP through SLIRP instead of the old fake
answers, and the reporter's PICSimLabWifi repro is never rewritten.
Wrapper semantics (rewrite, passthrough, module-attr delegation, and the
`from network import WLAN` form) are exercised against an instrumented
fake module; both generated preludes are syntax-checked.
The metadata auto-scan sweeps every wokwi-elements board into the
registry, and boards Velxio does not emulate surface as component cards
that promise support we don't have. Filtered in the picker, not deleted
from the metadata: four saved projects already contain the element and
must keep rendering.
Reported in #262: on an emulated ESP32, MicroPython's WLAN.scan() always
returned [], ifconfig() reported 10.0.2.15/10.0.2.2/10.0.2.3, and
outbound sockets raised EHOSTUNREACH — while Arduino WiFi.h on the same
board and container scanned, connected on 192.168.4.x and completed real
HTTP requests. Two independent faults, both needed for the failure.
1. The MicroPython prelude injected a stub `network` module into
sys.modules unconditionally, so user code never reached the firmware
driver. The stub's hardcoded ifconfig() happens to be QEMU's SLIRP
defaults, which is why the symptom read so convincingly as a routing
bug.
2. hasWifi survived a language switch. It is a property of the compiled
sketch, set only by arduino-cli, but setBoardLanguageMode kept it — so
a board compiled once as Arduino carried that verdict into a later
MicroPython run. The source-scanning fallback only fires when hasWifi
is undefined, so it never got a chance, and the backend attaches the
`-nic` device only when wifi_enabled is true.
The stub is NOT removed, which is where this departs from the patch in
the issue. It exists for a reason the report didn't have: without a NIC,
`network.WLAN(STA_IF)` hangs forever waiting on peripheral status bits
QEMU never sets, tripping the FreeRTOS watchdog after ~26s. Deleting it
would trade a fake-but-working network for a hung board. It is now
conditional — real driver when a NIC is attached, stub when none is —
so both paths are honest.
Also kept: the ntptime and urequests stubs, which the issue's diff would
have dropped along with `network` (it removed the whole prelude block).
Those back 29 call sites in the 100-days gallery examples, which have no
emulated internet to reach regardless of the NIC.
The detector is now one shared function instead of two copies that could
disagree — the stub decision and the -nic decision MUST match. Folded in
`from network import WLAN`, which matched neither previous pattern: such
a sketch was judged WiFi-less and hung on the missing peripheral. The
existing tests re-implemented the detection inline, so they only ever
proved that copy self-consistent; the new ones call the shipped function.
The Arduino section listed only Uno and Mega — Nano and Nano ESP32
existed as first-class boards (kinds, FQBNs, examples) but could only be
reached through the gallery or the board dropdown. Same for the
ESP32-CAM, which now sits in the ESP32 section next to its DevKit
sibling. The camera board's starter is the webcam demo rather than a
blink: the board exists to show the sensor, and a bare LED sketch would
be a misleading first run.
Entering the editor could stack two overlays: the starter-template
dialog opened on mount, then four seconds later the "What's new" modal
landed on top of it. Two dimmed backdrops over each other, and the
smaller, *less* important surface in front — the z-indexes said it
outright, news 10000 against the starter's 9000.
The delay made it worse rather than gentler. Arriving after the user has
started reading the templates is the most disruptive moment available;
appearing instantly would at least have let them clear it before
engaging.
The rule this restores: a modal is for what BLOCKS, and an announcement
never blocks. News now slides into the corner as a toast that dims
nothing, steals no focus (role="status", polite), and retires by itself.
The full post is one click behind "Read more" — a modal the user asked
for is a categorically different thing from one thrown at them — and
stays reachable from Help ▸ What's new once the toast is gone.
Worth noting the audience argument too: the starter dialog only fires on
a PRISTINE visit, i.e. for someone brand new, and "what's new" is
meaningless without a baseline to compare against. Returning users, the
ones it is actually written for, arrive with a project loaded and never
saw the collision.
Renamed NewsModal → NewsAnnouncer: it is not a modal by default any more,
and leaving the old name would have mislead the next reader.
Strings are new keys under `news.*`, filled in for all nine locales — the
previous modal had "What's new" and "Got it" hardcoded in English.
Toast sits at z-index 8000, deliberately BELOW the starter dialog, so if
the two ever coincide again the blocking task keeps the foreground.
The editor menubar's Account menu hosted only the shared `user-menu`
slot, so it had no way in or out of a session: the bottom-left dropdown
renders My projects / Sign in from its own markup, which this menubar
never sees. Signed-in users had no route to their saved work from the
editor, and anonymous ones had no way to sign in without leaving it.
Declares two account-scoped command ids and adds an `optional` item flag
that HIDES a row whose command is unregistered instead of the default
"render disabled". Absence here is not "temporarily unavailable" but
"does not apply": OSS has no accounts, and in pro exactly one of the two
is meaningful at a time — a greyed-out My projects would read as broken.
My projects sits third in File, at the head of the project group rather
than tacked onto the two "new …" rows: it opens saved work, which is
what Open/Save beneath it are for.
Labels reuse header.auth.{myProjects,signIn}, already translated in all
nine locales — no new strings.
The emulated BMI270 and battery gauge were faithful and inert: with nothing
driving them the IMU reported the board lying flat for the whole run and the
gauge reported the single voltage it was seeded with, so a sketch that reacts
to tilt or warns on low charge could not be exercised at all.
A Sensors popover on the canvas header supplies the missing half. Tilt is
entered as roll/pitch on a drag pad rather than three raw axes — what a user
means is "lean it left" — and gravity in the board's frame is that rotation
applied to (0, 0, 1) g, which is also why the vector stays at 1 g whatever the
attitude. Turning the board spins the gyro for as long as the drag lasts and
parks it back at zero shortly after, matching a real part: a held tilt reads no
rotation. Battery is a slider over the LiPo working range.
Gated per board by builtInImu / builtInBattery on the pro board def, the same
way the Mic toggle is gated, and each section renders only if its flag is set.
The microphone stream also learns to resample. The engine now tells the source
which rate the guest programmed, so a sketch recording at 8 kHz consumes two
captured samples per read instead of playing back at half speed.
Authors paste screenshot URLs without knowing the  syntax; GFM
autolinks them into plain <a> tags, so videos previewed but images did
not. An autolinked href ending in an image extension now renders as the
image itself; explicit [label](...png) links stay links. All images get
loading=lazy.
useProjectStore.currentExampleId — stamped by loadExample, dropped the
moment a real project (or a blank workspace) takes over. The compile
request and the run event carry it as example_id, analytics only, so
'which examples get compiled and run most' becomes answerable.
setComponents/setWires (project load, example load, .vlx/wokwi import,
clear) bump a counter so observers that diff components/wires between
updates can tell hydration from a user deliberately adding one part.
Canvas edits (addComponent/addWire) don't touch it.
Second half of the deep-link race: an overlay board kind added BEFORE
the overlay registers makes isEsp32Kind() false, so addBoard wires the
board as a generic AVR — and the parts on the canvas attach their I2C
device models to THAT simulator (measured live: the gesture's device
sat on an AVRSimulator while the C6 engine booted with an empty bus).
The overlay's rebuild then swapped simulatorMap but left the flat
`simulator` field stale, so DynamicComponent's [simulator] effect never
re-attached anything. Re-syncing the flat field when the rebuilt board
is the active one makes every part re-attach against the real shim —
sensors, displays, mic sources, the lot.
The pro overlay loads async, so a deep-linked example attaches its part
device models to the shim wired around the STOCK QEMU bridge — whose
attachSyncI2cDevice is a silent optional no-op — and only then does the
overlay's factory rebuild the board with the js-engine bridge. The
rebuild made a brand-new shim; the parts on the canvas hold the old one
in their attach closures and never re-attach. Result: the engine booted
with an EMPTY I2C bus and arduino's i2c-ng driver failed every
transaction with ESP_ERR_INVALID_STATE (the seated C6 gesture example —
measured live with the bus device table at Map(0)). Whether it broke
was a chunk-load race; the pro bundle's growth turned it into a sure
loss.
The shim now records every sync-attached device and a rebuilt shim
adopts its predecessor's — through addI2CDevice, so the new Delegating
bridge buffers them pre-connect and its start() replays them into the
engine after reset, as it always did for attaches it actually heard.
Several boards share one FQBN (the Pimoroni RP2350 trio all compile as
rpipico2), so FQBN-keyed metrics can't tell them apart. The compile
request and the run event now carry board_kind — analytics only, rides
into the metric hook's extra.
suppressOnlineOnlyAds(): overlay seam so the hosted build can silence
'available in the online editor' ad cards for items it manages — an
embargoed item must vanish, not advertise the site the user is on.
Pure OSS builds never call it; ads behave exactly as before.
The whenDefined recalc was necessary but not sufficient — measured on
staging, the example route loses BOTH ways:
- the element side: every settle timer can fire before the part is
findable in the DOM. The pinInfo-ready poll in DynamicComponent now
also re-derives wire endpoints the first time the part's pinInfo is
actually readable, and waits up to 10s (the 2s cap was the corner-
wire bug again on slow connections).
- the wire side: loadExample stores wires with zeroed endpoints BEHIND
awaits (library installs), potentially after every recalc has come
and gone. A canvas effect now spots endpoints still at (0,0) and
runs one deferred recalc; real coordinates land, the condition
clears, no loop.
Both Buy renderers (picker hover panel + Part Inspector) now append
utm_source=velxio&utm_medium=simulator&utm_campaign=datasheet with the
component id in utm_content, so vendors can attribute the referral.
trackProductPageClick fires the GA4 event and dispatches a
'velxio:product-page-click' CustomEvent — an overlay build can persist
the click server-side without this tree knowing about it.
The canvas re-derives wire endpoints on load-settle timers (100/300/
500ms), but an overlay-defined custom element can upgrade after the
last one — its chunk is large — and calculatePinPosition then finds no
pinInfo, so every wire to the part falls back to its corner and floats
there until something moves it (field report: the Grove gesture module
with all four Grove wires dangling on bare PCB). A customElements
.whenDefined hook now recalculates when the tag actually defines,
however late that is.
tailAfterStream sliced result.stdout at the live-buffer offset, but the
buffer interleaves stdout+stderr in arrival order while result.stdout is
stdout-only plus a joining newline — offsets never line up, so the flush
could start mid-line ('f/esptool_py && ...'). Instead, the poll loop now
emits one final onProgress(state:'done') with the completed buffer and
the existing delta logic flushes the tail perfectly aligned. tailAfterStream
is gone.
With the success-path reprint gone, the lines that land between the
final running-poll and job completion (esptool image creation, the
binary-size summary) silently vanished. tailAfterStream() appends
result.stdout past the streamed offset, noise-filtered, before the
structured analysis — skipped once the live buffer hits its 256 KB
tail-trim cap, where offsets stop lining up.
ESP-IDF builds sprayed the compilation console with configure chatter
(-- cmake status, git-metadata probes that 'fatal' on the synthesized
project tree, IDF component-manager NOTEs, Python env checks) and then
reprinted the entire stdout a second time when parseCompileResult ran
over the final result after the live stream had already shown it.
- isNoiseBuildLine(): pattern list for build-system chatter, applied to
the live stream deltas and to the final-result parsing.
- parseCompileResult(streamedLive): skips the stdout reprint on success;
on failure re-emits only error/warning lines so they still get the
red/yellow markers the plain live stream lacked.
Compiler errors, FAILED blocks, ninja [N/M] progress, esptool output and
binary-size summaries all still show. The full log stays available
server-side.
The chat reserves its width as padding-right on .app-container, but an
absolute inset-0 layer spans the padding box, so the picker's right
column and its scrollbar landed under the panel. The screen now gives
up the same width through the same CSS variable, with the same 0.12s
ease the padding uses, and falls back to zero in builds without the
overlay.
A modal over a pristine /editor dims an interface that is empty anyway
and offers a Cancel whose only destination is a dead workspace. The
picker now takes over the content area (StarterScreen): no veil, no
Cancel, the grid gets the room the 840px dialog never had, and the
examples gallery link is the secondary path out. The modal stays for
"New workspace" over existing work, where the replace-everything
warning and Cancel mean something — both shells share one card grid.
The details that make the takeover behave like a page: it sits at
z-index 90 (above the canvas' floating zoom pill, below the header's
stacking context so the menu dropdowns stay clickable; the fixed
account corner box is render-gated instead), the panes underneath are
inert while it is up, focus lands on the heading on mount and parks on
the workspace container on dismissal, and any path that fills the
workspace meanwhile — the File-menu modal, Open project…, a dropped
.vlx — dismisses it rather than letting its cards silently wipe the
loaded work. Full editor.newProject i18n for all nine locales (German
in Sie-form), heading outline h1→h2 / h3→h4, token focus ring, and
reduced-motion respected.
The component grid and the category filter now follow a fixed
maker-first category order (sensors, outputs/LEDs, displays, input,
motors, communication, electromech, other… then passive, analog, logic):
Velxio's audience reaches for a DHT22 or an LED far more often than a
bare transistor or a 74HC gate. Stable sort — order within a category is
untouched, and search results group the same way.
The account options that only lived in the bottom-left user button
(subscription, licenses, simulation history, replays, privacy) are now
reachable from the header too: a new Account menu hosts the pro items via
the SAME data-velxio-slot="user-menu" the corner dropdown uses — one
overlay renderer, two hosts, empty in OSS builds. Language moves from its
own top-level trigger into a section of that menu, so the menubar stays at
five triggers and frees header room for when the AI chat docks.
The canvas header runs out of room when the AI chat panel docks on the
right — the board selector clipped and the zoom cluster was squeezed out
entirely. The −/%/+ cluster now floats on the circuit canvas' bottom-right
corner (always free), with stopPropagation so a click never starts a pan.
Component picker: registry entries that ARE boards (the injected Raspberry
Pi family) no longer render as component cards — clicking one dropped a
dead 40-pin canvas prop that never boots (that is how "add a Pi 4" looked
like it placed a Pi 3). The boards row is the only path now, and it gains
Raspberry Pi Zero / 1 / 2 cards (Pi-3 illustration, PRO pill, same gate):
their QEMU profiles already existed in qemu_manager; the canvas renders
them through the Pi-3 element and BoardOnCanvas/store route them like any
Pi kind.
Part inspector: a board whose canvas node is NOT a registered custom
element (the Pi family's plain <img> wrapper) now clones the live node for
the preview instead of giving up — the Pi 3/4/5 pin map was completely
missing before. Wide boards with 40+ pins (Mega, Pi family) render
ROTATED 90° so their long pin rows become side columns with vertical room
(new PINS_ART_ROTATED_H box), and pinInspectorLayout splits a dual-line
header pair to OPPOSITE gutters the way printed pinout posters do — 40
interleaved labels never fit one gutter. Existing 18 layout tests pass.
esp-insights/esp-rainmaker print their version banner to stderr during the
CMake configure; without git metadata in the component tree it reads
"Project commit: HEAD-HASH-NOTFOUND" and the stderr classifier's default
painted it as a red error. Users read it as a failed build (it is not).
Classify "project commit:" lines as info.
The header spoke two languages: the ESP32-CAM/Sense board toggle says
"Camera" while component-owned webcams printed their registry label
("HuskyLens cam", "Gesture cam") — which read as a different control.
The button now says "Camera" everywhere; the component identity stays in
the tooltip, where it disambiguates when several cameras coexist.
Cards drop to a 178px grid (dialog 840px) with tighter type so more
starters fit per row; the Blank card's plus glyph goes accent-blue at
64px. Arduino Mega (mega-blink) joins the Arduino section next to the
Uno. Recaptured xiao-rp2040-blink.webp now that the board art is
silk-screened "XIAO-RP2040" (was "XIAO-ESP32-C3").
Boards with a camera surface their webcam state in the header
(CameraToggle); components that ARE cameras — vision sensors whose
element captures the webcam itself — had no header presence, so users
who learned "the header icon says my webcam is in use" read its absence
as a broken feature. A tiny registry seam lets any component register
its camera (label, live/error/off, reason, toggle); the header renders
one CameraToggle-styled button per entry and nothing when none.
The starter cards now carry the same circuit thumbnails the examples
gallery uses (ExampleThumbnail → /examples-thumbs/<id>.webp with the
CircuitPreview SVG fallback): boards with a Blink example reuse its thumb,
the rest get freshly captured starter-<kind>.webp shots in the same folder
(XIAO S3/C3, Netduino 2, Pi 4/5; plus the missing xiao-esp32c6-blink and
xiao-rp2040-blink example thumbs).
The ESP32 section is now one card per chip generation with the Seeed XIAO
variant preferred (DevKit V1 / XIAO S3 / XIAO C3 / XIAO C6), and XIAO
RP2040 joins the Raspberry Pi section — replacing the previous
every-variant list and the separate XIAO section.
Fixes: a pristine /editor visit clears the hardcoded Uno starter BEFORE
showing the dialog (empty canvas behind; cancel now leaves a blank
workspace), and clearing the last board re-points the editor at a
nonexistent group so Monaco no longer keeps showing the deleted board's
sketch (removeBoard only re-points when another board remains).
New NewProjectDialog: a bare /editor visit (and the New workspace button)
offers a blank workspace or a ready-to-run Blink starter per board family
instead of silently dropping the user into the hardcoded Uno + LED starter.
Boards with a gallery Blink example load it fully wired; the rest get a
fresh board with the on-board-LED sketch. Pro-gated boards carry the PRO
pill and go through the boardGateDecision seam. Shows once per page load;
en/es strings (the other locales fall back to English for now).
The word "Buy" on a solid button read as an ad inside a work dialog. The
link is really a pointer to the part's product page, so it now says that —
localized in all nine languages — with an external-link icon instead of a
shopping cart. Same URL, same placement, in both the part inspector and the
picker hover card.
The part inspector (right-click dialog) now lists the gallery examples that
use the part at the bottom of the Properties tab — matched by metadata id
against boardType/boardFilter/boards[].boardKind/components[].type, so it
works for components and boards alike, including overlay-registered ones
(re-derived via the pro-examples version subscription). Each link opens the
live editor (/example/:id) in a new tab. i18n key in all 9 locales.
The /examples board filter combo was a fixed list, so examples for
runtime-registered boards (XIAO, M5Stack, Raspberry Pi, ...) were reachable
only under "All". The gallery now appends a tab per board kind found in the
registered examples, labelled from BOARD_KIND_LABELS.
e-paper RAM persists between refreshes, but the decoder reset the accumulated
window union on every 0x20 MASTER_ACTIVATION. A PARTIAL refresh (BadgeOS redraws
only a strip when you navigate) then set a small window, so composeFrame emitted
just that strip, placed top-left with the rest black — reading as a 90°-rotated
screen with a black band down the side. Keep the union (and the greyscale flag)
across refreshes so it stays at the full-panel extent set by the first full
refresh; every frame now composes the whole persistent RAM and partial updates
land in place. Cleared only by a real RST (0x12). Paged full refreshes (GxEPD2)
re-cover the panel each frame so they are unchanged; the BadgeOS menu render is
byte-identical and all 23 decoder/epaper tests pass.
A panel driven with a Y-decrement entry mode through the rotation-1 transpose
(BadgeOS on the Badger 2350) rendered upside-down: its text read vertically
flipped. The transpose was calibrated against the standard Y-increment
(GxEPD2 / raw-SSD1680) path, where the source index maps to display row via
Wn-1-x; under Y-decrement the source axis ends up flipped, so map it straight
(x) to the display row for that case. Gated on the same yTopIsHigh signal
already used for the RAM read, so Y-increment panels are byte-for-byte
unchanged. Verified: the BadgeOS factory menu now renders upright ("BadgeOS"
title + app icons readable). 23 decoder/epaper tests still pass.
Panels that upload a custom waveform LUT (0x32) AND write both RAM planes
(0x24 + 0x26) in a frame drive 4-level greyscale: each pixel is 2 bits (one
per plane) composited by the custom LUT into 4 grey levels. Auto-detect this
from the command stream (custom LUT + red-plane written; never key off a panel
name) and expose an optional Frame.grey (0..3) alongside the existing 1-bit
`pixels` (kept as a level>=2 -> white projection so 1-bit and BWR consumers -
EPaperPart, GxEPD2 - are byte-identical). composeFrame builds a parallel grey
plane and rotates it through the same transpose as the palette plane.
The combo (bw<<1 | red) -> level map is [3,2,1,0] (white/light/dark/black):
bw is the dominant luminance bit (bw=0 -> light pair, bw=1 -> dark pair), red
refines one step within each half; verified against the captured menu's plane
populations. Exported DEFAULT_GREY_COMBO_TO_LEVEL + an optional greyComboToLevel
option (tunes ordering only, never forces greyscale on).
Standard SSD1680 paths (raw badge examples, GxEPD2 full refresh) load the OTP
LUT, never send 0x32, never write 0x26 -> unchanged. 23 unit tests pass
(ssd168x-decoder + epaper-part-integration, incl. new greyscale + no-regression
cases).
Panels that upload their own B/W waveform LUT via 0x32 (WRITE_LUT) instead of
loading the OTP/built-in waveform (0x22 with the 0x10 load bit) redefine the
generic SSD168x B/W convention: on the OTP waveform RAM bit 1 = white, but a
custom-waveform panel in our catalog inverts it (bit 1 = black). Auto-detect
the custom LUT from the command stream (never key off a panel name) and XOR the
B/W polarity; when set, compose from the 0x24 plane only (the 0x26 plane is the
differential "old" framebuffer, not a mono mirror). Every standard path we
drive (GxEPD2 full refresh, the raw SSD1680 badge examples) loads the OTP LUT
and never sends 0x32, so their polarity is unchanged.
Also fix descending RAM ranges (X-/Y-decrement entry mode, e.g. yrange=[263,0]):
normalize window bounds and the write-cursor wrap with min/max (verbatim [0] as
the low bound collapsed every scanline onto one row -> garbled/blank frame), and
read the visual-top row from the high RAM address under Y-decrement. Byte-
identical for ascending ranges. Removes the dead ramTarget field.
20/20 unit tests pass (ssd168x-decoder + epaper-part-integration).
The in-browser MicroPython run path required `sim instanceof RP2040Simulator`,
so an overlay-registered pro simulator (e.g. the RP2350's ARM MicroPython)
could never use it. Accept any simulator exposing loadMicroPython(files)
instead - generic plumbing, no board-specific reference; a sim without the
method is a no-op exactly as before. RP2040 behavior is unchanged.
Replaces the inline swap-the-action-bar confirmation (buttons jumped
around) with showConfirmDialog, same pattern as FileExplorer. While the
modal is open the dialog's Escape/click-outside close handlers stand
down. Boards keep their own remove-board modal via skipDeleteConfirm.
NewsMarkdown (shared renderer): YouTube links render as a thumbnail +
play badge that swaps to the youtube-nocookie iframe on click (nothing
loads from the player until the user opts in); images render inline;
all links open in a new tab. Product decision supersedes the alt-text
image stripping: posts embed screenshots/demos, and the README now
documents that embedded media loads in the viewer's browser.
Security review follow-ups (all LOW):
- proxy: negative cache on upstream failure (no outbound fetch per
request while velxio.dev is unreachable) and a 2MB body cap via
streaming read (httpx timeouts are per read op, not per body)
- NewsModal: OSS builds render markdown images as alt text so viewers'
browsers never contact remote hosts; pro cloud builds show them
Editor shows scheduled product-news posts as a markdown modal: max one
per day, oldest first, each post only ever once (marked seen at
delivery). OSS default source proxies velxio.dev's public feed through
the local backend (cached ~6h, anonymous, VELXIO_NEWS=off to disable)
with seen-state in localStorage; a pro overlay can register a
server-backed per-user source via lib/newsSource.ts.
File names may now carry '/' paths; the explorer renders each board group
as a collapsible folder tree (folders first, files in group order, CSS-var
indentation because .fe-file-item pins padding with !important). New-folder
buttons on the board header and per-folder hover actions (new file here,
new subfolder, delete with confirm when files are inside; a folder holding
every file of the group cannot be deleted - groups keep >= 1 file).
Model: names are the source of truth; only EMPTY folders are tracked
(folderGroups per group) so they survive until a file lands in them, then
materialise into the name prefix. Round-trips through .vlx (optional
folderGroups field, laxly validated), the auth stash draft, and
loadProjectState. Examples gain boards[].files so a single board can ship
a full multi-file tree (first entry = main sketch).
Backend: the arduino-cli sketch writer now creates subdirectories for
'/'-pathed names and REJECTS names that resolve outside the sketch dir
('..' traversal) - previously it crashed on the former and wrote outside
the tmp dir on the latter.
- examples-robot-desktop: Serial messages, comments and identifiers
(right/left servos, light threshold naming, START state) across the
embedded .ino and headers
- examples-100-days: PULL_DOWN explainer comment in the MicroPython menu day
On real hardware your code lives in flash, not on the microSD; a sketch
listing the card should see its data (csv, json, txt, wav...), not its
own source. buildProjectSdImage now skips .ino/.h/.hpp/.c/.cpp/.py from
the workspace auto-copy. Explicit uploads are exempt - an upload always
lands whatever its extension. Panel hint updated; tests cover both the
exclusion and the upload exemption (15 green).
- The live card file action now says Download (it was Save).
- Right-click opens the board inspector in EVERY mode: the contextmenu
handler moves from the drag overlay (hidden during simulation) to the
board wrapper, so the SD panel is reachable while the sketch runs and
the board's buttons stay interactive.
- Buy button in the inspector action bar goes solid brand blue #0071e3,
matching Velxio's solid-button language.
The SD panel only knew about uploads; everything the GUEST wrote to the
FAT card (photos, logs) stayed invisible inside the bridge. New
readFat16Image() parses the card image back (BPB-driven, real cluster
chains, VFAT long names, root dir - the inverse of buildFat16Image but
general enough for FatFs-written cards), and the panel gains a live
'Card contents' section reading the bridge's readSdImage() with a
per-file Save (download) button and a Refresh. Round-trip covered in
fat-image.test.ts (16 green).
Real webcams hit the 23000-byte bound, but the S3 esp32-camera build
allocates width*height/5 = 15360 bytes for a QVGA JPEG frame buffer and
stops copying one 1 KiB DMA half-buffer short of it, so oversized frames
lost their tail - including the EOI marker cam_hal scans for (the NO-EOI
storm on staging; the small canvas-fake frames masked it). The bounded
encoder now takes a budget (14000 for the Sense, default 23000 for the
QEMU ESP32-CAM path unchanged), the downscale fallback re-runs its own
quality ladder, and a frame that cannot fit is skipped instead of sent
truncated.
The toggle's attention border reused the .velxio-ants class name, which
is ALSO the canvas selection outline whose ::after is position:absolute
- on the non-positioned button it anchored to the toolbar and drew a
marching-ant line across its full width. Renamed the button variant to
.velxio-btn-ants. The ants also showed while the simulation was stopped;
now they only run when the sketch is running and the camera is off (the
only moment the button is actually asking for a click).
New canvas-header Mic toggle, shown for boards whose ProBoardDef declares
builtInMicrophone (their bridge implements setMicrophoneSource). Capture
runs at the AudioContext's native rate, is decimated to 16 kHz and ring-
buffered (2 s, drop-oldest on overflow, silence on underflow - the engine
paces pulls in simulated cycles, up to 4x real time during boot boost).
No auto-start: with the toggle off the bridge's 440 Hz test tone keeps
mic sketches alive, so taking the user's microphone stays an explicit
click. The source is re-applied on every run start to survive bridge
rebuilds.
The Camera button was hard-gated to the esp32-cam board kind. The Sense now
runs its camera through the S3 engine's LCD_CAM model, fed by the same
useWebcamFrames -> sendCameraFrame path, so the toggle shows for it as well.
Three-part fix for the library-contamination class of ESP32 compile
failures (a user's project kept pulling unrelated libraries because 79%
of projects compile with an empty manifest, forcing scan-all resolution
over ~1000 shared libraries):
1. Name-affinity ranking in _find_library_for_header: the provider whose
name matches the header stem wins (exact normalized match > esp32
arch declaration > contains-stem, alphabetical only as tie-break).
Previously first-alphabetical won, so any stray library shipping a
generic header (Servo.h has 6 providers) could hijack the build.
2. Manifest auto-migration: scan-all compiles now report the libraries
the build really used (manifest_incomplete +
manifest_suggested_libraries on the compile result); the editor folds
single-candidate suggestions into the board's declared manifest after
a green build, so the NEXT compile runs scoped. One green build = one
migrated project; empty-manifest scan-all behaviour is untouched.
3. Install-declares: the Wokwi import library modal records successful
installs in the active board's manifest, and .vlx export/import now
round-trips board.libraries.
Tests: test_espidf_library_ranking.py (9) + library-manifest.test.ts (19).
A ProBoardDef can declare builtInSdCsPin, and the store already built a FAT
card from the project files for it - but there was no way to put YOUR files
on that card: the upload panel only existed for the microsd-card component
and for parts with metadata.sdSlot, and boards have no properties bag.
Boards now carry sdFiles (same shape the SD panel persists everywhere else):
- BoardInstance.sdFiles, consumed by the store's Run path (card component
still wins when one is on the canvas);
- the board inspector shows the SD Card panel whenever the board kind
declares builtInSdCsPin, and routes the panel's onChange to updateBoard;
- .vlx round-trips it (serialisableBoard + payload type), and gallery
examples can pre-load the slot via ExampleBoard.sdFiles, applied by
loadExample the way the panel would.
First user: the XIAO ESP32S3 Sense (CS=GPIO21), whose board def and example
land in the pro overlay.
- Rotate/Delete (and the board actions) moved OUT of the left column into a
bar across the bottom of the dialog, so they are in the same place on both
tabs. Buy joins them, right-aligned: it used to be the last thing in the
datasheet body, which meant scrolling that pane to the end to reach it, and
it did not exist at all on the Properties tab.
- The datasheet scrolled sideways because the doc tables have a nowrap first
column (the pin name) and wide pinouts pushed past the pane. The dialog is
wider (720px, still clamped to the viewport so it cannot run off the right
edge) and the doc now wraps: fixed table layout, wrapping first column,
pre-wrap on code blocks, overflow-x hidden.
Switching Properties <-> Datasheet resized the whole dialog: each tab sized
to its own content, so a short property list shrank it and a long datasheet
grew it. The tab pane is now a fixed 360px (capped at 46vh) and each tab
scrolls inside it, so the dialog holds still. The mobile full-sheet keeps
flowing as one column.
Rotate and Delete were outline buttons; the brand kit says interactive
surfaces are solid accent blue (--blue-600 #0071e3, hover --blue-500) and
destructive ones solid danger red (--red-500 #ff453a), both with white text.
They use the app's own tokens rather than hardcoded hex.
The preview effect still depended on componentMetadata BY IDENTITY. For
components that is stable (the registry hands back the same object), but for
BOARDS the canvas builds the metadata inline per render, so every parent
re-render - which a pointer moving over the canvas causes - tore the preview
element down and rebuilt it. The dialog visibly resized and snapped back.
It now keys on a digest of the metadata (id, tagName, defaults) and reads the
object through a ref, joining propsKey and pinsKey which were fixed the same
way earlier. Nothing rebuilds unless something real changed.
91 of the 156 catalogue parts have neither an authored doc nor a metadata
description, so the Datasheet tab rendered nothing but tag chips and read as
broken. It now states plainly that no datasheet is written yet, and points at
the pin map, which IS the useful content for those parts. The picker hover
card gets the same line, since both render one body.
The Arduino Uno came out wrong: 18 pins on the top header, 13 on the bottom,
and SIX x values shared between the two. The column detector accepted any two
pads sharing an x, so those pairs were read as columns and most of the board
was thrown into the side gutters with leader lines fanning across the art.
A column now needs three pads AND small gaps between them (no more than 40%
of the body), which is what a real header looks like; rows get the same guard
on x. The Uno lands as two headers, top and bottom, with no side gutters at
all - covered by a test using its real 31-pin table.
Three things from using it:
- The pin map is why the dialog gets opened, so hiding it behind a checkbox
meant every visit started with a click. Pins are always drawn now and the
toggle is gone (with its translation key).
- The dialog sat at z-index 1300 and the pro agent chat panel docks over the
canvas at 8000, so on a wide layout the dialog opened UNDERNEATH the chat -
invisible, on the very area the chat covers. It now sits at 8500: above the
chat, still below the component picker.
- On a 32-pin board a name in the gutter could not be matched to a pad by
eye. Hovering (or focusing) either the label or the dot now lights the
whole run - label, leader line and pad together.
Right-clicking a board opened a small bespoke menu (Board Options... / Flash
to real board / Remove board) with its styling inline, while components got
the inspector. Boards now open the SAME dialog: the live board art with every
pin labelled at its real position, and an actions column that carries Board
Options and Flash instead of Rotate (boards do not rotate), with the delete
button reading "Remove board" and the wire count moved into the confirmation.
The dialog grew four optional props to make that possible without a second
implementation: extraActions, deleteLabel/deleteHint, and
previewTagName/previewAttributes - boards select their art through a
board-kind ATTRIBUTE rather than a property, so the preview needs to set it.
Also adds the boardOptions and flashToBoard strings to the nine locales: the
old menu hardcoded them in English, so those two items never translated.
205 lines of inline-styled menu are gone.
The ReSpeaker's left side carries 13 labels: at the minimum spacing that is
208px against a 190px body, so the column ran past both ends and the first
and last labels were cut off by the preview's clip. The gutters now grow to
whatever the labels actually occupy - the box follows the content.
Three things the dialog got wrong in use:
1. Missing pins. Classification was nearest-edge with an "interior" bucket,
and interior pins printed no label - only a dot with a tooltip. The
ReSpeaker Lite showed it: its XIAO socket is two INSET columns (x=50.5 and
126.5 on a 178-wide body) plus two breakout columns, so most of its pins
were called interior and the part looked like it was missing them. The
classifier now finds the LINES first - pins sharing an x are a column,
pins sharing a y a row - assigns each line to the side of the body it sits
on however far inset it is, and joins label to dot with a leader. Only a
lone pad falls back to nearest-edge. Every pin gets a printed label; that
is now the contract, covered by a ReSpeaker test with its real table.
2. The panel was cut off on the Datasheet tab until some unrelated event
re-rendered it. The datasheet loads asynchronously, so the one-shot
measure placed the dialog while it was still short and it then grew off
screen. A ResizeObserver repositions on any size change, and the tab body
caps its own height so long markdown scrolls inside the tab.
3. Flicker when the pointer left and re-entered. The preview effect depended
on componentProperties and pinInfo by identity - both are rebuilt on every
parent render (pinInfo is a getter) - so the element was torn down and
remounted constantly. It now depends on stable digests of them.
An SSD1306 has 8 pins along a 240px header. Horizontal labels need ~36px
each = 288px, so they overflowed the art box and rendered outside the dialog,
over the header and the canvas. Top/bottom labels are now vertical text - what
printed pinout diagrams do - which needs only the side spacing, and the gutter
grows to fit. The preview also clips, so nothing can escape again.
The right-click dialog was a 250px column: every pin as a text row (an ESP32
means 30 rows of scrolling), a few editors, Rotate/Delete. The picker's info
card (datasheet, brand, Buy) was a separate surface you could only reach by
hovering the catalogue. One dialog now serves both:
- ~560px, two panes: live preview + actions on the left, Properties/Datasheet
tabs on the right. The Datasheet tab IS the picker card's body -
ComponentInfoPanel was split into an embeddable ComponentInfoBody (+
useComponentDoc, and its .cip-* styles moved to their own stylesheet) so
both surfaces render one implementation.
- "Show pins" (off by default): the preview is the REAL web component,
mounted and scaled, with pin markers at their true pinInfo positions and
labels flanking the side each pin lives on. pinInspectorLayout is pure
geometry - nearest-edge classification, per-side label stacking with a
minimum spacing and leader lines when nudged, interior pins as
dot+tooltip - driven only by pinInfo plus the measured element size, so
every part and board, present or future, works with no per-part data.
Dots are tinted by the pin's declared signal (i2c/spi/power/...).
- Clicking a pin keeps the old contract (onPinSelect -> handlePinClick), so
wires start with the same undo, colors and running-state gating.
- The two open gestures finally agree on coordinates: right-click always
passed viewport coords while touch passed canvas-local ones; the dialog is
now portaled to body in viewport space and the touch site converts.
- Keybind capture, the SD Card panel, the two-step delete, Escape and
click-outside all migrate unchanged. Mobile keeps the full-sheet layout.
Geometry covered by pin-inspector-layout.test.ts with coordinate tables
copied verbatim from the shipped parts (ESP32 two-column board, LED, an
interior-pin case).
The "SD Card" upload panel in the property dialog was keyed to one component
id, microsd-card, so a part that CARRIES a slot of its own (the Seeed Round
Display shield) had a working card electrically but no way to put files on
it - the user saw the slot mount and could never feed it.
New metadata flag sdSlot: the dialog shows the same panel for any part that
declares it, persisting uploads as properties.sdFiles exactly like the
standalone card. The part's simulation is responsible for reading them when
it builds its card image.
Two independent defects, both visible as "the NTC reports the wrong
temperature" (issue #233).
1. The part built its divider against a hard-coded 5 V rail, while the SPICE
path used the board's real rail. They only agreed on AVR. On a 3.3 V board
the injected node sat above the ADC's full scale: the slider at 25 C read
~1.4 C, and every slider value below ~11 C saturated to the same number, so
-40, 0 and 10 C were indistinguishable. The rail now comes from the board
(analogRailVolts), matching setAdcVoltage's own AVR/RP2040/ESP32 split.
2. The divider convention was corrected in 608c2538 (VCC -> R_pull -> OUT ->
R_NTC -> GND) but data/examples.ts was not updated with it, so three of the
four bundled NTC sketches still decoded the OTHER topology. Their readings
came out mirrored about 25 C: the uno-ntc example printed -3.42 C with the
slider at 60 C - the exact symptom dd22bcfe had recorded as the bug. Fixed
in uno-ntc, pico-ntc and attiny85-ntc-sensor; examples-circuits.ts was
already right.
The sibling analog sensors (gas, flame, heart-beat, sound) map their sliders
0..1023 onto the same hard-coded 5 V and will saturate the same way on 3.3 V
boards. Left alone here: that is not what #233 reports, and each one needs its
examples re-checked before changing.
Stage 1 arms a \r at banner+800ms to flush QEMU's held ">>> " prompt, and
stage 2 arms Ctrl-A at prompt+200ms. Nothing kept the first from firing
after the second: if the prompt ever arrives on its own within 600ms, the
\r lands inside the pasted source, and MicroPython reads a lone \r as a
newline - it cuts a source line in half with no diagnostic of its own.
Here that is still latent; the in-browser JS engines, which deliver serial
per byte, hit it on every single run.
Three generic seams, none naming any board:
The pin tracer gains a socket hop: a component that declares boardSocket
with a board actually seated on it resolves a pad to the SAME-NAMED pin
of that board — seating IS the connection, like a XIAO pushed into a
shield header or a HAT on the 40-pin. Until now a seated shield's
buttons and LEDs were dead unless the user drew wires the real stack
does not have. Wires keep working exactly as before for every other
host (Uno, Mega, Pi, STM32, ...).
setMicrophoneSource now RETURNS whether a bridge actually took the
source, so a part can state that this host has no I2S instead of
pretending to stream into a void — capability reported, never invented.
createNeopixelDecoder is exported: boards are not the only things
carrying an addressable LED, and a part with one on board needs the
same decode rather than a drifting copy.
Deterministic repro (emulation-gaps F4): after pinMode(2, INPUT_PULLUP)
with a correctly-wired button-to-GND, all 8 setup()-time digitalReads
and the first two loop() passes returned 0 — the input register only
got its level from the first SPICE solve (~400 ms). That window is what
fired phantom emergency-stop latches and auto-started state machines in
audited sessions (and an unwired INPUT_PULLUP pin on the qemu bridges
never got driven at all: no net in pinNetMap, connector skips it, guest
read 0 forever).
Fix: PinManager.onPullChange fires on pull transitions; AVRSimulator
seeds its port input to the resting level instantly (real silicon does
this in ns), and makePinPullHandler does the same for the qemu-bridge
boards via the shim's setPinState. Sourced nets are still overridden by
the very next solve, so the 'mis-wired button still works' regression
guarded by the June work cannot return.
Audited circuits (2026-07) passed pre-flight with zero findings while being
electrically dead or mis-supplied: a battery with one pole wired, a MOSFET
switching a rail nothing powers, a 12V-coil relay fed from 5V, and VCC pins
tied together with no source. Three new graph-based rules (no solve needed,
so they fire even when ngspice cannot converge; all non-blocking warnings):
- unpowered-net: power-input pins (VCC/VIN/V+/COIL+/rated supply pins) and
whole conduction regions that no battery, power supply, or board pin
reaches. Ground and source-negative nets do not bridge power; MOSFET/BJT
conduct only through their channel; a relay coil is isolated from its
contacts; custom chips and boards are self-powered.
- no-return-path: a source with a single pole wired, or whose + side never
reconnects to its - side (return analysis joins all pins, so voltage-driven
gates/bases are not false positives).
- voltage-mismatch: relay coil_voltage vs the nominal supply on the coil
nets (region fallback for coils fed through a switch/transistor): below
the 60% pull-in threshold it never actuates, above 1.5x it burns out.
verifyFromStore now also verifies circuits whose only source is a
power-supply component. Gallery sweep extended to fail on the new codes:
zero findings across all 228 wired examples.
DS3231 (I2C 0x68):
- New velxio-ds3231 Web Component (4-pin module: GND/VCC/SDA/SCL) with
pinInfo per CLAUDE.md 6a; registered in elements-register + main.tsx.
- Catalog entry in scripts/component-overrides.json (_customComponents)
mirrored into components-metadata.json exactly as the generator emits it
(verified by cloning wokwi-elements and running generate:metadata: zero drift).
- The existing VirtualDS3231 device sim (DS1307-compatible time regs
0x00-0x06 + control 0x0E / status 0x0F / temperature 0x11-0x12 at 0.25 C
steps) is now user-reachable from the picker; the AVR/RP2040 attach path
gains live temperature updates via the SensorControlPanel (new ds3231
slider in sensorControlConfig).
GPS NEO-6M (UART talker, 9600 baud):
- New velxio-gps-neo6m Web Component (VCC/RX/TX/GND, pulsing PPS LED).
- New part sim GpsParts.ts: emits a valid GPGGA+GPRMC cycle per second
(correct XOR checksums, ddmm.mmmmm coords, UTC clock advancing 1 s/cycle)
with lat/lng/altitude/speed configurable via property dialog and live
via a new SensorControlPanel entry. Defaults: Madrid 40.4168 N 3.7038 W.
- Injection routes, chosen by classifying the wired board pin:
1) hardware UART RX -> new uniform sim.feedUart(uart, data) seam
(AVR USART0, RP2040 uart0/1 via rp2040js feedByte, ESP32 uart0/2 and
STM32 USART1/2 via their bridge shims); byte feed is paced in 8-byte
wall-clock chunks so 32-byte RX FIFOs never overflow;
2) any other digital pin on a cycle-accurate sim -> real 8N1 bit-banged
waveform via schedulePinChange, so SoftwareSerial decodes it;
3) feedUart rejection (e.g. Mega USART1-3, not modelled by avr8js)
degrades permanently to the bit-banged path.
- Interconnect already probed sim.feedUart; implementing it also upgrades
cross-board UART byte shortcuts for RP2040 uart1.
Tests: new gps-neo6m.test.ts (16 tests: NMEA builders, byte injection on
Uno RX0 / ESP32 RX2, Mega RX1 fallback, waveform decode back to $GPGGA,
live position updates, PPS pulse) + 3 new ds3231 AVR-path tests in
protocol-parts.test.ts. Full frontend suite: 2294 passed, 2 pre-existing
Galaksija Z80 timeouts that pass in isolation. npx tsc --noEmit clean.
Lets metrics overlays distinguish agent-triggered compiles from manual
ones (the AI assistant's compiles were previously invisible in project
counters). Loose optional field — omitted means manual.
The STM32 branch of collectPinStates deliberately skipped outputs from
the netlist — a workaround from when pinNameToArduinoPin couldn't map
'PC13' at all. With the mapping unified, emit digital outputs like every
other board so wired LEDs light from the solve (emulation-gaps F3).
Adds the missing BOARD_PIN_GROUPS entries for the STM32 family (3.3V
logic, suffixed GND/3V3 silks) so sources stamp at the right voltage.
Three parallel half-implementations of the pin-name mapping each broke a
different board family (2026-07 emulation-gaps audit):
- collectPinStates.pinNameToArduinoPin returned -1 for STM32 'PC13' (no
V source stamped: LED dark with correct firmware) and for nano-esp32
'D2'/'A0' (no pull resistor stamped for INPUT_PULLUP buttons).
- connectDigitalInputsToMcu.gpioFromPinName only knew digits/GPIO/GP, so
labeled pins were never driven from the solve (buttons stuck LOW).
- connectAnalogInputsToMcu's ADC_PIN_MAP used 'GPIO32'-style lookup keys
that never matched the real bare-number wire pin names, so the
SPICE->ADC path skipped every esp32-family pin; its per-kind GPIO
converters also mapped nano-esp32 A-pins with the AVR convention.
All three now delegate to utils/boardPinMapping.boardPinToNumber (with
the previous behavior as fallback for unknown names). Also adds the
ESP32-C3 branch to the store's adcChannelForPin (GPIO0-5 -> CH0-5,
verified against the qemu SARADC channel layout).
David Montero Crespo