Cricket browser programming plan

Yes: Cricket can plausibly be programmed and tested from a computer browser.
Use Chrome or Edge, a qualified SerialUPDI adapter, and approved firmware files.
An existing open-source browser programmer already lists ATtiny3217 as tested.
People still listen, feel the motor, and measure current with a meter.
Start in the assembly’s Test & program tab; phones view progress and results.
Cricket does not need the Mac Universal Tester for this proposed workflow.

Status: proposal — research and planning only; no implementation or bench validation.

Recommendation: qualify and vendor WebUPDI’s TypeScript programmer, then add the smallest app integration. Keep compilation outside the browser. First prove one released .hex → flash → readback verify → saved serial/result. Do not translate the Python wrapper or write a new UPDI engine.

Numbered owner decisions — recommendations awaiting decisions

Approve a 1–2 day feasibility slice on one known-good Cricket 008 and one identified adapter/computer. A successful flash is programming evidence, not a complete production test.
Support Chrome/Edge on Windows, macOS and Linux, plus Chrome on ChromeOS after qualification; keep phones view-only. Firefox desktop is a later qualification option, not technically impossible.
Name the exact shipping source commit, image and approver. Reconcile the old checkout with September 25–October 4 firmware work before approving bytes for use.
Approve manual actuator checks and meter readings initially; Engineering defines current limits, required charging checks and the final shipping state.
Confirm board revision, adapter chip/wiring/power, build and serial assignment point. Reuse existing ERP/evidence/label services; no new serial counter or results database.

Scope and inspected evidence

This replaces only Cricket’s Mac/Universal Tester assumption in app-test-program-tab-plan. Keep that plan’s assembly/build/unit views, release provenance, results ownership and rework rules. A simple qualified adapter/cable and meter suffice initially; do not require a Universal Tester controller, fixture EEPROM or its unrelated rollout gate for Cricket. Cricket still needs its own physical acceptance.

Read cricket-product, embeddedera-app, company-operating-system-strategy, shared engineering rules and the app-entry memory. Every task starts in Home; reuse existing engines and add only shop-specific glue. Future implementation follows the sandbox, app UI and release gates.

Inspected read-only Cricket checkout, commit 9cae8a7 dated 2026-09-16: product.yml, firmware 008 README/Makefile, tools/build_flash.py, docs/test-report.md, docs/pinout.md, actuator/production sources, Firmware/serial_terminal.py, STM32 configuration and CI workflow.

product.yml maps Cricket 008 to ATtiny3217; product is prototype, board is marked shipping, and IPNs are null. These flags do not establish an approved firmware release or ERP identity.
build_flash.py invokes Make/AVR-GCC, then avrdude serialupdi, device t3217, flash write and explicit verify. Python is orchestration; avrdude contains the programming protocol. Even --build-only currently resolves avrdude first.
The 008 build is a plain Makefile using tool binaries under .platformio/packages; the PlatformIO atmelmegaavr context is not a browser dependency. The inspected CI builds KiCad/fab outputs, not released firmware.
Outputs are build/cricket_008.hex, build/actuator_test.hex and build/deep_sleep_test.hex. Builds clean that directory; collect each artifact before building the next. HEX excludes EEPROM.
Snapshot normal firmware uses a 30-second bench interval and 20 MHz definitions. Its test report describes an earlier 30-minute board image and says the twelve-pattern update was not flashed. Neither proves today’s shipping behavior.
The newer product log reports 10 MHz, a 45-minute mean, one-hour arming delay, EEPROM modes and flash_test.py with self-test/readback/ships-asleep checks. That script is absent here; retrieve and review its exact newer revision during implementation.

ATtiny3217 is tinyAVR 1-series, not 2-series. Both it and representative 2-series parts use the NVM v0 path relevant here; do not select a device by family name alone. Microchip family documentation, WebUPDI tested targets.

Browser support, checked 2026-10-04

Computer/browser	Proposed support
Windows/macOS/Linux: Chrome or Edge	Program after adapter/driver qualification
ChromeOS: Chrome	Program after Chromebook/adapter qualification
Android: Chrome	View-only shop policy initially
iOS Safari and usual iOS browsers	View-only; no Web Serial
macOS Safari; Firefox Android	View-only; no Web Serial
Firefox desktop 151+	API exists; defer shop qualification

