ZephyrRTOS ざっくり入門 #2 常田 裕士 秋葉原ロボット部 第148回勉強会 @ 秋葉原 ロボスタディオン 

Hello Worldと Lチカを読む 

Hello World.  samples/hello_world にあるので写経しましょう。  ファイル構成:  CMakeLists.txt: Cmakeの設定ファイル。コンパイル対象の設定に使う。  prj.conf: ビルドオプションの設定  src/main.c: これが本体  README.rst: 気にしない。  単なるドキュメント。ZephyrではreStructuredTextが標準  Sample.yaml: 見なかったことにする。  自動試験用の設定ファイル 

CMakeLists.txt  CMakeの設定ファイルは基本的にはコンパイル対象とincludeパスの追加のみ  find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE}) はオマジナイとして必須。  Zephyr固有のCmakeの設定がまるっと読み込まれる。  ベタでcmakeコマンドは使わないので、ここで頑張らないこと。  だいたいの場合、このファイルのコピペで十分。 

prj.conf  設定のメインはこれで行う。  LinuxのKconfigシステムを移植して使っ ている。  CONFIG_～=y で各種オプションを設定 する。  オプションは山程ある。(現状20000程 度)  west build –t menuconfigで設定ができ る。  west build –t guiconfig でいい感じの画 面で設定ができる。 (apt install python3-tk が必要) 

src/main.c  どこにでもある普通のHello World.  「どこにでもある普通のHello World」が 素直に動かないのが組み込み開発。 (最近はだいぶ減った)  ANSI Cがない、main()がない、謎のlinkerスクリプト…  Zephyrは組み込み、RTOSではあるが、かなり普通の「C言語」で書ける。  とはいえ、POSIXを意識するfopenあたりになると互換レイヤーを組み込む形に。  この辺はソニーのSpresenseが使ってるNuttXの方が上手にやっている。 #include int main(void) { printf("Hello World! %s¥n", CONFIG_BOARD_TARGET); return 0; } 

blinky  これも写経推奨。samples/basic/blinkyにある。  samples/basic配下は基本的なサンプルが入ってい るので一通り動かすと良い。  設定はHello Worldとさして変わらず。LEDのた めにGPIOを使うので、prj.confで CONFIG_GPIO=yが指定されてる。 

Blinky 読解 #1 #define LED0_NODE DT_ALIAS(led0) static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios); leds: leds { compatible = "gpio-leds"; green_led_2: led_2 { gpios = <&gpioa 5 GPIO_ACTIVE_HIGH>; label = "User LD2"; }; }; aliases { led0 = &green_led_2; };  DT=DeviceTree. この定義を参照してハードウェアにアクセスしている。  これもLinux由来。  LEDの定義を参照して、GPIOのポートとピン番号の情報をまとめた gpio_dt_spec構造体の情報を引き出している。  フラグがGPIO_ACTIVE_LOWだと負論理になる。 RESETとかだとACTIVE_LOWを使う。 Nucleo_h503rbのdevicetreeより抜粋 

Blinky 読解 #2  DeviceTreeさえわかればあとはシンプル。  gpio_is_ready_dt: 状態チェック  gpio_pin_configure_dt: ピンの入出力の設定  gpio_pin_toggle_dt: ピン出力を反転  k_msleep: ミリ秒待つ  DeviceTreeを深追いすると大変なので、いまは 「動いているのでヨシ！」  それ以外は割と素直なプログラム。  しかし、DeviceTreeが追えないと、このコードは読 めない。 int main(void) { int ret; bool led_state = true; if (!gpio_is_ready_dt(&led)) { return 0; } ret = gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE); if (ret < 0) { return 0; } while (1) { ret = gpio_pin_toggle_dt(&led); if (ret < 0) { return 0; } led_state = !led_state; printf("LED state: %s¥n", led_state ? "ON" : "OFF"); k_msleep(SLEEP_TIME_MS); } return 0; } 

DeviceTree  DeviceTreeはZephyrを特徴づける最大の要素  「汎用RTOS」であるため、カーネルの基本機能で強い「色」はついていない。  Linuxと違って、DeviceTreeを静的にコンパイルして組み込む。  組み込み用途で必要なフットプリント最小化と、 実装と構成の分離を同時に実現している。  このトレードとして、 大変煩雑なC言語のマクロの記述が必要になる  このpros/consのトレードの判断こそが Zephyrを特徴づけている 

© 2024 Fujitsu Limited Linuxでの DeviceTree 11  DeviceTreeの仕様にある、DTB形式 （DeviceTree Blob）を使う。  テキストで記述されたDTS(DeviceTree Source)をDTBにコンパイルする  カーネルが起動時にDTBを読んで、構成 (Configuration)データとして利用する。 

ZephyrでのDeviceTree © 2024 Fujitsu Limited 12  DeviceTreeの書式はLinuxと同じ（DeviceTreeの仕様通り）  ZephyrではDTBを使わない  DeviceTreeから巨大なC言語のコード（マクロ）を生成する  動的な構成の変更はできない。  実装と構成を分離して、コードの再利用性を高めるのが目的。  Linuxでもこの目的で導入された。 LKML: Linus Torvalds: Re: [GIT PULL] omap changes for v2.6.39 merge window (ARM 関連のコードが激増し、Linus氏が激怒したという逸話)  Zephyrでも同様に効果が上がっている。 

具体的な現れ方  LチカのソースでDeviceTreeの情報にアクセスしているのは以下の箇所。 #define LED0_NODE DT_ALIAS(led0) static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios);  以下のようなDeviceTree定義と対応する。 / { aliases { led0 = &myled0; }; leds { compatible = "gpio-leds"; myled0: led_0 { gpios = <&gpio0 13 GPIO_ACTIVE_LOW>; }; }; }; © 2024 Fujitsu Limited 13 

