v0.0.37

0.0.37

• (JA) 設定を core（oep-spec core §13、9fc6ad9 / c4fbd6e）に合わせた。oep_client.config（oep.probe.config）を無くし、
  oep_client.settings を足した:
  • fn 0 の get / set / unset / save / state / network。値は（fn、項目番号、key）で運び、host には（カテゴリ、平らな名前、値、出どころ）で見せる。
  • 設定のファイル（docs/oep-settings-file.ja.md）の書き出しと入れ直し（export、plan_import、apply_import）。secret は読まない。
  • oep config を oep settings（show / items / set / unset / save / state / network / export / import）に置き換えた。
  • 仮想ベンチは fn 0 の設定（各持ち主の項目、固定・既定の値、名前での保存）を持つ。共有ベクタの設定の場合と settings_file.json を通す。
  • 線の名前の探し方（find_line）は、出どころによらず全部の channel.{}.label から探す（firmware の label も設定の固定の値）。
• (JA) libusb1 経由の HID（hidapi がない環境の経路）で、カーネルの HID ドライバを外して interface を claim してから、
  レポート記述子を読むようにした。今までは claim の前に読んでいて、Linux の usbfs に LIBUSB_ERROR_IO で断られていた
  （RP2 の HID は interface 3、2026-10-22）。OEP の記述子でなければ interface を戻し、ドライバを付け直す。
• (JA) CaptureDrops に dropped_bytes を足した。ストリームが落としたバイト数の合計で、理由を問わない（写す経路で区画を捨てた
  分も含む）。oep-probe-arduino e08687c 以降。それより前の形では None。
• (JA) USB（vendor bulk）の既定を UsbProcessStream にした（POSIX のみ）。
  • wireskein の測定: 負荷 14 の host で、P4X の 40 MB/s・30 秒を取った。thread の版は 6 回中 3 回で欠損があり、process の
    版は 3 回とも欠損 0 だった。
  • OEP_USB_STREAM=thread で、今までどおり UsbAsyncStream（このプロセスのスレッド）を使う。Windows は pipe を fd で
    渡せないので、今までどおり。
  • 子プロセスが動かない（起動できない、準備の前に終わった、時間切れ）ときは、警告を出して UsbAsyncStream に戻す。機器が
    無いという答えはそのまま返す。
  • 開くのに、子プロセスを起こす分だけ時間がかかる（約 0.6 秒）。
• (JA) CaptureDrops に spill_peak と spill_bytes を足した。P4 のファーム 826eee0 からの、ストリームの DMA リングの後ろの
  待避 FIFO（PSRAM、8 MiB）の最大使用量と大きさ。それより前のファームの形では None。
• (JA) UsbAsyncStream の既定を 32 KiB × 480 本にした（前は 64 KiB × 128）。
  • probe は各転送を短いパケットで終えるので、URB の大きさによらず 1 本に 1 フレーム（40 MB/s の P4X で約 19 KB）しか入らない。
    host が溜められるのは「本数 × 1 フレーム」になる（64 KiB × 128 は約 2.4 MB、40 MB/s で 60 ms）。wireskein の測定による。
  • 480 × 32 KiB は 15 MiB で、usbfs_memory_mb の既定 16 に収まる。usbfs が途中で断ったら、そこまでの本数で続ける
    （1 本も出せなければ例外）。
  • open_usb_host(urb_size=, depth=) で選べる。UsbProcessStream は、このプロセスの URB_SIZE / DEPTH を引き継ぐ。
• (JA) UsbProcessStream: UsbAsyncStream を別のプロセス（python -m oep_client.usb_stream）で動かす。形は UsbAsyncStream と同じ
  （read、in_waiting、write、reset_input_buffer、close、stats）。
  • IN の転送の受け取りと出し直しは、そのプロセスの event のスレッドと GIL で行う。host の側のスレッドが GIL を長く持っても
    （numpy、大きな bytes の結合など）、転送は止まらない。読まれていない分は、そのプロセスに溜まる。
  • データはパイプで、write と stats は socket pair で受け渡す。multiprocessing の spawn は使わない（呼び出し側の main を
    もう一度走らせるため）。
  • 環境変数 OEP_USB_STREAM=process で、open_host の USB がこれを使う（既定は今までどおり UsbAsyncStream）。
  • wireskein の切り分けを受けた。負荷 14 のとき、event のスレッドが最大 6 秒止まり、40 MB/s の P4X で欠損が出ていた。
    実機では、まだ確かめていない。
• (JA) UsbAsyncStream: 戻った IN の転送は、データを写したらすぐ出し直し、ロック（read() と共有）はその後に取るようにした。
  前はロックを取ってから出し直していたので、read() がロックを持つ間は転送が戻らなかった。stats() を足した（callbacks、
  inflight_min = callback の時点で出ていた転送の最少、gap_max_s = callback の間隔の最大、buffered_max、bytes、urb_size、
  depth）。open() / コンストラクタで urb_size と depth を選べる（既定は URB_SIZE × DEPTH = 64 KiB × 128）。
  wireskein の切り分け（負荷 14 で 40 MB/s に欠損。event のスレッドが時々数百 ms から数秒止まる）を受けた。
• (JA) CaptureGroup.stream(link, tracks, seconds=, nbytes=, into=) -> {fn: Received}: ストリーミングのトラックを集めた
  capture-group で、1 本の経路に混ざって届く push をトラックごと（fn ごと）の Received に分けて集める。seq、generation、gap、
  segment_info の扱いは LogicCapture.stream() と同じ（その内側を _collect() に切り出した）。nbytes は全トラックが届くまで待つ。
  CaptureGroup.finish() は各トラックの finish() を呼ぶ。wireskein の依頼。
• (JA) Wire.scan: 1 回の要求に入れる組を、255 までかつ経路の max_frame に収まる数にした。前は 255 組を詰めていて、
  max_frame 1024 の経路で候補が多いと（rp2350-pins の 812 組）1031 バイトの要求を送っていた（仮想ベンチはそれを受けていた）。JS への移植で見つかった。

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

Full Changelog: v0.0.36...v0.0.37