v0.0.27

0.0.27

• (EN) tests/hw port_speed verdict follows the host guide §7.3.2: a one-at-a-time cell at a raised rate fails only when broken + lost ≥ 3 and its ratio is over max(2 × the boot-speed ratio of the same flow, 5 % OEP_HW_ERROR_MAX) - the absolute 1 % failed the CH340 jig on bursts the boot speed shows too. Results with the probe 5bafb92 (port_speed handshake per core §3.5, block length) on the ATOM, the V003 jig (SWIO) and the X035 jig (DFU, RVSWD): all pass.
• (JA) tests/hw の port_speed の判定を host 開発ガイド §7.3.2 に合わせた: 上げた速さの 1 つずつの条件で、broken + lost が 3 以上かつ割合が max(起動時の速さの同じ流し方の割合 × 2, 5 %（OEP_HW_ERROR_MAX）) を超えたときだけ落とす（絶対の 1 % は、起動時の速さにもある CH340 のまとまった落ちで治具を落としていた）。probe 5bafb92（core §3.5 の握手、block 長）での結果: ATOM、V003 治具（SWIO）、X035 治具（DFU、RVSWD）すべて pass。
• (EN) port_speed follows the host guide's reference procedure (oep-spec host-development-guide.ja.md §7; core §3.5 is the handshake). raise_speed(hst, candidates=(500000,), *, flows=None, verify=None, baseline=None, frames=16, verify_ms=None, idle_ms=3000, port=None, record=False) replaces the old rates, verify_bytes, verify_s, duplex_s. The minimal form (§7.2, the default; ~50 ms, no measurement): try -> switch to the requested baud -> settle 20 ms -> confirm (100 ms x3) -> commit. The full form (verify=True, or flows given; §7.3): a baseline at the boot speed per flow (this session's frames when 60+ and under 10 %, else 60 measured per flow, re-measured at n=1 when over 10 %), then per candidate every flows ("in"|"out"|"duplex", n; default all three at the most the link keeps) for frames (16) frames at max_frame-16, a flow failing on broken+lost >= 3 and a ratio over max(2x baseline, 5 %), re-run at n=1 (then n=1 is the link's cap), one failed flow failing the candidate. SpeedTrial now carries actual, switched, flows (FlowResult: flow, n, frames, broken, lost, kb_s, ratio, passed), n_cap, in_kb_s/out_kb_s/duplex_kb_s; SpeedReport adds verified, baseline, baseline_flows, step_downs (StepDown), skipped. In use: the frames of the last 3 s (none judged under 50) over max(2x baseline, 10 %) broken or lost step the link down (was 3 strikes in 5 s); a missed answer still falls back to the boot speed within port_speed_idle_max_ms + 1 s (a link error when no confirm comes, never back to the raised rate). The keepalive interval is set under half of idle_ms. set_baud switches to the requested baud and to the probe's answered baud only when the OS refuses it (obligation 6/2). oep speed keeps working and gains --candidates, --flows, --verify/--minimal, --frames, --no-record.
• (JA) port_speed を host 開発ガイドの参考手順に合わせた（oep-spec host-development-guide.ja.md §7。core §3.5 は握手だけ）。raise_speed(hst, candidates=(500000,), *, flows=None, verify=None, baseline=None, frames=16, verify_ms=None, idle_ms=3000, port=None, record=False) が旧 rates, verify_bytes, verify_s, duplex_s を置き換える。最小の形（§7.2、既定。約 50 ms、計測なし）: 試す → 要求した baud に切り替え → 20 ms → confirm（100 ms×3）→ 決める。完全な形（verify=True か flows を渡す。§7.3）: 起動時の速さの基準を流し方ごとに取り（このセッションの 60 フレーム以上かつ 10 % 未満、無ければ 60 フレーム。10 % 超は n=1 で測り直し）、候補ごとに flows（("in"|"out"|"duplex", n)。既定は link が出す最大で 3 つ）を frames（16）フレーム max_frame−16 で流し、壊れ+失われが 3 以上かつ割合が max(基準×2, 5 %) 超で流し方は通らず、n=1 で流し直し（通れば n=1 が上限）、1 つでも通らなければ候補は通らない。SpeedTrial は actual、switched、flows（FlowResult: flow, n, frames, broken, lost, kb_s, ratio, passed）、n_cap、in_kb_s/out_kb_s/duplex_kb_s を持つ。SpeedReport に verified、baseline、baseline_flows、step_downs（StepDown）、skipped を足した。使用中は直近 3 秒のフレーム（50 未満は判定しない）が max(基準×2, 10 %) 超で降りる（旧: 5 秒に 3 回）。応答が来ない要求は port_speed_idle_max_ms + 1 秒の内に起動時の速さへ戻る（confirm が通らなければリンクの失敗。上げた速さへは戻さない）。keepalive の間隔は idle_ms の半分未満にした。set_baud は要求した baud に切り替え、OS が断ったときだけ probe の応答の baud にする（義務 6/2）。oep speed は動いたまま --candidates、--flows、--verify/--minimal、--frames、--no-record を足した。
• (EN) port_speed record (host guide §7.4): speed_record.SpeedRecord keeps passed / failed rates per (port path, unit_id) in ~/.cache/oep-client/link-speed.json ($XDG_CACHE_HOME), 30-day expiry; raise_speed(record=True) (a bool, a path, or a SpeedRecord) reorders candidates (passed first, failed skipped -> report.skipped) and writes this run's outcomes and step-downs. On by default for the oep speed CLI, off for the library (open_host(..., record=) passes it through). A file that cannot be read or written is a cache miss, not an error (SpeedRecord.error).
• (JA) port_speed の記録（host ガイド §7.4）: speed_record.SpeedRecord は通った / 通らなかった速さを（口のパス、unit_id）ごとに ~/.cache/oep-client/link-speed.json（$XDG_CACHE_HOME）に 30 日残す。raise_speed(record=True)（真偽値・パス・SpeedRecord）は候補を並べ替え（通った速さを先頭、通らなかった速さは外す → report.skipped）、この実行の結果と降りた事実を書く。oep speed CLI は既定で ON、ライブラリは OFF（open_host(..., record=) で渡す）。読めない / 書けないファイルはキャッシュミスで、エラーにしない（SpeedRecord.error）。
• (EN) riscv-dm / arm-adi max_length (bytes) and max_words from describe (oep-if-debug §4.5 / §6): RiscvDm and ArmAdi take their block size from the declared max_length only, never (max_frame - 18) / 4 or the like - ch32_flash._block_size and arm.MemAp.chunk do too. A probe with block ops that declares no usable max_length raises riscv.NoMaxLength (the spec makes it mandatory there). The fake declares max_length = max_frame - 24 rounded to a word (so a read_block answer and a write_block request both fit): 40 at 64-byte frames (esp32-v003), 1000 at 1024 (the P4 / RP2350 profiles) - was a flat 1000 / 40. A block over max_length is now rejected unsupported with payload 0x00 (was malformed); an odd address stays malformed. A port_speed step above 2 is malformed (was unsupported), and a step that does not fit the port's state is unavailable cause 6.
• (JA) riscv-dm / arm-adi の max_length（byte）と max_words を describe から取る（oep-if-debug §4.5 / §6）: RiscvDm と ArmAdi は block の長さを宣言された max_length だけから決め、(max_frame - 18) / 4 などからは計算しない。ch32_flash._block_size と arm.MemAp.chunk も同じ。block op を持つのに使える max_length を宣言しない probe は riscv.NoMaxLength（spec で必須）。偽の probe は max_length = max_frame − 24 を語に丸めて宣言する（read_block の応答と write_block の要求がどちらも収まる）: 64 byte フレーム（esp32-v003）で 40、1024（P4 / RP2350）で 1000 ― 旧は一律 1000 / 40。max_length を超える block は payload 0x00 の rejected unsupported（旧 malformed）、奇数番地は malformed のまま。port_speed の step が 2 より大きいと malformed（旧 unsupported）、口の状態に合わない step は unavailable cause 6。
• (EN) The committed probe's self-revert condition 4 is now 3 broken candidates in a row with no good frame between (was 3 within a 1 s window); condition 2 (trying) counts a broken candidate only after the first good frame at the new speed arrives (the switch-over's leftovers do not count); idle_ms (condition 3) is not counted while a request runs. The fake and its tests follow.
• (JA) 決めた probe の自己復帰の条件 4 を「正常を挟まず壊れた候補 3 つ連続」にした（旧: 1 秒の窓に 3 つ）。条件 2（試し）は新しい速さで最初の正常フレームが来た後の壊れた候補だけ数える（切り替えの直後の残りは数えない）。idle_ms（条件 3）は要求の実行中は数えない。偽の probe とそのテストも追随。
• (EN) tests/hw on the bench's jigs (2026-10-02, with the bench's leave): V003 jig (ESP32-D0WD + CH340, CH32V003 over SWIO) and X035 jig (ESP32-P4 over DFU, CH32X035 over RVSWD) - flash, identity, config, wire (50 halt / read_block / resume loops, registers unchanged), gpio, uart, session pass on both; the CH340's port_speed cells fail the 1 % verdict now and then (bursty probe->host loss at every rate, oep-spec docs/link-measurements.ja.md §1.4). Fixes found by running there: one arduino-cli build path per profile (the shared sketch cache linked another profile's objects), the wire lookup asks list for oep.wire (a trailing dot matched nothing), the uart test runs on a UART the probe's settings already planned (a jig's plan) instead of failing to plan it again. The Pro Micro RP2350 run found a firmware fault (a UART plan on pins its UART cannot use froze the probe; fixed in oep-probe-arduino 654b06a).
• (JA) tests/hw を bench の治具で（2026-10-02、bench の了解のもと）: V003 治具（ESP32-D0WD + CH340、SWIO 越しの CH32V003）と X035 治具（DFU で焼く ESP32-P4、RVSWD 越しの CH32X035）。flash / identity / config / wire（halt → read_block → resume 50 往復、レジスタ不変）/ gpio / uart / session はどちらも pass。CH340 の port_speed は 1 % の判定にときどき掛かる（どの速さでも probe→host がまとまって落ちる。oep-spec docs/link-measurements.ja.md §1.4）。回して見つけた直し: arduino-cli の build path を profile ごとに分ける（共有の sketch cache が別 profile の object を link した）、線の検索は list に oep.wire を渡す（末尾の点では何も当たらない）、uart の試験は probe の設定が既に plan した UART（治具の plan）の上で行う（もう一度 plan して失敗しない）。Pro Micro RP2350 の一巡で firmware の不具合を見つけた（UART が使えないピンへの plan で probe が固まる。oep-probe-arduino 654b06a で修正）。
• (EN) Link: on a serial port (COBS framing) the answer bytes expected in flight are bounded by SerialLink.ANSWER_BURST_MAX (6 KiB; answer_burst per link, 0 = off) - at most 5 requests in flight for a 1024-byte frame. Linux cdc_acm silently lost 20-30 % of 8 x 1008-byte answers from an ESP32-P4's HS CDC, none below 8 KiB, and none when the same endpoint is read through libusb (oep-spec docs/link-measurements.ja.md §1.1, core §3.4). Not applied to vendor bulk / HID. cobs.frame_max(message_len). oep linktest --json flushes each line.
• (JA) link: シリアルの口（COBS）では、未解決の応答の見込み量を SerialLink.ANSWER_BURST_MAX（6 KiB。link ごとの answer_burst、0 で無し）に抑える。1024 B のフレームなら同時 5 まで。ESP32-P4 の HS CDC で 8 × 1008 B の応答を Linux の cdc_acm が 20〜30 % 黙って落とし、8 KiB 未満なら 0、同じエンドポイントを libusb で読めば 8 本でも 0 だった（oep-spec docs/link-measurements.ja.md §1.1、core §3.4）。vendor bulk / HID には掛けない。cobs.frame_max(message_len)。oep linktest --json は 1 行ずつ flush する。
• (EN) tests/hw: the pre-release hardware test of oep-spec docs/release-testing.ja.md (pytest, marker hw, skipped without OEP_HW_BOARDS). Per board: flash the firmware (a local build with OEP_PROBE_DIR, or a GitHub release with OEP_PROBE_VERSION, sha256 checked; OEP_HW_NOFLASH=1 tests what is on the board), then confirm / list / describe, probe.config set / get / save / state / unset with a disable item and a reboot, the wire (with OEP_HW_TARGET), fixture gpio and uart, port_speed through linktest.matrix (verdict: one at a time ≤ 1 % broken + lost), the session's lease / expired / resumed / force. Flashers: esptool (classic ESP32), USB DFU in pyusb (ESP32-P4), the 1200-baud touch and picotool (RP2040 / RP2350). Results in tests/hw/results/<board>-<firmware>-<client>.json. Run on an M5Stack ATOM with the 0.0.26 main build and release 0.0.25 (2026-10-01): everything passes but port_speed, where the ATOM's bridge (a CH552 posing as FTDI) loses 0-8 % of 496-byte answers one at a time at 115200 (COBS-broken frames) and 921600 gets no confirm while 1500000 and 500000 do.
• (JA) tests/hw: oep-spec docs/release-testing.ja.md のリリース前の実機試験（pytest、マーカー hw。OEP_HW_BOARDS が無ければ skip）。ボードごとに: firmware を焼き（OEP_PROBE_DIR でローカルのビルド、OEP_PROBE_VERSION で GitHub のリリース。sha256 を照合。OEP_HW_NOFLASH=1 は入っているものを試す）、confirm / list / describe、probe.config の set / get / save / state / unset（disable を含む）と再起動、線（OEP_HW_TARGET のとき）、fixture の gpio と uart、linktest.matrix による port_speed（判定: 1 つずつで broken + lost が 1 % 以下）、セッションの lease / expired / resumed / force。焼き方: esptool（classic ESP32）、pyusb の USB DFU（ESP32-P4）、1200 baud のタッチと picotool（RP2040 / RP2350）。結果は tests/hw/results/<board>-<firmware>-<client>.json。M5Stack ATOM で main の 0.0.26 ビルドとリリース 0.0.25 を回した（2026-10-01）: port_speed 以外は通る。ATOM の変換（CH552 の FTDI 互換）は 115200 で 1 つずつでも 496 バイトの答えの 0〜8 % を落とし（COBS の壊れたフレーム）、921600 は confirm が返らない（1500000 と 500000 は通る）。
• (EN) oep linktest and oep_client.linktest: measure a link under conditions the caller chooses - rates to switch to with port_speed (or the speed in force), patterns (in / out / duplex), in-flight counts, frame sizes, frames or seconds, the answer wait, the driver's low-latency mode - and count ok / broken / lost frames and KB/s per cell. No fixed numbers in the measurement. Found with it: an M5Stack ATOM's FTDI corrupts the probe's answer while the host is transmitting, at 115200 as at 1.5 Mbaud (5-9 % of pipelined frames), and is clean one request at a time (2026-10-01).
• (JA) oep linktest と oep_client.linktest: 呼ぶ側が条件を決めて線を測る。port_speed で切り替える速さ（または今の速さ）、流し方（in / out / duplex）、同時に出す要求の数、フレームの大きさ、回数か時間、答えの待ち、ドライバの low latency。条件ごとに ok / broken / lost と KB/s を数える。決め打ちの数値は持たない。これで分かったこと: M5Stack ATOM の FTDI は、host が送っている間に受けた probe の答えを壊す（115200 でも 1.5 Mbaud でも、重ねたフレームの 5〜9 %）。1 つずつなら壊れない（2026-10-01）。

Repository: https://github.com/Open-Embedded-Probe/oep-client-python

Full Changelog: v0.0.26...v0.0.27