Chrome documents desktop Web Serial on Windows, macOS, Linux and ChromeOS; Edge follows Chromium support. It requires HTTPS (localhost is a development exception), a click/tap to request a port, and permission for the selected device. Previously granted ports can be listed; access can be revoked or blocked by administrator policy. Chrome guide, compatibility data.

Correction to “Firefox none”: Firefox 151 added desktop Web Serial with a site-permission add-on prompt. Safari/iOS remain unsupported. Keep Chrome/Edge as the initial supported shop workflow because API availability alone does not qualify UPDI timing. Mozilla announcement.

Android USB status: current compatibility data lists broader support from Chrome 148; Chrome 138–147 was Bluetooth RFCOMM-only. Chromium’s rollout announcement targeted M149 and requires the newer Android Serial API on a limited device set. Thus USB serial is conditional, not universally absent or universally available. Test actual OS/device/port support before any expansion. Compatibility data, Chromium rollout conditions.

Older Android configurations may use WebUSB plus a compatible serial polyfill, restricted to accessible USB interfaces; that is a separate transport/driver project and not part of phase 1. ChromeOS uses Chrome, not an assumed native Edge installation. Chrome polyfill guidance.

Cloudflare Access is compatible in principle: authenticate to the existing HTTPS app, then the browser talks directly to the local adapter. Access does not tunnel UPDI bytes or grant serial permission. Use a same-origin panel, allow serial in Permissions Policy, and avoid cross-origin iframe restrictions. Reauthentication must preserve attempt state. This is an architectural inference, to verify in the real gated app. Web Serial requirements.

USB-serial drivers are still required

Windows: CH340 uses WCH CH341SER; CP2102 uses Silicon Labs CP210x VCP; FTDI uses FTDI VCP/CDM. Windows may install them automatically; otherwise use the signed vendor package. A browser cannot install a missing driver.
macOS: common CH340/FTDI IDs may already bind to an Apple driver; otherwise use the matching vendor VCP. CP2102 commonly needs Silicon Labs VCP. Check OS/Apple-silicon compatibility and system-extension approval; do not layer competing drivers blindly.
Linux: normal kernels provide ch341, cp210x and ftdi_sio. Port permissions, often dialout/udev, still apply; packaged-browser confinement and another process holding the port can block access.
ChromeOS: these three driver families are present in ChromiumOS kernel configuration. Normally no downloaded desktop driver is needed; actual Chromebook kernel, USB IDs and enterprise policy still require checking.
Android/iOS: installing a Windows/macOS VCP does not add browser support. Android needs compatible OS/device support or a WebUSB driver implementation; iOS remains outside programming scope.

Driver sources: WCH Windows, WCH guide from adapter vendor Adafruit, Silicon Labs, FTDI VCP, Apple/FTDI interaction, ChromiumOS driver configuration.

Existing programmer options, before custom code

A — WebUPDI: recommended first trial. MIT TypeScript port of Microchip’s pymcuprog SerialUPDI code. Explicitly tested with ATtiny416, ATtiny3217 and ATtiny3226, all NVM v0. Supports HEX/binary, device ID detection, flash/EEPROM/user-row and erase/unlock. It is a small application with reusable modules, not an established supported SDK. Project.

Maintenance evidence is modest: nine commits displayed, not archived; GitHub’s topic listing reports an update on May 3, 2026. Exact latest commit/date could not be retrieved. Pin and review the source before vendoring; retain MIT and upstream notices. This is a fit candidate with limited maintenance evidence, not a mature-library claim. Activity listing.

Its UI source erases flash pages, writes and compares readback byte-for-byte, throwing on mismatch. No fuse UI was found; safe fuse programming remains an explicit source-review/bench gate. Extract structured success/failure from the engine—do not treat a log line or swallowed UI exception as success. No reliable throughput benchmark was found. Inspected programming flow.

Start qualification at 115200 baud; a product vendor reports that rate with CH340G and ATtiny3217. Measure erase/write/verify time on Cricket; higher rates come only after qualification. Upstream page-by-page erasure may dominate a small image. Vendor’s actual use.

Other JS leads were checked: FM Lab advertises browser UPDI/readback, but reusable licence, maintenance and 3217 coverage were not established. uartdebug has recent UPDI topic metadata, while the retrieved README documents a terminal; licence and UPDI completeness were not verified. Neither is presently a stronger reuse candidate. FM Lab, uartdebug.

