feat(web): Basicmicro MCP console (UART/CAN) + generic slcan CAN console

[finger563]

Description

Two new self-contained browser tools (auto-hosted + indexed at esp-cpp.github.io/espp/apps/ by the docs pipeline):

mcp_console.html — Basicmicro MCP Console

Test/configure MCP236/MCP266 (RoboClaw-family) controllers through either kind of USB converter:

• USB↔UART (packet serial): CRC16-CCITT with a load-time golden self-test, 0xFF-ACK write validation, reply-CRC verification seeded with sent addr+cmd, and the ≥15 ms quiet-resync recovery on any failure. Device info (firmware version / battery / temperature / signed currents / decoded status bits with a 32→16-bit auto-retry for older firmware), spring-to-zero duty sliders (keyboard-accessible zero buttons), strict-i32 speed commands, 5 Hz encoder polling with status-bit decode, encoder reset.
• USB↔CAN (slcan → CANopen/DS402): slcan bring-up with CR/BEL ack handling, NMT, expedited SDO client (index/sub-matched waiter, 24 decoded abort codes), heartbeat badge with staleness, CiA 402 statusword state machine + verified enable sequence, fault-reset/quick-stop, profile velocity + position (with new-setpoint pulse), identity/device-type/error-register, and an SDO object browser (15 preloaded standard objects + arbitrary typed access) — the tool for discovering the MCP's actual object dictionary, which Basicmicro doesn't publish.
• Always-visible STOP (duty 0/0 in UART mode, quick-stop controlword in CAN mode). Note: STOP runs through the serialized transaction chain (~worst-case a few hundred ms behind an in-flight poll) to keep request/reply pairing sound — the reasoning is documented in-file; hardware E-stop remains the real safety path.

can_console.html — CAN Bus Console (slcan)

Generic console for any slcan (LAWICEL) USB-CAN adapter: bitrate + open/close, strict TX composer (std/ext/RTR with 11/29-bit range checks, DLC/data consistency), multiple periodic-send slots, chronological log (pause keeps capturing for export), per-ID latest table with changed-byte highlighting + period estimates, include/exclude ID filters (values + ranges), adapter info panel.

Both follow the established console conventions: single-file/offline (no CDN), light/dark theme-aware, responsive, aria-labeled, promise-chain-serialized wire I/O, e.port-based unplug teardown, <title> + <meta name="description"> for the apps index.

Testing