DeviceTreeの闇  DeviceTreeでは、配列の定義があるので、Zephyrのマクロでも配列をループ処 理するためのマクロ(!)が生成される。  ～_FOREACH_…という名前で、マクロを引数に取って、それを各要素に適用する高 階関数(高階マクロ？)が作られる。  COND_CODE_1  #ifdefと似たような動きをするが、マクロの引数で与えた値でコードの有効無効を切 り替える機能。  中身は完全に黒魔術（##を使った多重のマクロ展開をうまく使っている。解析が非 常に面倒）  上記のFOREACHと組み合わせると、DeviceTreeの定義に合わせて、無駄なくコード を生成できる。 © 2024 Fujitsu Limited 14 

一例 #define SERIAL_DEFINED_0 1 #define EXTERN_SERIAL_N(i) extern arduino::ZephyrSerial Serial##i; #define DECLARE_EXTERN_SERIAL_N(n, p, i) COND_CODE_1(SERIAL_DEFINED_##i, (), (EXTERN_SERIAL_N(i))) /* Declare Serial1, Serial2, ... */ DT_FOREACH_PROP_ELEM(DT_PATH(zephyr_user), serials, DECLARE_EXTERN_SERIAL_N) 私が作成したZephyr向けArduinoAPIの中から。gsoc-2022-arduino-core/cores/arduino/zephyrSerial.h DeviceTree上の配列serialsを見て、0番目以降の要素に対してSerial1, Serial2, …と割り振って宣言する。ここで0番目はす でにSerialとして定義済みなので除外したい。 COND_CODE_1は第一引数が定義済みで真なら第二引数、そうでなければ第三引数をコードに置き換えられる。ただし、 第一引数は内部で別のマクロと連結して処理されるため、整数リテラルとして定義されている必要がある。 ここでは、序数を連結すると、整数に展開できるSERIAL_DEFINED_0を定義して、この動作に適応させて処理を行っている。 複雑なコードであるが、DeviceTreeの要素を適切に扱えており、また、すべてコンパイル時計算となるので効率的である。 DeviceTreeによる実装と構成の分離、HALはLinuxから受け継いだHeritageの部分にもあたる。 dirtyではあるが、この仕組みによって非常に巧く処理されており、Zephyrを特徴づけている部分でもある。 © 2024 Fujitsu Limited 15 

シールドを使う  ZephyrにはArduinoのシールドのような拡張ボー ドを使う機能がある。  簡単には、west build のコマンドに –shield xxx のオプションを追加すると、定義済みの シールドを組み込める。  boards/shields/ の下に入っているものが使える。 (まだ多くはない) 

使ってみる  いいサンプルがないので、手前味噌ながら私のリポジトリからPR提出中のサン プルを使う。  ここで紹介するサンプルは現在、Grove等のコネクタ接続のための仕様提案を 行って議論中。 https://github.com/zephyrproject-rtos/zephyr/issues/82889  NucleoにGrove base shield for Arduinoのシールドを乗せて、 その上にGrove接続のセンサーを接続する。  --shieldは重ねがけ可能。 west build -p -b nucleo_h503rb samples/sensor/lis2dh/ --shield seeed_grove_base_sheild --shield seeed_grove_lis3dhtr git fetch origin pull/82996/head:pr82996 git checkout pr82996 

Shieldの中身 • Kconfigの設定。westのコマンドラインで指定された場合に有効になる設 定。 Kconfig.shield • devicetreeのオーバーレイ。すでにあるDeviceTreeの設定を上書きする。 Shieldの場合、バスに追加するデバイスの定義を持っている。 ～.overlay 

Adafruit AW9523Bの例  私が作成して既にマージ済みのコード。  Adafruitのstemma_qtコネクタにつながる GPIO ExpanderチップのAW9523Bを実装し たボード。  I2cバスにaw9523bのデバイスを接続する設 定をオーバーレイとして追加する。  このオーバーレイが追加されると、  stemma_qt_i2c のi2cバスが有効になる。 (statusをokayで上書きするので)  stemma_qt_i2c のi2cバス上にaw9523bの デバイスが追加される &stemma_qt_i2c { status = "okay"; adafruit_aw9523: aw9523b@58 { status = "okay"; reg = <0x58>; compatible = "awinic,aw9523b"; adafruit_aw9523_gpio: aw9523b-gpio { status = "okay"; compatible = "awinic,aw9523b-gpio"; gpio-controller; #gpio-cells = <2>; }; }; }; 

オーバーレイの使われ方  Shield以外にもオーバーレイはあちこちで使われる。  west buildのオプションで --extra-dtc-overlay … で指定する  boards/ のディレクトリを作成し、[ボード名].overlayファイルを作成すると、 対象のボードのビルドの場合のみそれが適用される。  socも boardsと同様の対応が可能  ボードのリビジョン違いを定義するために使われる。 

まとめ  Zephyrのサンプルはソースツリーのsamplesの下に色々入ってる。 特にsamples/basicは基本的な使い方のサンプルで、動かしてみるのが良い。  デバイスにアクセスするためにはDeviceTreeから情報を持ってくる必要がある。  KconfigもDeviceTreeもLinuxから継承した仕組み。  DeviceTreeのオーバーレイを使ってデバイスの追加を行える。  Shieldはパッケージ化された形でオーバーレイを使える便利な仕組み。  オーバーレイはアプリ固有の設定やボードのカスタマイズなど色々な形で現れ る。