B — avrdude WASM: exists, second choice only after a targeted check. Leaphy’s avrdude-webassembly and npm package exist, GPLv3; repository archived October 24, 2025, package 1.7.1 listed as about two years old. It demonstrates browser uploading, but retrieved evidence does not establish working SerialUPDI/3217/NVM v0, fuse operations or speed in that WASM build. Native avrdude capability is not proof of browser transport parity. Repository, package.

If revisited, verify serialupdi is compiled in and baud/framing/break/echo/drain behavior survives the web backend; prove fuse read/write and flash verify on hardware. Budget C/Emscripten maintenance and GPL distribution compliance. Retain native avrdude as the engineering recovery/reference tool regardless.

C — Pyodide + pymcuprog + WebSerial shim: plausible fallback, not drop-in. pymcuprog is MIT, vendor-maintained; PyPI’s latest observed release is June 3, 2025. Its native SerialUPDI path supplies tinyAVR device/NVM handling and read/write/verify/fuse operations; browser compatibility and timing still need proof. Pyodide is MPL-2.0. pymcuprog, Pyodide licence.

Exact-name searches for pyserial-webserial and pyodide-serial did not establish maintained packages. A real alternative is Apache-2.0 serialx, with WebSerial/Pyodide support and serialx-compat; its observed PyPI release is September 4, 2026. Confirm its browser backend implements the synchronous pyserial calls pymcuprog uses, including framing, baud changes, timeouts, breaks and buffer handling. serialx, release evidence.

Allow for Python-to-JS async bridging, dependency/import compatibility, startup download and USB latency; no end-to-end Cricket speed evidence was found. Pyodide cannot simply run this wrapper’s native Make/avr-gcc/avrdude subprocesses. A Python WebSerial demo proves transport, not unchanged programmer compatibility. Pyodide constraints, PyScript transport demonstration.

D — our own port: last resort. megaTinyCore prog.py is already a Python adaptation around pymcuprog, with OS/adapter-specific timing work; no better maintained JS port of it was established than WebUPDI’s direct pymcuprog port. Prefer contributing a bounded fix to WebUPDI. megaTinyCore’s SerialUPDI account.

Planning estimate for a restricted 3217/NVM v0 engine: roughly 1,000–2,500 lines plus tests/integration, not a measured count. Work includes serial half-duplex echo, break/sync, UPDI keys/reset/status, addressing/repeats, NVM busy/page operations, HEX parsing, fuse policy, verify and recovery. Budget 8–15 extra engineering days and renewed hardware qualification. Reuse permissively licensed Microchip code if needed; implement no other MCU families initially.

What the browser test actually does

Open assembly → Test & program → Program & test (browser). Select the existing build and scan/reserve the unit serial. Display board revision, release and adapter/power instructions; preview then confirm programming.
Connect the adapter through the browser chooser. Read MCU identity and approved fuse expectations; block wrong identity or unknown hardware compatibility. First slice uses a preconfigured board and does not write fuses.
Flash and verify the released actuator image. Release programming/reset so it runs once. The inspected sequence is 12 motor patterns, then 1/2/3 kHz tones, then permanent sleep. Show twelve pattern checkboxes and three tone checkboxes, each initially unchecked; allow Fail/Not observed. An on-screen timeline is guidance, not measured execution.
Have the operator feel all patterns and hear all tones. Missed sequence means an explicit controlled replay/reset, with the attempt retained. Hearing tones establishes audibility, not calibrated frequency or sound pressure; sensation does not measure motor force.
Enter current manually with unit, meter identity/range, supply voltage and image/state. Measure production standby separately from optional --deep-sleep minimum-current diagnostics; one cannot substitute for the other. Record active current only with an appropriate measurement method and approved limits.
Restore the approved production image last, read back and compare it, apply the reviewed EEPROM/default-state policy, and check the specified shipping behavior. Never finish with actuator/deep-sleep firmware or release on flash PASS alone.
Save every attempt and failed/skipped step. Final PASS requires all required evidence, production-image verification and confirmed result delivery. Reuse Retest/Quarantine and the existing receipt/finished-label gates.

Serial readback: Firmware/serial_terminal.py belongs to the older STM32G0B1 USB CDC firmware. Firmware 008 has no UART print/command implementation in this snapshot; its USB plug is not a programming/data console. UPDI is not a transparent UART terminal. Do not promise browser logs merely because the repository contains a Python terminal.

