差分
このページの2つのバージョン間の差分を表示します。
| 両方とも前のリビジョン前のリビジョン次のリビジョン | 前のリビジョン | ||
| pocketterm35のキーマップを変更する [2026/07/13 00:05] – [code.py] araki | pocketterm35のキーマップを変更する [2026/07/21 00:47] (現在) – [boot.py] araki | ||
|---|---|---|---|
| 行 42: | 行 42: | ||
| いいタイミングでRESETが入ると、boot.pyがキャンセルされるようで、CIRCUITPYがマウントされる | いいタイミングでRESETが入ると、boot.pyがキャンセルされるようで、CIRCUITPYがマウントされる | ||
| - | あまりに不便なので、この問題についても、改造の過程で解消していきたいと思う | + | {{ : |
| + | |||
| + | このとき、RP PI2がみえることがあるが、これはRP2040自体のファームウェアを変更するためのもので、このデバイスは操作しないこと | ||
| + | |||
| + | おそらくは、boot.pyではなく Circuit Python自体の起動がキャンセルされてしまうとこれが出てくるのだろうと推測しているが、確かなことはわからない | ||
| + | |||
| + | いえることはとにかくそれには触るな、である | ||
| + | |||
| + | なお、CIRCUITPYは、PocketTerm35本体からログインしていないと出現しない | ||
| + | |||
| + | リモートからsshでログインしているだけでは永遠に出てこないので、この部分だけは必ずローカルからログインした状態で操作すること | ||
| + | |||
| + | なお、このいい感じにしかCIRCUITPYが出てこないのはあまりに不便なので、この問題についても、改造の過程で解消していきたいと思う | ||
| ===== 準備 ===== | ===== 準備 ===== | ||
| 行 56: | 行 68: | ||
| * PocketTerm35にsshでアクセスできる環境 | * PocketTerm35にsshでアクセスできる環境 | ||
| - | * ファームウェアの回復用のuf2ファイルセット((Waveshareのサポートに頼むともらえるかもしれない)) | + | * ファームウェアの回復用のuf2ファイルセット((Waveshareのサポートに頼むともらえるかもしれない。わたしはもらえた)) |
| * 実験用のRaspbery Pi Pico (RP2040) | * 実験用のRaspbery Pi Pico (RP2040) | ||
| 行 114: | 行 126: | ||
| * Gamepad をHIDエンドポイントとして追加 | * Gamepad をHIDエンドポイントとして追加 | ||
| - | を boot.pyで、キーの監視とキーコードの送信やインジケータ、スピーカ、LCDのバックライトなどの制御を行う | + | を boot.pyで、それ以外のキーの監視とキーコードの送信やインジケータ、スピーカ、LCDのバックライトなどの制御を code.py行う |
| + | |||
| + | boot.pyをいじるのはおっかないので、code.pyで全部やればいいだろうとは思うのだが、上の二点はどうしても boot.pyでやらないとダメなので、覚悟を決めてコードの変更を行う | ||
| code.pyの変更は比較的安全だが、boot.pyの方は中で例外などが発生して、それを適切に処理しないとファームウェアが再起不能になる危険性があるので、慎重に行う | code.pyの変更は比較的安全だが、boot.pyの方は中で例外などが発生して、それを適切に処理しないとファームウェアが再起不能になる危険性があるので、慎重に行う | ||
| 行 124: | 行 138: | ||
| 左 Fnキーが押されていたら storage.enable_usb_drive()でCIRCUITPYを有効化する処理と、GamepadをUSB HIDのエンドポイントとして追加する処理を記述する | 左 Fnキーが押されていたら storage.enable_usb_drive()でCIRCUITPYを有効化する処理と、GamepadをUSB HIDのエンドポイントとして追加する処理を記述する | ||
| + | |||
| + | Fnキーは、結構長めに押していないといけないが、Ubuntuや多くのディストリビューションでは、CIRCUITPYが認識された時点でデバイスの挿入音が鳴ると思うので、それを待って離してもらえればいいと思う | ||
| コメントにあるように、Gamepadのエントリはサンプルから持ってきた | コメントにあるように、Gamepadのエントリはサンプルから持ってきた | ||
| 行 134: | 行 150: | ||
| 上に書いたように万一未処理の例外が発生するとファームウェアが修復不能になるためである | 上に書いたように万一未処理の例外が発生するとファームウェアが修復不能になるためである | ||
| + | |||
| + | なお、boot.pyの中にある print()などの出力は boot_out.txtというファイルに出力される | ||
| + | |||
| + | このファイルは、boot.pyから何も出力されなければ昔のファイルがいつまでも残っているので、boot.pyをテストする前には boot_out.txtを消してからやった方が問題の有無がわかりやすい | ||
| + | |||
| + | なお、boot.pyの中で未処理の例外が発生するなどすると、CIRCUITPYドライブ自体にアクセスできなくなるので、boot_out.txtに何が書かれたかを知る術はない | ||
| <file python boot.py> | <file python boot.py> | ||
| 行 220: | 行 242: | ||
| 標準のカスタムキー処理は押したときにしか発動しないが、キーリピートなどをキーパッドにもさせたかったので、カスタムキー処理の関数登録を(押す, | 標準のカスタムキー処理は押したときにしか発動しないが、キーリピートなどをキーパッドにもさせたかったので、カスタムキー処理の関数登録を(押す, | ||
| + | |||
| + | なお、code.pyの中の print()などの出力はシリアルコンソールで見ることができる | ||
| <file python code.py> | <file python code.py> | ||