Raspberry Piでは、Raspbian上で普通のPythonを使ってI/Oを制御することができます。
なのに敢えて、ベアメタルでMicroPythonを実装することにどんな意味があるのか、最近思っていることをちょっと書いておきます。
まず、起動時間短縮、これはあまり意味がないと思います。
Raspbianは確かに起動に時間がかかりますが、Buildrootなどで軽量なLinuxシステムを作れば、5秒以内に起動するシステムを作ることは可能です。
ハードを直接叩くような実装をすること自体が楽しい、これはまあ当たっています。しかし、これはMicroPythonではなくベアメタルプログラミングの楽しさです。
その結果できあがったものを使う意味があるかどうかは別の話です。
同様の議論がMicroPythonのフォーラムでも行われていました。
Raspberry Pi Zero – MicroPython Forum
最近感じているのは、Raspbian上でPythonを使用するよりも、MicroPythonを使用するほうがよりベアメタルプログラミング的であるということです。
MicroPythonの面白さは、ハードウェアを抽象化する層がMicroPythonそのものしかないところにあります。
実際のベアメタルプログラミングにかなり近い形でハードウェアに触れることができます。
Raspbian + Pythonでは、Linuxがハードウェアを抽象化しているため、ハードウェアからちょっと距離があります。
例えば、UNIXなのでデバイスがデバイスファイルとして見えていますし、スーパーユーザ権限無しにできることにも限りがあります。
もちろん、その結果として楽ができるわけですが。
MicroPythonでは、ハードウェアを抽象化するレイヤはMicroPython以外にはありません。プラットフォームによってはSDKで隠蔽される部分がある程度です。基本的に、ハードウェアはMicroPythonのモジュールないしクラスで抽象化されます。
その結果、MicroPythonでのプログラミングは、Cでハードウェアを叩くベアメタルプログラミングに近くなります。ボードに接続された周辺デバイスを直接制御でき、その反応も直接返って来るので、デバイスの生の挙動を観察することができます。
そのようなベアメタルプログラミングの環境として、MicroPythonは非常に優れています。デバイスは実際に動かして調べないと挙動が把握できないことも多いので、REPLで試行錯誤的にハードウェアを叩けるのは、コンパイルとダウンロードの手間が省けて大変便利です。関数定義もその場で追加修正できるので、デバッグ効率はC言語でのベアメタルプログラミングとは雲泥の差があります。
つまり「Raspberry Piに様々なデバイスをつないで制御するには、MicroPython on ベアメタルRaspberry Piは価値がある」ということになります。
逆に言うと、MicroPythonの良さを活かすためには、ハードウェアを過度に抽象化しないことが重要になります。
前回のTimerクラスの実装では、この抽象化をするかどうか、ちょっと悩みました。
Raspberry Piでは、System Timerは4つ(0, 1, 2, 3)ありますが、2つ(0と2)は使用済みです。
MicroPythonからは、実質的にはTimer 1と3しか使えないことになります。
そのため、Timerクラスの設計として
・利用可能な2つだけをサポートするか、4つともサポートした上で0と2は使うな、とするか
・そもそもTimerが2つしか使えないのは不便なので、TimerクラスではVirtual Timerだけにして、Virtual Timerの実現にハードウェアタイマを1つだけ使ってはどうか
といったことも考えました。
しかし結局、TimerクラスではRaspberry PiのSystem Timerの仕様をそのまま素直に反映させることにしました。
その結果、Timerクラスでは4つのタイマが指定できますが、0と2は実質的に使えないという(若干不便な)仕様になります。
ですが、これがRaspberry Piの仕様であり、それを隠すような実装をMicroPython側で行うことは、かえってMicroPythonの魅力を削いでしまうのではないかと思いました。
というわけで、現在思っていることをまとめると、以下のようになります。
・Raspbian + Pythonでは、Raspberry Piにつないだハードウェアを制御する時にLinuxが邪魔になる場合もある
・MicroPythonは、REPLの中でハードウェアを直接制御・観察できるところにメリットがある
・MicroPythonのメリットを享受するには、ハードウェアをMicroPythonが過度に抽象化しないことが重要
従って、今後も基本的にはまずBCM2835のリファレンスマニュアルにある内容をそのまま実装した上で、ハードウェアに無い機能(Timerクラスで言えばコールバックやカウンタ)は適宜、利便性のために追加するという方針で行こうと思っています。
コメント