The newer note’s SRAM/EEPROM readback over UPDI may provide self-test flags and battery readings once reviewed. UPDI entry/exit can reset/restart the program; avoid continuous polling during the one-shot test or current measurement. Suggested future firmware: a versioned self-test result block with build ID, status and ADC readings; or explicit self-test commands over UART if suitable pins and fixture wiring are available. These are suggestions only. Neither proves physical sound/vibration without sensors.

Later, a USB instrument with a documented protocol could feed readings through a second browser port. Qualify microamp resolution, burden voltage, pulse capture and power-path isolation first; an ordinary USB inline charging meter is not necessarily a battery standby-current meter. Charging LEDs, VBUS sensing and blue LED checks need separate approved steps; the actuator image alone does not test them.

App, firmware and record ownership

Put the panel in proposed #part/<part-pk>/test for assemblies configured with test method browser/UPDI. Add a bench station mode page reached from that panel/build, reusing the same workflow with large controls, scan-next-unit and pinned build/release. Station mode is a browser page, not a new native tester application or top-level management system.

Use the existing Tabler components, theme/Home link and Access identity. Phone layout remains readable at 375 px and shows progress/history; programming controls explain that a qualified computer is required. Station identity is an app registration plus adapter/profile selection; USB VID/PID identifies a chip family, not necessarily a unique adapter or Cricket unit.

Artifact path: Engineering builds on its qualified workstation first; later add a pinned AVR toolchain CI job in the Cricket repo. Keep C firmware and current build targets. Store reviewed .hex, SHA-256, source commit, toolchain/flags, target signature, board revisions, image role and fuse/EEPROM policy in a release manifest. Identify one approved production image and separate diagnostic images.

Proposed storage: versioned Cricket release assets, retained by hash in the existing authenticated artifact/evidence service; app backend serves exact bytes on the Home origin. Verify the retention/upload path during phase 1. Do not rely on expiring CI job artifacts, mutable latest, or expose repository tokens to browsers. A local build can be released with the same provenance; CI is not a prerequisite for the first board.

The browser checks the artifact hash and HEX bounds before erase; UPDI verification compares programmed bytes afterward. These checks answer different questions. A checksum alone does not authorize a release: the authenticated manifest must bind approved bytes to the selected product/build. Builds keep their release snapshot; later defaults do not rewrite history.

Results: reuse InvenTree PartTestTemplate and per-stock-item test results, as in the tab plan. Required steps might include identity/fuses, actuator observations, standby current, production program/verify and shipping state. Preserve individual observations and image hashes in detailed attempt evidence; link summaries and attachments from the serial’s ERP record. Templates, results/API support.

Browser → same-origin authenticated app endpoint → existing tester event journal/API → idempotent InvenTree results. Keep ERP credentials and station-service secrets server-side. Reuse permanent attempt/event IDs, operator, stock/serial, build, stage, firmware/workflow hashes, adapter profile, measurements and timestamps. Existing API stages/build selection need deliberate Cricket mapping; do not pretend Cricket is a coated Cow board.

Use a small IndexedDB outbox for interrupted uploads, with “saved locally / server accepted / ERP confirmed” states. Require online serial reservation and a server attempt record before starting initially. After browser/storage loss, reconcile the unfinished attempt; never infer PASS or allocate a replacement serial automatically. Authentication expiry or loss of network must not cause automatic reflashing.

Reuse the existing central serial allocation and Brother board-serial/Zebra bag-label flow and print services. Bind the serial before testing so failures retain identity; use an existing serialized stock item or the existing pending-case mapping until ERP creation. Board identification labels may precede testing; finished-product labels follow accepted results/disposition. Reprints retain serial and history; no browser USB printer driver project. Confirm Cricket’s label dimensions and fit.

Phases and estimates

Focused engineering days for one implementer with review; board access, owner decisions and electrical redesign waiting time are extra. These replace Cricket’s station implementation estimate, not add to an unchanged Universal Tester plan.

