μiTRONプログラマーがZephyrに挑戦！ その１

Zephyrの習得が避けられなかった経緯

私は組み込みソフトウェア・エンジニアとして長年μiTRON準拠のRTOSを使用してきました。

どんなに時代が進もうが、余程大きな案件でなければμiTRON、コレさえマスターしておけば大概の案件に対処できる…と思っていたのですが。

…甘かった！！

そのきっかけがコイツです！

Nordicという会社の「nRF5340」というマイコンです。

Nordic社は、BluetoothやZigbeeなどの2.4GHz帯の無線技術にめっぽう強い半導体メーカーです。

この「nRF5340」も、Bluetoothをはじめ様々な無線ペリフェラルを備えたSoCです。

今後、コイツを仕事で使用する可能性が出てきました。

マイコンとしてのコアはただのARMですから、この上で走るソフトウェアも、いつも通りμiTRON準拠のTOPPERS/ASPでも載せてサクッと作れるっしょ？ってタカを括っていたのですが…コレが大間違い！

何が問題か？

それは、肝心のBluetoothなどの無線周辺機器を動作させるドライバやプロトコルスタックが「Zephyr」というRTOS上での動作を前提としてNordic社から提供されていることです！

昔は、シリアルやSPIなど、組み込みソフトウェアといえばマイコンのデータシートとにらめっこして一からドライバなどをフルスクラッチで作成していました。

今では、こういった開発は工数と信頼性の面で避けられ、マイコンのメーカーからミドルウェアのサンプルが提供され、これを自分のターゲットに移植する…という方法がメジャーです。

このようなサンプルは大概の場合はベアメタル、すなわち特定のRTOSの上で動くものではなく、プレーンな状態で提供される傾向がありました。

しかし最近ではペリフェラルが複雑化しており、ベアメタルでは実装が煩雑になる（つまり読みにくいし、使いにくい）場合が増えてきており、ベアメタルで動作するサンプルに加え、何らかのRTOSの上で動作するサンプルも同時に提供される例も見られるようになりました。

イーサネットやUSBが出てきた辺りで、RTOSを使わないとベアメタルでの実装はキツくなった印象ですね。

しかし、Nordicの例のようにベアメタル向けのものが無く、特定のRTOSでのみ動作するサンプルしか提供されていないという例は私の知る限り初めてでした。

（古いドライバやプロトコルスタックでは提供されていたようですが、今更それらは使いたくありませんよね？）

つまり「Zephyr」というRTOSを使用しないと「nRF5340」に搭載している無線周辺機器が全く使えないということです！

さあ困った…。

ことここに至り「nRF5340」を存分に使用するには「Zephyr」を学ばなければならない状況となってしまいました。

これが、リスキリングってやつかぁ？

Zephyr何するものぞ？

噂の「Zephyr」ですが、一体何者？

私の拙い説明を読んでいただくより、こちらをご覧いただいた方が確実でしょう。

つまり、Linux Foundationが中心に開発を行っているオープンソースのRTOSです。

Apache License 2.0ライセンスのもと、無料で使用できます。

「nRF5340」の採用するARM Cortex-M33コアだけではなく、RISC-Vや他のアーキテクチャのマイコンもサポートされています。

また、OSのカーネルだけではなく、通信関係のドライバやセキュリティ関連のミドルウェアまで提供されます。

Linux Foundationが主管であるだけに、Linuxと同様コミュニティーによるバザール式の開発スタイルが採られ、世界中のエンジニアが開発を活発に継続しているとのこと。

ZephyrはLinux Foundationが主管しているから誤解されがちですが、ZephyrとLinuxは全くの別物です。

ベテランの方は「μCiinux」などを思い浮かべ、ZephyrをMMU抜きのLinuxミニマム版と解釈してしまいそうですが、設計がまるで異なる実装となっています。

しかしながら、CUIのコンフィギュレーションメニューやデバイスツリーでのハードウェア設定など、Linuxの文化は取り入れられています。

ですので、組み込みLinuxの開発経験者にとっては他のRTOSよりも取っつき易いでしょう。

一方で、私のようなμiTRONしか使ってこなかったプログラマーが、すぐにコイツを使いこなすことができるものでしょうか？

今回のミッション

初めてのRTOSを使うときは、普段使っているRTOSとの動作の差分を見ることが最も近道だと思っています。

どんなRTOSでもタスク（スレッド）、セマフォ、イベントフラグ…など大体同じような機能を持っていて、それらの作成・設定方法や「細かな動き」が異なります。

問題となるのは、その「細かな動き」の違いです。

新しいRTOSの上で走るアプリケーションを組む時には、ついつい今まで使い慣れたRTOSをベースに設計してしまいがちです。

そうすると予想外の問題にぶち当たることが良くあります。

同じ設計で使い慣れたRTOSでは動いたのだから、新しいRTOSでも同様だろう…と思い込んでしまうのは仕方のないことですが、これが落とし穴だったりします。

私たちは、大きな違いにはよく気付くし注意を払うけど、微妙で小さな違い…ましてやOSの中身の動作の違いなどにはなかなか気が付かないものです。

具体的な例として、タスクやスレッドの起動／休止タイミングや優先度とタスクスケジューリングの違いなどです。

大雑把に見れば両OSともに違いはないが細部での動作が異なることが引き金となり、深刻な不具合に繋がるかもしれません。

しかも、そういったものに限って原因の特定は難しい場合が多いのです。

したがって、予めそれぞれの違いを可能な限り把握しておくことが重要だと考えました。

ところで、μiTRON準拠の実装であるTOPPERS/ASPには、RTOSの動きを理解する上で非常に有用なサンプルプログラムが用意されています。

このサンプルプログラムはターゲットとパソコンをシリアル通信で接続し、パソコン上のターミナルからコマンドを送ることによって、μiTRONの主要なシステムコールを実際に動かしてみるといった内容となっています。

こんな感じです。

μiTRONのタスクの切り替えや、その反応のタイミングなどが視覚的に確認でき、非常に理解しやすい「名プログラム」だと思います。

こちらの過去記事に内容を書かせていただいていますので、興味のある方は是非。

今回は、このサンプルプログラムを可能な限り忠実にZephyrに移植し、動作を比較することでμiTRONとの「細かな動き」の違いを見つけていきたいと思います。

必要なもの

今回のターゲットとなるのはNordic社製の評価ボード「nRF7002 Development Kit」です。

搭載されているマイコンこそ「nRF5340」ですが、これは「nRF7002」というWi-Fiのコントローラを「nRF5340」マイコンと組み合わせて使うための評価ボードです。

デバッガはオンボードでかの有名な「J-Link」が載っていますので、別個に用意する必要はありません。

これ一枚で遊べますよ。

こちらでは9,000円行かない程度？

またコレじゃなくとも、同じNordicのボードなら大体同じ手順で動かすことができると思います。

ダウンロード／GitHub

サンプルプログラムをZephyrに移植したソースコードの入手は、こちらからどうぞ。

今回は、説明ばかりの退屈な更新となってしまいました…。

次回から開発環境の構築を説明します。

＜続く＞