Files
Beyond-KLE/ELCレイヤー.md
T
ewdernaandClaude Opus 5 5b671976d5 docs: 保留課題をbacklogへ分離し、運用ルール5を追加
未確認事項が「現在の仕様が答えに依存するもの」と「答えが出なくても進められる
もの」を混ぜて抱えていた。後者を backlog/README.md へ移し、仕様書の未確認事項を
前者だけに絞る。移す際は保留中の対応範囲・暫定仕様を仕様書本文に明記し、
backlogへの移動が仮説の採用を意味しないようにする。

PHY・ELC・IDXの10件を移し、3ファイルとも未確認事項が空になった。
ルール4では、事実確認の「格上げ条件」と意思決定の「完了条件」を区別する。
仕様書側の保留課題はbacklogの区分へのリンク箇条書きだけに固定し、
末尾は保留課題 → 検討済み・非採用 → 未確認事項の順に置く。

doc-lintをルール5に対応させ、backlogを検査対象に加えた。回帰テストを追加。

Journal: journal/2026-09-22-document-backlog.md

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DKW58HEg8zAQoLrkWByPfD
2026-09-22 19:52:39 +09:00

159 lines
7.6 KiB
Markdown

# ELCレイヤー
## 概要
ELCレイヤーは、マイコンのピンと各キーの端子がどう対応するかを提供する。
扱うのは配線だけとする。読んだ値をどう解釈するか(アナログ値から押下深さを出す変換、
キーごとのキャリブレーション)は持たない。キャリブレーションは実機ごとの実測値であって
設計データではなく、センサの品種はPCB設計ツール側の選択だからである。
## 構造
### ピンとピン提供者
ELCが扱う「ピン」は物理的なマイコンピンに限らない。**ピン提供者(provider)が提供する論理ピン**とする。
マルチプレクサ・シフトレジスタ・GPIOエキスパンダは、いずれも「少ないピンを多くのピンに増やす装置」である。
これらを提供者として扱うと、キーの側からは直結もmux経由も同じ「ピンに繋がっている」だけになる。
提供者は、自分が消費する上位ピンを宣言する。上位ピンには別の提供者の論理ピンを書けるので、
多段の接続は入れ子として表せる。分割キーボードの各半身は、それぞれ別の提供者として置く。
ピンの参照は `<提供者ID>.<ピン名>` の形とする。`VCC` と `GND` は電源レールを指す予約名で、提供者を持たない。
現時点で具体形を定めるのは、マイコンとアナログマルチプレクサの2種別。
デジタル側でピンを増やす部品も提供者として扱うが、種別ごとの記述は必要になった時点で定める。
同じ `PinRef` が複数の提供者の `select` に現れることは一律には禁止しない。
複数mux構成の走査出力は、実配線と制御方法を確認した構成から対応する。
### キーの端子
キーは検出方式(detect)を持ち、検出方式ごとに端子の構成が決まる。各端子は接続先の論理ピンを持つ。
- 接点(contact): a, b の2端子。端子は無極性で、a と b に順序の意味はない
- アナログ(analog): out 1端子。加えて電源の vcc, gnd。ホールセンサがこれにあたる
光学スイッチは当面未対応とする。端子構成を確認するまで、既存の検出方式に仮置きしない。
### 配線トポロジを区分として持たない
マトリクス・direct・charlieplexing を列挙して選ばせることはしない。
これらは端子の接続先の組み合わせとして表れるものであって、設計者が選ぶ区分ではない。
- 両端子がそれぞれ別のマイコンピンを指す → マトリクスまたはcharlieplexing
- 片方の端子が電源レールを指す → direct
- out がマルチプレクサの論理ピンを指す → mux経由のアナログ読み
row / col はELCの正本に含めない。charlieplexing で便宜的に行と列の形で書くことはあるが、
それは表記の都合であって配線の事実ではない。QMKなどが要求する row / col は、出力時に割り当てる派生情報とする。
走査方向の決定と追加指定はFirmware Generatorが受け持ち、ELCには保存しない。
接点マトリクスでは、どちら側のピン群を駆動し、どちら側から読み取るかを指す。
配線・ダイオードの向きと整合する方向を出力器が選び、追加指定が必要な場合は出力設定で受け取る。
配線だけから全方式の走査手順が一意に決まることは前提にしない。
方式ごとの必要な設定は、その方式の出力に対応する際に確認し、未対応の構成は出力しない。
### ダイオード
接点キーはダイオードの向きを持つ。向きは端子名で表す(`a-to-b` はアノードがa側)。省略時はダイオードなし。
### LEDの識別番号
LEDの番号はELCが持つ。設計者が恣意的に決めてよいが、決めた順序はそのまま配線の指示になるため、
配線の情報として扱う。
チェーンごとに、データピンと、LEDの並びを持つ。並びの各要素はPHYのノードIDで、
per-key LEDを載せたキーか、LEDの部品ノードを指す。並びの位置がそのLEDの番号になる。
チェーンは複数持てる。
現時点で定めるのはチェーン方式(WS2812系)のみとする。ドライバICでアドレスを与える方式は未定。
### レイアウトバリアント
PHYがレイアウトバリアントを持つ場合も、ELCは選択に関係なく全バリアントのキーを配線する。
基板上のフットプリントは選ばれなかった側も実在するため。
互いに排他なキーは、同じ接続先の組を共有してよい。排他でないキー同士が同じ接続先の組を持つのは
設計エラーとする。接点マトリクスなら、どちらが押されたかを区別できないため。
排他かどうかはPHYの木から判る。
ファームウェア向けのキー番号と接続先の対応表は、バリアント選択後のIDXの並びから生成する。
同じ接続先を共有する排他キーも、選択後に同時には残らない。ELCの保存データは選択によって書き換えない。
LEDチェーンもバリアントごとに分けない。排他なキー位置の両方にLEDが載る基板も、
バリアント固有のキーにLEDが載らない基板もあるが、どちらもチェーンは1本で、選択によって並びが変わらない。
載らないキーは、PHYがキーごとに持つper-key LEDの有無でそのまま表せる。
キー配列の出力で行うバリアントの取捨・番号の詰め直しは、LEDチェーンには適用しない。
### 他レイヤーへの参照
キーと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[]
}
```
## 保留課題
- [ELCの保留課題](backlog/README.md#elc)
## 検討済み・非採用
- `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)
## 未確認事項
(なし)