From 5bba75d1e8662765cf07b1b92e2b952fbd33beac Mon Sep 17 00:00:00 2001 From: EwdErna Date: Sun, 20 Sep 2026 20:24:56 +0900 Subject: [PATCH] =?UTF-8?q?ELC:=20ELC=E3=83=AC=E3=82=A4=E3=83=A4=E3=83=BC?= =?UTF-8?q?=E3=81=AE=E5=88=9D=E7=89=88=E3=80=82=E3=83=94=E3=83=B3=E6=8F=90?= =?UTF-8?q?=E4=BE=9B=E8=80=85=E3=81=AB=E3=82=88=E3=82=8B=E9=85=8D=E7=B7=9A?= =?UTF-8?q?=E8=A1=A8=E7=8F=BE?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit muxを「ピンを増やす装置」として抽象化し、提供者が提供する論理ピンを キーの端子が指す形にした。直結もmux経由も同じ形になり、多段muxは 入れ子で表せる。 配線方式(マトリクス / direct / charlieplexing)は列挙せず、端子の 接続先の組み合わせとして表す。row / col は正本に含めない。 射程は配線のみとし、センサの品種・出力特性・キャリブレーションは 持たない。PCB設計の手前までというPHYの線に揃えた。 Journal: journal/2026-09-20-elc-pin-provider.md Journal: journal/2026-09-20-elc-scope.md Co-Authored-By: Claude Opus 5 --- ELCレイヤー.md | 146 +++++++++++++++++++++++++ journal/2026-09-20-elc-pin-provider.md | 52 +++++++++ journal/2026-09-20-elc-scope.md | 34 ++++++ 3 files changed, 232 insertions(+) create mode 100644 ELCレイヤー.md create mode 100644 journal/2026-09-20-elc-pin-provider.md create mode 100644 journal/2026-09-20-elc-scope.md diff --git a/ELCレイヤー.md b/ELCレイヤー.md new file mode 100644 index 0000000..d1101a3 --- /dev/null +++ b/ELCレイヤー.md @@ -0,0 +1,146 @@ +# ELCレイヤー + +## 概要 + +ELCレイヤーは、マイコンのピンと各キーの端子がどう対応するかを提供する。 + +扱うのは配線だけとする。読んだ値をどう解釈するか(アナログ値から押下深さを出す変換、 +キーごとのキャリブレーション)は持たない。キャリブレーションは実機ごとの実測値であって +設計データではなく、センサの品種はPCB設計ツール側の選択だからである。 + +## 構造 + +### ピンとピン提供者 + +ELCが扱う「ピン」は物理的なマイコンピンに限らない。**ピン提供者(provider)が提供する論理ピン**とする。 + +マルチプレクサ・シフトレジスタ・GPIOエキスパンダは、いずれも「少ないピンを多くのピンに増やす装置」である。 +これらを提供者として扱うと、キーの側からは直結もmux経由も同じ「ピンに繋がっている」だけになる。 + +提供者は、自分が消費する上位ピンを宣言する。上位ピンには別の提供者の論理ピンを書けるので、 +多段の接続は入れ子として表せる。分割キーボードの各半身は、それぞれ別の提供者として置く。 + +ピンの参照は `<提供者ID>.<ピン名>` の形とする。`VCC` と `GND` は電源レールを指す予約名で、提供者を持たない。 + +現時点で具体形を定めるのは、マイコンとアナログマルチプレクサの2種別。 +デジタル側でピンを増やす部品も提供者として扱うが、種別ごとの記述は必要になった時点で定める。 + +### キーの端子 + +キーは検出方式(detect)を持ち、検出方式ごとに端子の構成が決まる。各端子は接続先の論理ピンを持つ。 + +- 接点(contact): a, b の2端子。端子は無極性で、a と b に順序の意味はない +- アナログ(analog): out 1端子。加えて電源の vcc, gnd。ホールセンサがこれにあたる + +光学スイッチの端子構成は未定 [推測:P-1]。 + +### 配線トポロジを区分として持たない + +マトリクス・direct・charlieplexing を列挙して選ばせることはしない。 +これらは端子の接続先の組み合わせとして表れるものであって、設計者が選ぶ区分ではない。 + +- 両端子がそれぞれ別のマイコンピンを指す → マトリクスまたはcharlieplexing +- 片方の端子が電源レールを指す → direct +- out がマルチプレクサの論理ピンを指す → mux経由のアナログ読み + +row / col はELCの正本に含めない。charlieplexing で便宜的に行と列の形で書くことはあるが、 +それは表記の都合であって配線の事実ではない。QMKなどが要求する row / col は、出力時に割り当てる派生情報とする。 + +### ダイオード + +接点キーはダイオードの向きを持つ。向きは端子名で表す(`a-to-b` はアノードがa側)。省略時はダイオードなし。 + +### LEDの識別番号 + +LEDの番号はELCが持つ。設計者が恣意的に決めてよいが、決めた順序はそのまま配線の指示になるため、 +配線の情報として扱う。 + +チェーンごとに、データピンと、LEDの並びを持つ。並びの各要素はPHYのノードIDで、 +per-key LEDを載せたキーか、LEDの部品ノードを指す。並びの位置がそのLEDの番号になる。 +チェーンは複数持てる。 + +現時点で定めるのはチェーン方式(WS2812系)のみとする。ドライバICでアドレスを与える方式は未定。 + +### 他レイヤーへの参照 + +キーとLEDの参照には、PHYのノードIDをそのまま使う。ELCはIDXを参照しない。 + +### 持たないもの + +- センサの品種、出力特性、キャリブレーション値 +- フットプリント、部品の実配置、基板の層構成 +- キーの物理的な位置とサイズ(PHYが持つ) + +## 保存形式 + +```ts +type PinRef = string // "<提供者ID>.<ピン名>" | "VCC" | "GND" + +type Provider = + | { + id: string, + kind: "mcu", + part: string, // 品番。ピン名の解釈に使う + } + | { + id: string, + kind: "analog-mux", + channels: number, // 提供する論理ピン数。ピン名は "0".."channels-1" + select: PinRef[], // 選択ピン。下位ビットから順 + common: PinRef, // 共通ピン + enable?: PinRef, + } + +type KeyWiring = + | { + key: string, // PHYのキーID + detect: "contact", + terminals: { a: PinRef, b: PinRef }, // 無極性 + diode?: "a-to-b" | "b-to-a", // 省略時はダイオードなし + } + | { + key: string, + detect: "analog", + terminals: { out: PinRef, vcc: PinRef, gnd: PinRef }, + } + +type LEDChain = { + id: string, + data: PinRef, + order: string[] // PHYのノードID。並びの位置が番号になる +} + +type ELC = { + providers: Provider[], + keys: KeyWiring[], + ledChains?: LEDChain[] +} +``` + +## 検討済み・非採用 + +- `matrix.type` による配線方式の列挙 (journal/2026-09-20-elc-pin-provider.md) +- キーが row / col を正本として持つ (journal/2026-09-20-elc-pin-provider.md) +- センサの出力特性・キャリブレーション値をELCが持つ (journal/2026-09-20-elc-scope.md) + +## 未確認事項 + +### P-1 光学スイッチの端子構成 + +- 位置づけ: 本文「キーの端子」が扱えていない残り +- 現状の認識: 発光側と受光側が独立した端子を持つのか、接点と同じ2端子として扱えるのかが分からない +- 格上げ条件: 光学スイッチを使った実在のPCBの回路図を読み、端子数と配線の形を確認する + +### P-2 複数マルチプレクサ構成の作り + +- 位置づけ: 本文「ピンとピン提供者」が前提にしている。`select` を提供者ごとに持たせてよいかに関わる +- 現状の認識: 選択ピンを複数のmuxで共有して共通ピンだけ分ける形と、イネーブルピンで切り替える形が考えられるが、 + どちらが一般的か確認していない。前者なら同じ `PinRef` が複数の提供者の `select` に現れる +- 格上げ条件: 複数muxを使った実在のキーボードの配線を確認し、共有の形を確かめる + +### P-3 駆動側と検出側の役割をELCが明示的に持つ必要があるか + +- 位置づけ: 本文「配線トポロジを区分として持たない」の残り +- 現状の認識: 接点マトリクスではダイオードの向きから、directでは電源レールの参照から、 + どちらを駆動しどちらを検出するかが決まりそうに見えるが、全方式で導出できるか確かめていない +- 格上げ条件: 各方式について、端子の接続先とダイオードの向きだけから走査手順が一意に決まるかを確認する diff --git a/journal/2026-09-20-elc-pin-provider.md b/journal/2026-09-20-elc-pin-provider.md new file mode 100644 index 0000000..b21bf75 --- /dev/null +++ b/journal/2026-09-20-elc-pin-provider.md @@ -0,0 +1,52 @@ +# muxをどう表現するか / 配線方式を列挙しない + +## 結論 + +muxを「ピンを増やす装置」= ピン提供者として抽象化する。 +キーの端子は、提供者が提供する論理ピンを指す。直結とmux経由が同じ形になる。 + +配線方式(マトリクス / direct / charlieplexing)は列挙しない。端子の接続先の組み合わせとして表れる。 +row / col は正本に含めず、QMK等への出力時に割り当てる派生情報にする。 + +## 案の比較 + +| 案 | mux経由のキーの書き方 | 判定 | +| --- | --- | --- | +| ピン提供者 | `"out": "mux0.5"`、mux0が select と common を宣言 | 採用 | +| 展開アドレス | `{ "adc": "A0", "ch": 5 }`、選択ピンはボード共通設定 | 多段muxで破綻する | +| ネットリスト | 部品と結線をそのまま持つ | 回路図エディタの領分。走査手順を導出できない | + +## muxの実際 + +アナログmux(74HC4051=8ch / CD74HC4067=16ch)は、選択ピンで指定した1チャンネルだけを +共通ピンに導通させるアナログスイッチ。HE/光学がこれを使うのは、センサ出力がアナログで +ADCピンが足りないため。 + +実例(Charading/qmk-he、Pro Micro): `S0-S3 -> Pin2,3,4,5`、共通(Z) -> `A0`。 +ファームは選択ピンに 5 を出力して A0 をADC読みすると、チャンネル5のセンサが読める。 + +つまりmuxは「1本のADCピンを16本に増やす装置」。この見方がそのまま表現になる。 + +出典: +- https://github.com/Charading/qmk-he +- https://github.com/jhonney13/hall-effect-keyboard + +## ピン提供者にすると付いてくるもの + +- 多段muxが入れ子で書ける。`mux1.common = "mux0.3"` と書くだけで専用の仕組みが要らない +- シフトレジスタ・GPIOエキスパンダ・デマルチプレクサが同じ枠に入る。種別が違うだけ +- 分割キーボードの右手側マイコンが、単に別の提供者になる +- `matrix.type` のenumが不要になる + +## row / col を正本にしない理由 + +ELCが扱う範囲を全トポロジ(接点マトリクス / direct / charlieplexing / アナログ / 光学、 +いずれもmuxを挟む場合を含む)とした時点で、row / col は普遍的な軸でなくなる。 +directに行と列はなく、charlieplexingでは便宜的な表記にすぎず、アナログでは経路が +(mux, チャンネル) になる。全部を一つの座標で表すと、方式ごとに意味の違う数値になる。 + +## 却下: 旧スキーマの `matrix.type` enum + +`phase1-json-schema.md` のELCスキーマは `standard / charlieplexing / direct` の3値を持ち、 +`matrix.dimensions{rows, cols}` を必須にしていた。アナログ・光学・ホールを受けられず、 +IDX側にも `matrix{row, col}` があって二重になっていた。ピン提供者の形にすると両方消える。 diff --git a/journal/2026-09-20-elc-scope.md b/journal/2026-09-20-elc-scope.md new file mode 100644 index 0000000..d168f71 --- /dev/null +++ b/journal/2026-09-20-elc-scope.md @@ -0,0 +1,34 @@ +# ELCの射程をどこで切るか + +## 結論 + +配線だけ。「マイコンのピンと各キーの端子がどう対応するか」で切る。 +センサの品種・出力特性・キャリブレーション値は持たない。 + +代償として、ELCだけではファームウェア生成が完結しない。アナログ値を押下深さに変換する部分の +置き場は未定のまま残す。必要になった時点で層を決める。 + +## 案の比較 + +| 案 | 内容 | 判定 | +| --- | --- | --- | +| 配線のみ | 端子とピンの対応、ダイオードの向き、LEDの番号 | 採用 | +| 配線 + センサ特性 | 加えてセンサ品番と出力カーブ | PCB設計ツール側の情報 | +| 配線 + センサ特性 + キャリブレーション | 加えてキーごとの実測最小/最大 | 設計データではない | + +## 根拠 + +PHYで既に「スイッチの品種もソケット方式も持たない。どのフットプリントを使うかはPCB設計ツール側の +選択であり、Beyond KLEはその手前までを扱う」と決めている。HEセンサの品番はそのPCB設計ツール側に落ちる。 +同じ線を引き直さずに済む。 + +キャリブレーションは性質が違う。HEセンサ(ラチオメトリックなホールIC)は磁束密度に対しては +比例した電圧を出すが、磁石とセンサの距離から磁束密度への関係が急峻な非線形で、 +さらに磁石の強さと実装のばらつきが乗る。押下0%と100%の生値はボードごと・キーごとに違うため、 +実機で最小/最大を取る必要がある。これは製造後の実測値であって、設計データではない。 + +## 捨てた仮説 + +「detect が analog なら出力の向き(磁石が近いと電圧が上がるか下がるか)くらいは設計時に決まるので +ELCが持ってよい」— センサ品番が決まれば決まる値であり、品番を持たないと決めた以上これも持てない。 +向きが必要になるのは生値の解釈の段階で、そこはELCの外。