One-board feasibility, 1–2 days. Reconcile a released image; from an app-linked workflow, use pinned WebUPDI to identify, flash and verify one safely powered, already-configured board. Manually attach hash/log/result to an existing sandbox serial/test record. Compare native avrdude readback. Exit: reproducible browser programming evidence, timings and recorded result; no production completion claim.
Small integrated panel, 2–4 days. Vendor reviewed modules, serve approved artifacts, add identity/hash guards, preview/confirm, explicit failures and authenticated result submission. Exit: one release/adapter/computer works in the sandbox; wrong MCU/image, denied permission and disconnected cable cannot yield PASS.
Guided Cricket bench flow, 3–5 days. Station mode, actuator checks, manual current, production restore, fuse/EEPROM handling, serial/label reuse and outbox recovery. Include actual newer self-test source review. Exit: known-good/failure/retest/quarantine boards and duplicate submission preserve evidence and stock identity.
Qualification and release, 2–4 days. Pin CI/release provenance, test supported OS/adapter combinations, cold-connect/replug, browser sleep/reload, Access expiry and ERP outage. Use app UI/release gates and update the applicable existing SOP during implementation. Exit: repeatable bench results and Engineering/Production acceptance.

Total: approximately 8–15 days if WebUPDI and existing service contracts fit. Start with phase 1 only. Fuse engine gaps, service stage generalization or an adapter change can expand this; do not promise throughput before measurement. Automated instruments and firmware changes are separate later scopes.

Risks and remaining questions

Known board power problem: the product note reports the current programmer puts 5.2 V onto the 008 battery header. Never attach it with the LiPo connected. Engineering must define safe power and isolation before the trial; software cannot fix it. The PA3/VBUS issue also needs disposition before charging tests.
Fuse safety: read first; compare an approved allowlist. Add writes only after testing on a spare/virgin device; never expose arbitrary fuse edits or disable UPDI. A locked/UPDI-disabled board may need separate HV recovery hardware; a USB-serial dongle cannot supply that automatically.
Adapter differences: CH340/CP2102/FTDI are not interchangeable qualification results. Confirm voltage, resistor/diode topology, echo, 8E2 framing, break generation and baud transitions; exclude jtag2updi unless separately supported. Check short cables and competing port users.
Timing and interruption: USB buffering, NVM busy time and browser scheduling affect speed/reliability. Use bounded timeouts and explicit retry attempts; cable removal, sleep or page closure during erase/write leaves an incomplete unit, never PASS.
Wrong firmware/state: reconcile old checkout/new log, oscillator fuses, EEPROM preservation and one-hour arming. Do not use an hour-long silence as proof of shipping-state correctness; define direct readback or a reviewed smoke-test method.
Open facts: actual board revision/quantity, fitted motor/cell, bench adapter model and OS, latest committed firmware, approved limits, release approver, ERP test templates and Cricket build/serial binding remain to confirm. Which charging checks are mandatory without the Universal Tester must be decided explicitly.

Research by the primary Codex session; no helper models ran. Capacity status returned missing data and a read-only helper route was unavailable under SOP-025. Only this proposal was written; the one-file instruction excludes sync, commits, memory updates, installs and implementation.

10-line summary

Browser programming is feasible enough for a one-board trial.
Reuse WebUPDI before considering a protocol port.
Keep the firmware build outside the browser.
Start with qualified desktop Chrome or Edge.
Keep phones view-only for this workflow.
Guide twelve motor checks and three audible tones.
Record current from a suitable meter initially.
Finish with approved production firmware and readback verify.
Reuse InvenTree serial results and existing label services.
Approve the 1–2 day feasibility slice before broader implementation.

Addendum 2026-10-04 (Claude) — the current work is on branch no-accelerometer, not main

main (9cae8a7, 2026-09-16) is stale; the owner's latest push is branch no-accelerometer (b688e2d, 2026-10-05) with cricket_firmware_008/tools/flash_test.py (+ test_flash_test.py). It already automates the per-board flow: signature check (1E 95 22) → fuse fix (OSCCFG=0x02; SYSCFG0 EESAVE=0, RSTPINCFG=01) → self-test image → after ~4 s read USERROW record (magic 0xB7: boot, idle/motor/piezo mV, temp) and evaluate (idle ≥ 4800 mV …) → release image → ships-asleep check (EEPROM byte 255 bit 7) → CSV log. So the browser flow is mostly automatic, not checkbox-driven. Implications for phase 1–3: the browser programmer must also read/write fuses, read USERROW and EEPROM (not only flash) — qualify WebUPDI for those memories first; port flash_test.py's pure logic (parse_record, fuse_fixes, evaluate, asleep_ok) to the app (small, covered by its existing tests) rather than running Python in the browser; keep the CSV fields as the ERP test-result fields. Merge/settle no-accelerometer before releasing firmware bytes.