From fdd3c7def1207ce1edcdbb72d7808f287fe53ec4 Mon Sep 17 00:00:00 2001 From: EwdErna Date: Sun, 20 Sep 2026 22:02:39 +0900 Subject: [PATCH] =?UTF-8?q?workflow:=20=E6=97=A2=E5=AD=98=E3=83=95?= =?UTF-8?q?=E3=83=AD=E3=83=BC=E3=81=A8=E3=81=AE=E5=AF=BE=E5=BF=9C=E3=81=A0?= =?UTF-8?q?=E3=81=91=E3=82=92=E6=AE=8B=E3=81=97=E3=80=81=E7=A2=BA=E5=AE=9A?= =?UTF-8?q?=E3=81=97=E3=81=9F=E4=BB=95=E6=A7=98=E3=81=AB=E8=BF=BD=E5=BE=93?= =?UTF-8?q?=E3=81=95=E3=81=9B=E3=82=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 解決策・プロトコル・次のアクションの各節は layers と phase1 の重複だったため削除し、 工程分析とその課題だけの文書にした。レイヤーの定義は layers を正とする旨を冒頭に置く。 工程の対応先は、回路設計をELCのみ、ファームウェア基本設定をPHY+IDX+ELCに修正。 PCB製造は品種とフットプリントを持たないため対応なしとした。 Co-Authored-By: Claude Opus 5 --- keyboard-making-workflow.md | 80 +++++-------------------------------- 1 file changed, 11 insertions(+), 69 deletions(-) diff --git a/keyboard-making-workflow.md b/keyboard-making-workflow.md index 8f295cb..945c5c6 100644 --- a/keyboard-making-workflow.md +++ b/keyboard-making-workflow.md @@ -1,5 +1,8 @@ # 自作キーボード制作ワークフロー分析 +既存の制作フローの各工程が、どのレイヤーに当たるかを見る文書。 +レイヤーの定義と役割は `keyboard-design-layers.md` を正とする。 + ## 現在の一般的な制作手順 ### 1. デザイン・設計段階 @@ -23,7 +26,7 @@ - ダイオード配置の検討 - **出力**: 回路図、ピン配置表 - **現在の課題**: KLEからマトリックス情報への変換が手動 -- **Beyond KLE対応**: **ELCレイヤー** + **IDXレイヤー** +- **Beyond KLE対応**: **ELCレイヤー**。行列構成という工程は持たず、キーの端子とピンの対応として書く ### 2. PCB設計段階 @@ -35,7 +38,7 @@ - スイッチフットプリントの配置 - マイコン・コネクタ等の部品配置 - **現在の課題**: KLEとPCBツール間の座標変換 -- **Beyond KLE対応**: **PHYレイヤー** → PCBツール連携 +- **Beyond KLE対応**: **PHYレイヤー** → PCBツール連携。渡すのは配置であって、フットプリントの選択はPCBツール側に残る #### b) 配線・ルーティング @@ -54,10 +57,9 @@ - マトリックス定義（ROW/COL） - ピン配置設定 - 物理レイアウト定義 -- **現在の課題**: - - KLEとファームウェア設定の手動変換 - - VIAではlabelフィールドに"1,5"等を記入してmatrix座標を表現 -- **Beyond KLE対応**: **IDXレイヤー** + **ELCレイヤー** → ファームウェア自動生成 +- **現在の課題**: KLEとファームウェア設定の手動変換 +- **Beyond KLE対応**: **PHY** + **IDX** + **ELC** → ファームウェア自動生成。 + ROW/COLはELCの配線から出力時に割り当てる #### b) キーマップ設定 @@ -73,7 +75,7 @@ #### a) PCB製造 - **出力**: Gerberファイル、BOM、Pick&Place -- **Beyond KLE対応**: PHY/ELCレイヤーからの自動生成 +- **Beyond KLE対応**: なし。部品の品種とフットプリントを持たないため、この段階はPCB設計ツールが担う #### b) 部品調達・組み立て @@ -86,72 +88,12 @@ - **問題**: KLE → PCB → ファームウェアで毎回手動変換 - **影響**: 一箇所変更時の全体への反映が困難 -### 2. マトリックス情報の欠落 - -- **問題**: KLEは物理配置のみ、論理構造（マトリックス）は別管理 -- **影響**: VIAでのhackyな対応（labelフィールド悪用） - -### 3. 設計変更時のトレーサビリティ不足 +### 2. 設計変更時のトレーサビリティ不足 - **問題**: どのレイヤーでの変更が他に影響するかが不明確 - **影響**: デバッグ・修正作業の複雑化 -### 4. ツール間連携の脆弱性 +### 3. ツール間連携の脆弱性 - **問題**: 手動変換によるヒューマンエラー - **影響**: 設計ミス、製造後の修正コスト - -## Beyond KLEによる解決策 - -### 1. 統一データモデル - -``` -物理設計(PHY) → キー識別(IDX) → 電気設計(ELC) → キーマップ(MAP) - ↓ ↓ ↓ ↓ - PCBツール ファームウェア 回路図 VIA/Remap -``` - -### 2. レイヤー間の明確な責任分離 - -- **PHY**: 物理配置のみに集中 -- **IDX**: 物理と論理の橋渡し（最重要レイヤー） -- **ELC**: 電気的接続の明確化 -- **MAP**: キーマップロジックの分離 - -### 3. 双方向の依存関係管理 - -- 上流レイヤーの変更が下流に自動反映 -- 下流での制約が上流設計にフィードバック - -### 4. 既存ツールとの互換性維持 - -- KLE JSONの完全サポート -- VIA/QMK等への出力対応 -- 段階的移行の実現 - -## Phase 1で策定すべきプロトコル - -### 1. レイヤー間インターフェース仕様 - -- 各レイヤーの入出力JSON Schema -- 依存関係の明確化 -- エラーハンドリング規則 - -### 2. 既存フォーマットとの変換仕様 - -- KLE JSON → PHY変換 -- QMK設定 ← IDX+ELC+MAP変換 -- VIA JSON ← 全レイヤー統合 - -### 3. 拡張性設計 - -- 非標準マトリックス（charlieplexing等）対応 -- 3D配置への拡張可能性 -- カスタムキーコードサポート - -## 次のアクション - -1. **JSON Schema策定**: 各レイヤーのデータ構造定義 -2. **変換ロジック設計**: レイヤー間の変換アルゴリズム -3. **リファレンス実装**: TypeScript/Rust等でのプロトタイプ -4. **テストケース作成**: 代表的なキーボード設計での検証