ハクソク

世界を動かす技術を、日本語で。

マイクロコントローラーと組み込みLinux上でErlang/Elixirを実行する

265日前原文(grisp.org)

概要

  • GRiSP はErlang/Elixirを組み込みシステムで直接実行するための専用ソフトウェアスタックを提供
  • GRiSP Metal/Alloy/Forge の3種類で、用途やハードウェア要件に応じて選択可能
  • リアルタイム性・小型フットプリント・堅牢な分散処理 が特徴
  • GRiSP-io でクラウドからのデプロイ・監視・管理が可能
  • プロトタイピングから本番運用まで、 拡張性と長期運用 に対応

GRiSP Metal：リアルタイム組み込み向け最小構成

  • Erlang/Elixir VM （BEAM）を RTEMS 上で直接起動
  • 16MB RAM に収まる MCUクラスの小型フットプリント
  • リアルタイムスケジューリング と 予測可能なI/O
  • ハードウェアインターフェースへの 低オーバーヘッドな直接アクセス
  • Supervision tree によるエッジでの高信頼性実現

GRiSP Alloy：リアルタイムLinux対応の拡張性

  • Buildrootベースの最小Linux RTイメージ でBEAMに直接ブート
  • 複数BEAMインスタンス を 優先度分離・コア固定 で実行
  • 分散Erlang による ローカル・セキュアリンク
  • Linuxの ドライバ・ファイルシステム・ネットワーク にフルアクセス
  • 高速起動、 小さな攻撃面、 本番運用対応

GRiSP Forge：産業用途のカスタマイズ性

  • Yoctoベース のリプロダクタブルなカスタムLinuxイメージ
  • Alloy同様、 複数Erlang/Elixir VM と 分散Erlangリンク を標準搭載
  • BSP統合 や 長期運用 に最適な構成
  • 産業用Linuxエコシステム との互換性・ツール群
  • 企業向け長期サポート と拡張性

GRiSP-io：クラウド＆エッジ管理プラットフォーム

  • GRiSPスタック採用デバイス の リモートデプロイ・管理
  • リアルタイムなシステム監視 と ヘルスチェック
  • OTA（Over-the-Air）アップデート の安全実施
  • クラウド・エッジ制御の ワークフロー統合
  • プロトタイプから大規模運用まで 一元管理

GRiSPの特徴と用途

  • Erlang/Elixir を ベアメタルや組み込みLinux で直接実行
  • 低オーバーヘッド・リアルタイム性 でシステム設計を簡素化
  • 分散処理・高信頼性 を小型組み込み機器にも適用可能
  • オープンソースツールで プロトタイプから量産まで対応
  • 自動化・ロボティクス・IoTデバイス などリアルタイム分散アプリケーションに最適
  • GRiSP-io による 遠隔監視・運用管理 の効率化

Hackerたちの意見

グリームはどうなの？

└

OTP互換性が実装されたら呼んでね。

リアルタイム機能があるって言われてるのに、詳しい情報が見つからないのが残念。でも、ハードウェア統合は好きだな。

└

うん、主張があいまいだよね。ビーム自体はソフトリアルタイムしか保証されてないから、オープンエンドにしておくと、特にハードウェアに関しては人々がハードリアルタイムだと思っちゃうかも。

└

リアルタイムって、現代史の中で最も誤用されている専門用語の一つだね。一般的に、ほとんどのJITやVMは保証されたレイテンシを主張できない。こういう概念を混ぜる人は、自分の無知をさらけ出しながら賢そうに見える。FreeRTOSは小さくて実現可能。予算に制約がなければVxWorks。LinuxCNCで使われるLinuxRTカーネルに外部コンテキストクロッキングやFPGAメモリDMAオーバーラップモジュール（Zynq SoCなど）を組み合わせるのもあり。リアルタイムは専門的で低賃金な分野で、多くの人はハードウェアのメタスタビリティ問題に取り組むには理解が抽象的すぎるね。=3

いいね！エルラングのことはなんでも好きなんだ。Beamを使って大規模なIoTデバイスのクラスターを管理するのは、フォールトトレランスだけじゃなくて、コードのホットスワッピングのためにも良いアイデアだと思う。

└

これって普段からやってることなの？

└

私も同じだけど、Elixirのためにね。ビームは素晴らしいし、成功事例がたくさんあるのに、なんでまだ広まってないのかいつも不思議に思ってる。アクターモデルのおかげでプログラミングがすごくシンプルに感じるよね。

MCUクラスのフットプリント（16MB RAMに収まる） それは絶対にMCUクラスのフットプリントじゃないよ。「M」がつくメモリの話をするときは、MCUとは言えない。証拠として、STのマイクロコントローラーのページを引用するよ：https://www.st.com/en/microcontrollers-microprocessors/stm32... 高性能なやつだけが1MB以上のRAMを持ってる。

