差分

このページの2つのバージョン間の差分を表示します。

--- pocketterm35のキーマップを変更する [2026/07/12 23:45] – [準備] araki
+++ pocketterm35のキーマップを変更する [2026/07/21 00:47] (現在) – [boot.py] araki
@@ 行 10: / 行 10: @@
 なるほど、それならばそれでやってみよう
+なお、Raspberry Pi Picoのファームウェアを変更できるだけの知識がない場合は、手を出さない方がいいと思う
+また、ここに書かれていることに基づいてキーマップの変更などを試みて、PocketTerm35が回復不能なダメージを受けたとしても、当方は一切関知しない
+この種の改変は、間違えば回復不能なダメージをPocketTerm35に与える可能性があることを念頭に、自己責任で行っていただきたい
 ===== CIRCUITPYをマウントする =====
@@ 行 20: / 行 26: @@
 のちにわかるのだが、boot.pyのなかでCIRCUITPYを無効化しているので、基本的に出てこないのだ
+以下が2026年6月到着のデバイスに入っていたデフォルトのboot.pyの内容である
 <file python boot.py>
@@ 行 30: / 行 38: @@
 **いい感じにRESETボタンを連打する**
-これしかないので、いい感じにRESETボタンを連打してください
+これしかないので、いい感じにRESETボタンを連打する
+いいタイミングでRESETが入ると、boot.pyがキャンセルされるようで、CIRCUITPYがマウントされる
+{{ :pocketterm35:code_py.png?400|}}
+このとき、RP PI2がみえることがあるが、これはRP2040自体のファームウェアを変更するためのもので、このデバイスは操作しないこと
+おそらくは、boot.pyではなく Circuit Python自体の起動がキャンセルされてしまうとこれが出てくるのだろうと推測しているが、確かなことはわからない
+いえることはとにかくそれには触るな、である
+なお、CIRCUITPYは、PocketTerm35本体からログインしていないと出現しない
+リモートからsshでログインしているだけでは永遠に出てこないので、この部分だけは必ずローカルからログインした状態で操作すること
-この問題についても、改造の過程で解消していきたいと思う
+なお、このいい感じにしかCIRCUITPYが出てこないのはあまりに不便なので、この問題についても、改造の過程で解消していきたいと思う
 ===== 準備 =====
@@ 行 46: / 行 68: @@
   * PocketTerm35にsshでアクセスできる環境
-  * ファームウェアの回復用のuf2ファイルセット((Waveshareのサポートに頼むともらえるかもしれない))
+  * ファームウェアの回復用のuf2ファイルセット((Waveshareのサポートに頼むともらえるかもしれない。わたしはもらえた))
   * 実験用のRaspbery Pi Pico (RP2040)
@@ 行 55: / 行 77: @@
 実験用のRaspberry Pi Picoがあると、キーを実装していなくても、シリアルコンソールで最低限の動作確認は行えるし、万一致命傷を与えても、Adafruitが配布している誰でも入手できる uf2ファイルで簡単に復旧できるので、Waveshareから回復用のファイルをもらえなかった場合にも安心である
+実験機の上で最低限、致命的な問題が起きないことを確認してから、PocketTerm35に持ち込めば、いきなり文鎮化するような悲劇は回避できるだろう
 ===== キーマップの設計 =====
@@ 行 103: / 行 126: @@
   * Gamepad をHIDエンドポイントとして追加
-を boot.pyで、キーの監視とキーコードの送信やインジケータ、スピーカ、LCDのバックライトなどの制御を行う
+を boot.pyで、それ以外のキーの監視とキーコードの送信やインジケータ、スピーカ、LCDのバックライトなどの制御を code.py行う
+boot.pyをいじるのはおっかないので、code.pyで全部やればいいだろうとは思うのだが、上の二点はどうしても boot.pyでやらないとダメなので、覚悟を決めてコードの変更を行う
 code.pyの変更は比較的安全だが、boot.pyの方は中で例外などが発生して、それを適切に処理しないとファームウェアが再起不能になる危険性があるので、慎重に行う
 万一、再起不能になった場合は、復旧用の uf2ファイルで修復しないと回復しない
+なお、code.pyの変更は自動的に検知されてリロードされるし、シリアルコンソールで Ctrl+Dをたたくことで強制的にリロードできるが、boot.pyを変更した場合は RP2040を本体背面のリセットボタンでリセットする必要がある
 ==== boot.py ====
-左 Fnキーが押されていたら storate.enable_usb_drive()でCIRCUITPYを有効化する処理と、GamepadをUSB HIDのエンドポイントとして追加する処理を記述する
+左 Fnキーが押されていたら storage.enable_usb_drive()でCIRCUITPYを有効化する処理と、GamepadをUSB HIDのエンドポイントとして追加する処理を記述する
+Fnキーは、結構長めに押していないといけないが、Ubuntuや多くのディストリビューションでは、CIRCUITPYが認識された時点でデバイスの挿入音が鳴ると思うので、それを待って離してもらえればいいと思う
 コメントにあるように、Gamepadのエントリはサンプルから持ってきた
@@ 行 121: / 行 150: @@
 上に書いたように万一未処理の例外が発生するとファームウェアが修復不能になるためである
+なお、boot.pyの中にある print()などの出力は boot_out.txtというファイルに出力される
+このファイルは、boot.pyから何も出力されなければ昔のファイルがいつまでも残っているので、boot.pyをテストする前には boot_out.txtを消してからやった方が問題の有無がわかりやすい
+なお、boot.pyの中で未処理の例外が発生するなどすると、CIRCUITPYドライブ自体にアクセスできなくなるので、boot_out.txtに何が書かれたかを知る術はない
 <file python boot.py>
@@ 行 200: / 行 235: @@
 ==== code.py ====
-基本的にはオリジナルのcode.pyに手を入れる形で行う方がいいだろう
+もちろん、果敢に、すべてをスクラッチから作成することも可能ではあるが、基本的にはオリジナルのcode.pyに手を入れる形で行う方がいいだろう
 ここでベースにしているのは製品に同梱されていたものではなく「ファームウェア頂戴」って依頼したときに、回復用の uf2ファイルと一緒に「Fn+L/Fn+Rでマウスクリックできるようにしたサンプルもつけとく」っていって同梱してきてくれたファイルなのでもしかすると微妙に違うかもしれないが、大体同じはずである
@@ 行 207: / 行 242: @@
 標準のカスタムキー処理は押したときにしか発動しないが、キーリピートなどをキーパッドにもさせたかったので、カスタムキー処理の関数登録を(押す,離す)のタプルで登録してあった場合に、キーリピート処理ができるように拡張した
+なお、code.pyの中の print()などの出力はシリアルコンソールで見ることができる
 <file python code.py>

WildTree Wiki

ユーザ用ツール

差分