• node --check passes on both extracted scripts; zero external resource loads; title+description present (verified independently).
• CRC implementation independently recomputed and matched (golden 0x31C3, real STOP packet CRC 0x9817).
• Headless-Chromium load shows clean init with in-page self-tests passing.
• Hardware validation against a real MCP over both converter types is the remaining gate (pairs with feat(basicmicro): MCP/RoboClaw packet-serial motor controller component #729/feat(canopen): lightweight CANopen client + DS402 drive helper #730).

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Adds two new offline, single-file browser consoles for interacting with CAN/slcan adapters and Basicmicro MCP motor controllers via the Web Serial API.

Changes:

• Introduces a generic slcan CAN bus console with TX composer, periodic sends, traffic log export, per-ID “latest” table, and RX filtering.
• Introduces a Basicmicro MCP console supporting both packet-serial (UART) and CANopen/DS402-over-slcan workflows, including safety STOP and SDO object browsing.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
components/twai/web/can_console.html	New generic slcan/Web Serial CAN console UI + protocol handling.
components/basicmicro/web/mcp_console.html	New MCP controller console supporting both UART packet-serial and CANopen/DS402-over-slcan.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

✅Static analysis result - no issues found! ✅

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

Suppressed comments (4)

components/twai/web/can_console.html:508

• String.prototype.substr is legacy/deprecated in JavaScript. Prefer slice(start, start + length) (or substring) to avoid relying on deprecated APIs.

      for (let i = 0; i < n; i++) out[i] = parseInt(compact.substr(i * 2, 2), 16);

components/twai/web/can_console.html:843

• String.prototype.substr is legacy/deprecated in JavaScript. Prefer slice(start, start + length) (or substring) to avoid relying on deprecated APIs.

        for (let i = 0; i < dlc; i++) data[i] = parseInt(dataStr.substr(i * 2, 2), 16);

components/twai/web/can_console.html:309

• The traffic log is expected to update frequently; aria-live=\"polite\" on a high-churn region can overwhelm screen readers and make the page difficult to use. Consider using aria-live=\"off\" (or role=\"log\" with carefully scoped aria-relevant=\"additions\") and relying on explicit user actions (Pause/Export) for assistive-tech consumption.

        <div id="log" aria-live="polite" aria-label="Chronological CAN traffic log"></div>

components/basicmicro/web/mcp_console.html:607

• Same concern as the CAN console: this log can update at high frequency (polling + traffic), and aria-live=\"polite\" may spam assistive technologies. Consider disabling live announcements (aria-live=\"off\") or using a more suitable pattern for logs (e.g., role=\"log\" + limited announcements) so screen reader users aren’t flooded.

        <div id="log" aria-live="polite" aria-label="Raw traffic log"></div>

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (5)

components/twai/web/can_console.html:842

• parseFrame()` accepts standard IDs up to 0xFFF (3 hex digits) and extended IDs up to 0xFFFFFFFF (8 hex digits), but classic CAN IDs are limited to 11-bit (<= 0x7FF) for standard and 29-bit (<= 0x1FFFFFFF) for extended. This can cause malformed/garbage tokens to be treated as legitimate frames and populate the log/table/filter incorrectly. Add an explicit range check after parsing (based on ext) and return null (or log an error) when the ID exceeds the spec limit.

    function parseFrame(tok) {
      const kind = tok[0];
      const ext = kind === "T" || kind === "R";
      const rtr = kind === "r" || kind === "R";
      const idLen = ext ? 8 : 3;
      if (tok.length < 1 + idLen + 1) return null;
      const idStr = tok.slice(1, 1 + idLen);
      const dlcCh = tok[1 + idLen];
      if (!/^[0-9a-fA-F]+$/.test(idStr) || !/^[0-8]$/.test(dlcCh)) return null;
      const id = parseInt(idStr, 16);
      const dlc = parseInt(dlcCh, 10);

components/twai/web/can_console.html:713

• When the adapter explicitly rejects the open command (okO === false), the UI is still switched into the "connected" state (enabling TX composer, periodic slots, adapter command buttons). Since channelOpen is false, actions will fail later with "Not connected / channel not open.", but the enabled controls make it easy to start timers/flows that will immediately error and spam the log. Consider keeping conn-gated controls disabled unless channelOpen is true, or switching back to disconnected UI on an O رفض (adapter refused open) while leaving the serial port open only if you have a specific reason to keep it open.

      setConnectedUI(true);
      if (okO === true) {
        channelOpen = true;
        setStatus("connected", "Open · " + kbit);
        logLine("sys", "CAN channel open at " + kbit + ".");
      } else if (okO === false) {
        channelOpen = false;
        setStatus("error", "Adapter refused O");
        logLine("err", "Adapter rejected the open command" + (okS === false ? " (bitrate was rejected too)" : "") +
          "; check the bitrate or power-cycle the adapter.");
      } else {

components/twai/web/can_console.html:587

• The on-screen counters (rxCount/txCount) appear to track only CAN frames (txCount increments in sendFrameLine; rxCount increments in onRxFrame), but logLine("tx"/"rx") is also used for slcan control commands/responses (e.g., sendCmd logs "tx" without updating txCount). This makes the displayed "rx/tx" stats inconsistent with what a user sees in the log. Either (a) move counting into logLine() (like mcp_console does) so all tx/rx log entries are counted, or (b) relabel the stats to explicitly say "frames" and keep command tokens out of the counters.

    function updateLogStats() {
      els.logStats.textContent = `rx ${rxCount} · tx ${txCount}`;
    }

components/twai/web/can_console.html:921

• The on-screen counters (rxCount/txCount) appear to track only CAN frames (txCount increments in sendFrameLine; rxCount increments in onRxFrame), but logLine("tx"/"rx") is also used for slcan control commands/responses (e.g., sendCmd logs "tx" without updating txCount). This makes the displayed "rx/tx" stats inconsistent with what a user sees in the log. Either (a) move counting into logLine() (like mcp_console does) so all tx/rx log entries are counted, or (b) relabel the stats to explicitly say "frames" and keep command tokens out of the counters.

        writer.write(encoder.encode(cmd + "\r")).then(() => {
          logLine("tx", cmd);
        }, (e) => {

components/basicmicro/web/mcp_console.html:1950

• When SDO form parsing fails, the UI displays the error text but does not mark the specific invalid field(s) with aria-invalid="true" (and readSdoForm always resets aria-invalid to false on success only). This reduces screen-reader feedback and misses the visual invalid styling you rely on elsewhere (e.g., transport node ID, motion fields). Set aria-invalid="true" on the specific field that failed parsing (index vs subindex vs type), and only clear it for that field once it validates.

    function readSdoForm() {
      const index = parseIndexStrict(els.sdoIndex.value);
      const sub = parseIntStrict(els.sdoSub.value, 0, 255, "subindex");
      const type = els.sdoType.value;
      if (!SDO_TYPES[type]) throw new Error("unknown type");
      els.sdoIndex.setAttribute("aria-invalid", "false");
      els.sdoSub.setAttribute("aria-invalid", "false");
      return { index, sub, type };
    }
    els.sdoReadBtn.addEventListener("click", async () => {
      els.sdoError.textContent = "";
      let form;
      try { form = readSdoForm(); }
      catch (e) { els.sdoError.textContent = e.message; return; }