└

MCUのRAMはどんどん安くなってるね。数年前はバイト単位で測ってたのに。RP2040の前は数十KiBだったのが、今はMiB単位で測られるようになった。16MiBは今のところは大きめだけど、数年後には主流のMCUもそのくらいの容量を搭載するようになると思うよ。

└

うーん、最近は境界が曖昧になってきてるね。今のところの差別化ポイントは、MMUはあるか？外部メモリ用のアドレスラインは？OS用に書くのか、"ベアメタル" / RTOSキット用に書くのか？GPIO用の専用ピンはあるか？適当なメモリ量を基準にすると、来年には古くなっちゃうよ。

└

これにはパッケージ内RAMは必ずしも必要じゃないよ。これを基にプロジェクトを作るかは微妙だけど、16MiBのRAMがあったからってBOMを台無しにすることはないと思う。

└

ErlangをKiBサイズのRAMで使うなら、AtomVMプロジェクトの方が合ってるかもね。 https://github.com/atomvm/AtomVM

└

彼らのボードはドイツのPhytecのダウターボードを使ってるみたいだね。これは非常に高性能なNXPのMCU、i.MX 6ULをベースにしてて、外部DDR RAMも追加されてる。

└

EspressifはESP32をMCUって呼んでるけど、ESP32のモデルの1/3以上は1MiB以上のオンボードPS（「擬似静的」）RAMを持ってるよ（つまり、自分専用のリフレッシュ回路を持つDRAMね）。少なくとも20のESP32モデルは16MiBを持ってる。俺は、ESP32はこの構成でもMCUだと思う。なぜなら、「持ち上げて使って、置いておく、再び持ち上げるまで充電が持つ」デバイスに期待される超低消費電力のアイドル要件を満たしてるから。だから、もし0.07ドルのMCU ICをキーボードやマウスに使うって意味なら、それはNerves（や他の動的ランタイム）を動かすのには向いてないよ。完全にベアメタルで行く必要がある。でも、2ドルから8ドルのMCU ICをウェブカメラやマネージドスイッチ、バッテリー駆動のはんだごて、自動吸引レベル検出付きのスティック掃除機、またはソフトタッチコントロールとLCDを備えたキッチンレンジや電子レンジなどに使うって意味なら、そういう用途ではNervesは問題なく動くよ。

それって神経質な感じ？でもソフトリアルタイムが加わってる？

└

俺の要約は、GRISPはRTOS上のBeamで、NervesはミニマルなLinux上のBeamってこと。でも、GRISPにはLinux上のGRISP AllowとGRISP Forgeもあるよ。どれもソフトリアルタイムを実現できる。

└

NervesはLinux上のErlang-as-initだね。GRISPはメタル上のRTEMSとErlangの組み合わせ。

Elixirの大ファンだよ。で、ちょっとバカな質問があるんだけど。見たリアルタイムアーキテクチャの中には、特定のプロセスが優先されるか、特定のHzで動くものがあったけど、ビームではそういうの見たことない。私の知る限りでは「ただ動く」って感じで、ほとんどの時はそれが素晴らしいんだけど。Process.flag(:priority, :high)を使えばできるかもしれないけど、それで十分かどうかはわからないな。

└

ビームはソフトリアルタイムしか約束してないよ。プロセスを切り替えるとき、実行可能な高優先度のタスクが、実行可能な通常または低優先度のタスクよりも選ばれるし、各キュー内ではすべての（実行可能な）タスクが再度タスクが実行される前に実行される。でも、ビームは本当にプリエンプティブじゃないから、高優先度のタスクが実行可能になっても、実行中の通常または低優先度のタスクは一時停止されない。通常のタスクは、リダクションキャップに達するかブロックされるまで続行されるんだ。それに、時間がかかる操作に当たって、イールドポイントがない場合もあるかも。ERTSのほとんどは、時間がかかる操作にイールドポイントがあるけど、もしかしたらそうじゃないのに当たるか、動作が不安定なNIFがあるかもしれない。リアルなプリエンプションがないと、厳しいタイミング要件を一貫して満たすのは難しいかもね。複数のビームを動かしてOSのプリエンプションを使うっていう手もあるかも？

90年代のコンピュータを使って、ErlangやElixirで暗号ノードを動かすことってできるかな…？それともそのバージョンの何か？

└

そうだね、Erlang/Elixirがここでの制約にはならないよ。90年代のハードウェアでも十分だし、彼らはもっと少ないリソースで設計されてたから。

└

ページには実装に16MBのRAMが必要って書いてあるから、90年代後半のコンピュータなら動かせるけど、90年代中頃のコンピュータ、特に初期のPentiumモデルはそれ以下のRAMが多かったよ。もしWindows 98以降で出荷されてたら、16MBはあるはず。