v0.0.36

0.0.36

• (JA) 試験: segment_columns の試験は、numpy が無ければ飛ばす（numpy は任意の依存。numpy の無い CI で落ちていた）。
• (JA) CaptureGroup.trigger_caps() -> TriggerCaps | None: capture-group の describe の trigger_caps（§4.4、0x41）を読む（max_stages、
  max_terms、max_conds、cross_track、types、protocols、trigger_out_latency_ns。trigger_out が無ければ None）。takes(COND[...]) と
  kinds()（宣言された条件の型の名前）で、bind の前に頼めるかを確かめられる。宣言なしや知らない形では None（宣言は目安で、正しいのは
  bind の答え）。wireskein の依頼。P4X（5a61110）で level、edge、cross_up、cross_down と読めた。
• (JA) capture_blocks.segment_columns / LogicCapture.columns(data, samples): 形式 1 の区画を、ブロックを作らずに列で読む（numpy が要る）。
  raw のチャネルはビット列、events のチャネルは区画を通した刻み（EventColumn: quanta、levels、counts、start_level）。fallback の
  ブロックは、その標本から probe と同じ数え方で刻みに直す。検査は read_logic_blocks と同じ。ヘッダだけを Python で辿り、raw は
  （fallback の組、r）ごとにまとめて、events は区画の全行を一度に読む（wireskein の提案と試作。60 ブロックの区画で 54 → 10 ms）。
• (JA) 仮想ベンチ: 形式 0 / 4 とアナログの streaming も、1 回の tick で作るサンプルを BLOCKS_A_TICK までにした（形式 1 と同じ。作れる
  速さで遅れて流す）。前は経過した時間ぶんを一度に作ろうとして、tick が長引くほど次の tick が重くなり、1 MHz × 2 本でも 0.3 秒の
  あいだ push が 1 つも来ず、stop の応答に 12.8 秒かかっていた（wireskein の報告）。
• (JA) oep-spec e1d5495 に追従（registry とベクタを取り込み）。configure / query の応答の judge_latency_ns（§3.3）を
  Config.judge_latency_ns で読む（組の出来事の元の条件を判定するトラックの、出来事と知るまでの最大の時間。返さない probe は None）。
• (JA) UsbAsyncStream.DEPTH の既定を 32 から 128 にした（64 KiB × 128 = 8 MiB、40 MB/s で 200 ms ぶん）。P4X の 40 MHz・8 本の 30 秒で、
  32 では USB の受け取り側のときどきの止まり（URB の出し直しの遅れ、バス）で 0.2〜0.6 % を落とした。128 では wireskein の 2 回と
  こちらの 5 回（形式 0 を 4 回、形式 4 を 1 回）、すべて落としなし。
• (JA) LogicCapture.stream() の keepalive の間隔を、同じ into の呼びをまたいで数えるようにした。前は呼ぶたびに数え直していたので、
  0.2 秒ずつ刻んで呼ぶ host では keepalive が 1 度も出ず、30 秒の取得の途中で lease が切れていた（wireskein の報告）。
• (JA) capture.CaptureDrops.buffer_peak: Arduino の firmware の capture-drops に足された最後の u32（ストリームの溜め、P4 では PSRAM の
  DMA リングが、送られずに持っていた最大のバイト数）。前の形（30 B）は buffer_peak を None にして読む。
• (JA) oep-spec 569e86b（capture §3.3 stream_buffer）に追従。Config.stream_buffer と Config.tolerable_delay_s()（host が読みを止めて
  よい時間の目安。形式 1 / 2 は最悪の帯域を渡す）。仮想ベンチは streaming の応答で 1 MiB を返す。link.reader（"usb-async"、"usb-sync"、
  ほかは stream の型の名前）で、どちらの USB の読みかが分かる（wireskein の依頼。同期の読みでは host の揺れが probe の落としになる）。
• (JA) 名前付き拡張（core §2.2、tag 0x7F）を共通に読む: message.named_extensions(tlvs)、Tail.named()（名前 → data、同じ名前は最初）。
  キャプチャの Status.named。Arduino の firmware 独自の診断 capture.CaptureDrops（io.github.open-embedded-probe.capture-drops:
  落としの内訳、経路、stage の数、メモリ）を CaptureDrops.of(status) で読む（wireskein の依頼）。registry と vectors は oep-spec 0eb94f8。
• (JA) 受信: 呼び出し側の時間切れの時点で frame が途中まで届いていても、FramingLost にしない（届いた分を取っておいて次の呼び出しで続ける）。
  FramingLost は、frame の途中で受信が probe_frame_gap_ms 以上止まったときだけ。16 KiB の push が 20 ms の pump の境目にかかると「区切りが
  崩れた」とみなして同期をやり直し、その間の push を捨てていた（2026-10-20、P4X の形式 4）。
