STM32でNUTTXを使ってみる

Work Queue Interfaces

NuttxのAPIはこちらに詳しく公開されています。
今回はこれらのAPIの中でも少し特殊なWork Queue Interfacesを紹介します。
このAPIを使うと、定周期で実行する処理を予約することができます。
Work Queue Interfacesは、デバイスを定期的にポーリングする場合などに使われます。
まず以下の手順でHPWORK(high priority work queue)を有効にします。

ここまで設定したらひたすらExitで抜けます。
新しい[.config]を使ってファームウェアをビルドし、新しいファームウェアをマイコンに書き込みます。
nshに接続するとhpworkのスレッドが起動しています。

同じ手順でLPWORK(low priority work queue)を有効にします。

これでlpworkのスレッドが起動します。

次にこちらの手順でsyslogの出力先をRAMLOGに変更します。
dmesgコマンドが使えるようになります。

この動作を確認するためのサンプルアプリを公開しています。
こちらの手順でapps/examplesディレクトリに追加してください。
以下の手順でサンプルアプリをファームに組み込みます。

$ make clean

              $ make menuconfig

Application Configuration > Examples で以下のアプリを追加してください。

新規アプリを追加したらひたすらExitで抜けます。
最後に以下の画面で[.config]を上書きします。

新しい[.config]を使ってファームウェアをビルドし、新しいファームウェアをマイコンに書き込みます。
nshに接続するとwq_testアプリが追加されています。

tickの引数で実行すると、1tick当たりの時間を表示します。
10m秒が1tickに相当します。

この値はこちらのメニューで変更することができます。

start1の引数で実行すると、1000m秒単位の定期処理(work1_loop)を開始します。
1000m秒はtick数に換算すると100tickに相当します。
work1_loopの結果はsyslogを使ってRAMLOGに記録されます。
dmesgでRAMLOGを見ると、100tick毎に処理を行っていることが分かります。
work1_loopのPIDはhpworkスレッドのPIDを引き継いでいます。
work1_loopはhpworkスレッドから呼び出されていて、hpworkの優先度を引き継ぎます。
hpworkの優先度は非常に高いので、関数内でsleepしてもsleepから復帰するとすぐに実行権を取り返します。
dmesgで表示したログはRAMLOGから消去されます。

start2の引数で実行すると、2000m秒単位の定期処理(work_loop2)を開始します。
2000m秒はtick数に換算すると200tickに相当します。
dmesgで200tick毎に処理を行っていることが分かります。
work_loop2のPIDはlpworkスレッドのPIDを引き継いでいます。
work_loop2はlpworkスレッドから呼び出されていて、lpworkの優先度を引き継ぎます。

stop1の引数で実行すると、work1_loopの処理を停止します。
stop2の引数で実行すると、work2_loopの処理を停止します。
定期処理が止まるのでRAMLOGには何も追加されなくなります。

APIの使い方に間違いがあるかもしれません。
こちらのドキュメントで確認してください。

ファームの書き込み方法と、nshへの接続方法はこちらに紹介しています。
STM32F4 Discovery
STM32F3 Discovery
STM32F103RB Nucleo
STM32F103 BluePill/BlackPill
STM32F103 VEボード
STM32F407 VGボード

続く．．．