• (JA) capture_blocks.LogicBlock.start_levels: events のチャネル全部（fallback も含む）の、ブロックの直前のレベル（§1.3 start_level）。
  区画の境目の変化を、fallback のブロックでも数えられる（wireskein の依頼）。
• (JA) 仮想ベンチ: 形式 1 の streaming は、1 回の tick で作るサンプルを BLOCKS_A_TICK までにする（作れる速さで遅れて流す）。stop は作りかけの
  ブロックだけを閉じる。2 MHz × 4 本で、遅れを取り戻そうとして応答しなくなっていた（wireskein の報告）。
• (JA) 仮想ベンチの §4.4 を oep-spec e87b50b に合わせた（段の入り口の when、アーム前の最後のサンプルとの比較、決めた段のトラックの不確かさ）。
• (JA) oep-spec 8e7ca20 の capture に追従（第 1 波）。
  • 形式 1（ロジックのブロック、§1.3）: capture_blocks.read_logic_blocks で復号する。raw と fallback のチャネルはビット列（bytes）で、events の
    チャネルは (tick、level、count) で返す。numpy があれば、見出しだけを Python で読み、残りを numpy でまとめて読む。
    LogicCapture.configure(data_format=, events=, roles=, block_max=) で設定し、read_segment は区画の終わり（次の区画の position か
    write_pos）まで 1 回で読む。lc.blocks() で復号し、worst_bytes() で最悪の大きさを計算する。
  • 形式 4（試験の並び）: ストリームの position k のバイトが k & 0xFF になる。
  • trigger_opts（arm、rearm、when、hysteresis）は capture.TriggerOpts で設定する。既定は arm 1、when 0 で、前の版の「最初に見えた条件で立つ」は
    arm 0、when 1 で表す。
  • トリガの記録（§3.10）は lc.triggers() で読む。triggered の出来事は record、sample、uncertainty_ns も持つ。
  • 仮想ベンチ: P4 のロジックは形式 1（mode 1 / 2）と形式 4 を、アナログは形式 4 を宣言する。rearm 1 の repeat では区画の間も state 3 のまま
    待ち、status の flags bit2、区画の flags bit3 / bit0 を立てる。configure は実装した TLV だけを知っていて、ほかを critical なら unsupported で
    断る。capture-group の force は §4.4 を入れるまで ops から外す。
  • conformance: triggers と group の force を任意の op として扱い、bind の TLV が定義されていても通す。
  • 仮想ベンチの形式 1 は streaming にも対応する。ブロックは揃ってから送る。stop では短い最後のブロックを送る。区画の位置は、区画が始まるたびに
    記録した表から引く。購読が無い間に始まった区画は丸ごと捨てる。
  • capture-group §4.4 の出来事の元（trigger source）を入れた。
    • クライアント: capture.TriggerSource、Stage、Cond（level、edge、cross_up / cross_down、above / below、timer）で式を組み、
      CaptureGroup.bind(tracks, source) で送る（どれも critical）。CaptureGroup.force()、GroupStatus.trigger（fn、ns、uncertainty_ns）、
      group の triggered（trigger_fn、record、ns、uncertainty）。トラックは trigger=(LINKED, 0, 0) と自分の pretrigger で configure する。
    • 仮想ベンチ（P4 の group）: features bit 0 と trigger_caps を宣言し、force を持つ。持つものは、4 段 × 4 項 × 4 条件、トラックをまたぐ AND、
      count、within_ns、on_timeout 0 / 1、abort、arm。rearm 1、外部の入力、trigger_out、serial は持たない。
      • 判定は、項が見るトラックのうち最も速いもののサンプルで行う（時刻の来たサンプルだけを見る）。
      • 出来事では、各トラックが自分のサンプルで区画を切り、自分の triggered を送る。
      • linked のトラックを単独で start すると cause 6、trigger source の組に linked でないトラックを入れると cause 6。
  • 仮想ベンチの --logic-wave ROLE=SPEC（virtual_bench_capture.logic_wave）: ロジックの役割ごとに波形を選ぶ。counter、quiet[:LEVEL]、
    square:PERIOD、uart:BAUD[:TEXT]（8N1 の文字、文字の間はアイドル）。静かな線と UART のような線で、形式 1 の典型の帯域を測れる
    （§1.3 の例: 2110 B / ブロック、125 MHz で 64.4 MB/s。仕様の見積もりは 63.6 MB/s）。

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

Full Changelog: v0.0.34...v0.0.36