2015/07/04

[nrf51]RTX ? (2)

自分でRTXをビルドせずとも、nRF51 SDKのサンプルにRTXで動くものが入っていた。
nRF51422向けだが、まあ大丈夫だろう。

ビルドしてみる前に、ソースの差分を見てみる。
ble_app_hrsと、ble_app_hrs_rtxのmain.cだ。
だいたいこんな感じだ。

  • タイマは、OSのしくみを使う
  • SoftDeviceからのBLEイベント通知は、メッセージボックスに詰めて投げるだけ。
    処理はble_stack_thread()というスレッド(uITRONでいうところのタスク)で行う。
  • sd_app_evt_wait()は、osDelay(1000)に置き換えられている

sd_app_evt_wait()は、SoftDeviceなしだとWFEみたいだが、SoftDeviceありだとSVCALLしている。
何か秘密があるんじゃないかと思ったんだけど・・・。
なんか、ちょっと納得がいってない。

RTXのosDelay()をたどると、__svcDelay()を呼んでいた。
svcDelay()という関数はあるのだが・・・。
こんな記載があり、マクロマクロして、SVCに変換されるようだ。

SVC_1_1(svcDelay,・・・・)

この辺が、nRF51 SDKがRTXをサポートしているという意味なのか。
でも、それだったら1秒じゃなくて、もっと長くすればいいのにという気もするが・・・何か違うのか・・・。

SVCはSoftDeviceと共有と書いてある。
だから、上記リンク先の表でも、RTXよりもS110の方が動作までに多くクロック数がかかるようになっているのだろう。
しかし、Application SVC interruptはS110の方が速くなっていて、何か腑に落ちない。
私がSVCをまだ理解できてないせいかもしれないので、本を読んでみよう。

[nrf51]RTX ? (1)

「ふふ、nRF51822には標準で使われるRTOSはなさそうだ。ここは私がTOPPERS/SSPを移植して、マイナー技術サイトから脱却するぜ」と思っていたかどうかは知らないが、TOPPERS/SSP周りを調べていた。

今朝、SWI0~5について調べていると、RTOSのことが出てきた。
いくつかOSが移植されているのは知っていたが、有名なものはないはず・・・
ん、ARM??

RTX Real-Time Operating System

いや、ARMがサイコーとか、そういうつもりはないのだが、IPの本家が出してきたとなると無視できない。
CMSISって、最初は評判がよくなかったような記憶があったので、全然気にしていなかったのだ。
そういう間に、世の中って動いていくのだね。

 

まずは、動かしてみよう。
ネットで情報が見つからなかったので、適当にやってみる。

まず、Keil v5を立ち上げよう。
どこかでソースだけダウンロードできるのかと思ったのだが、上記リンクの一番下に「MDKの全editionにソースがある」となっていたから、他ではダウンロードできないのだろう。

新規でプロジェクトを作って、nRF51822を選択。
次に進めると、こういうダイアログが出てきた。

image

まず、Keil RTXにチェックを入れる。
そうすると、左下のValidation Outputに「これが足りない」みたいな警告が出てくる。
それに全部チェックし、s110にもチェックすると、また警告が出てきたので、全部にチェックする。
OKをすると、こういうプロジェクトができた。

image

何も考えず、そのままビルドすると、エラーが2つ出た。
お楽しみはこれからってところですかね。


nRF51822で検索していたから見つけられなかったのだが、ソースだけのダウンロードもできるようだ。
こちらにBSDライセンス版(無料)のダウンロード先があったので、ダウンロードしてみた。
ARM: 無料版 リアルタイムOS RTX OS : BSDライセンス: マイコン風雲録

CMSIS_RTOS_RTX_V4P70.ZIP (3,437K)
Monday, March 18, 2013

 

GCCでもビルドできるようなので、うまくいけば試すかも。
ただ、RTXがあまり情報に出てこなかったのが気になっている。
ARMのお仕事をしていないので気付いていなかっただけかもしれないが、状況は気になりますな。

2015/07/03

[nrf51][ssp]Advertisingのタイムアウト (3)

割り込みハンドラをどうするかは考えればよいとして、SoftDeviceがどの割り込みをどう使っているのかは把握しておきたい。
周辺機器などはよいとして、SWI0~SWI5というのがどう使われているかは、ソースまで見ないとわからない。
でも、資料があるなら見たいです。

それっぽい質問が上がっていた。
how the swi0~swi5 interrupts triggered by softdevice? - Nordic Developer Zone
一番最後の回答に「SoftDevice Specification 2.0を読むとよいよ」とあるので、読んでみた。

S110-SDS / nRF51822(ログインしなくても読めるのかはわからん)
p.37にSWIの用途が書かれていた。
ARMのSWI命令は途中でSVCになったが、このSWIはそれとは別で、内部要因で発生させることができる割込らしい。
よくわからんが、そういうことができるんだろう。

p.36には、それぞれの割込について、アプリにとって制限あり(Restricted)なのか、アプリまでやってこない(Blocked)なのか、自由に使ってよい(Open)なのかが書いてある。
SWI2はRestrictedなので、nRF51 SDKを呼び出すようにするのがよいだろう。

 

SWI0は、アプリが使ってよいことになっている。
SVCのベクタは14だったと思うが、それとは別に使えるのか?
親切なことに、さっきのQAの人が「nrf_svc.hを見るとよいよ」と書いてくれている。
見ると、SVCALLマクロがそれに当たるようだ。
んー、私のイメージでは、SVCALLマクロを使うとSVC割込(14)が発生して、そのハンドラの中でswitch-caseするのだったのだけど、その0~5についてはSoftDeviceがSWI0~5に変換し、それ以外は自分の中で処理してしまうということかな?
うーむ。

前に悩んでいたSVCの値だが、これはp.38に範囲が書いてあった。
それ以外にも、いろいろ情報が書いてあるので、OSを移植するつもりなら読まないといかんのだろうな。。。

[nrf51][ssp]Advertisingのタイムアウト (2)

さて、前回わかったのは、Advertisingのタイムアウト時間になるとSWI2の割込が発生しているようだ、ということだった。

どのようにして確認したかというと、

  1. BLEスニファを立ち上げる
  2. nRF51のアプリを立ち上げる
  3. スニファでAdvertisingが止まるのを待つ
  4. デバッガで止める

だ。
うちはGNU環境なので、EclipseでGDBを使っているのだが、まあ他でも同じだろう。
もしかすると、有償の環境はもっとすごいのかもしれない。
有償の開発環境でうらやましいのは、ビルド以上にデバッグですな。

 

SoftDeviceを使った環境では、割り込みベクタはSoftDeviceが握っている。
Cortex-M0ではベクタオフセットレジスタがオプション扱いで、nRF51822ではレジスタがないから、変更できない。
動的にベクタが変わらないのは、デバッグとしてはやりやすい。迷わなくて済むし。

それ故、アプリが割り込みベクタと思って定義しているものは、単にSoftDeviceが関数呼び出しをするのに使っているベーブルだろうと思う。
SoftDeviceの中身を知らないし、デバッガで追ったわけでもないが、一度SoftDeviceが割り込みベクタから呼び出されたのにアプリの方まで呼んでいるというのは、そういうしくみになっているとしか思えない。

gcc_startup_nrf51.sを見ると、ベクタテーブルが定義されている。
この場所は、SoftDeviceが固定で呼び出すアドレスになるので、順番などは変更できない。
これを今はTOPPERS/SSPが使うようにしていて、自分のデフォルト割り込みハンドラに飛ばしている。
だから、OS無しのときはAdvertisingのタイムアウトによって呼ばれていたハンドラが呼ばれないのだ。

 

では、どうすべきか。
ITRONにならって、TOPPERS標準割り込み処理モデルを定義してから既存のSWI割込を呼び出すようにすべきか。
あるいは、既存の流れにそのまま載せるために、標準割り込み処理モデルをそこだけ使わないようにするか。
うーむ。

2015/07/01

[nrf51][ssp]Advertisingのタイムアウト (1)

githubに置いている、nRF51822+TOPPERS/SSPだが、Advertisingが1分続くと止まっている。
なぜだ!?

という話を書こうとしてソースを確認したのだが、app_ble.cのAPP_ADV_TIMEOUT_IN_SECONDSに、60秒って自分で定義してた。
そして、Advertising間隔は1秒。
念のため、30秒にしてみたら、30回のAdvertisingで止まった。

てへっ。

ではなく、SoftDeviceに対してタイムアウト時間を指定していた場合、どういうことが起きているのかを考えてみたい。
これは、SoftDeviceというある種のOSの中にuITRONを載せたがために起きていると思う。
なぜなら、今まではAdvertisingのTimeoutという通知がコールバックされていたから。


TOPPERS/SSPでは、TOPPERS標準割り込み処理モデル、という実装を使っている。
内容とかは知らないのだが、とにかくマイコンの割り込みハンドラが直接使われるのではなく、TOPPERSが一度吸収してハンドラを呼ぶようになっている。
これによってパフォーマンスとサイズは多少犠牲になるが、ハンドラ自体の移植性は高くなる。

「パフォーマンスの犠牲」は、性能が十分に引き出せない程度の意味なので、「速度パフォーマンスが犠牲になる」であれば処理速度が十分に出せてないことになるし、「省電力パフォーマンスが犠牲になる」であれば電力消費が無駄になっていることになる。
省電力に関しては、製品の要求などに関わってくるので、一般的な指標は出せないだろう。
電池を使わないモデルであればそもそも気にしないだろうし、100日持つか101日持つかみたいなところだと1日は誤差範囲だろうし。


そんな感じで、省電力をシステム依存で目一杯削減したい場合、汎用OSは導入できないだろう。
その代わり、汎用OSで使いたい機能は自分で実装することになり、苦労が増える。
汎用OSを使うなら、省電力は多少犠牲になるが、自分で実装する量が減るので、バグも減るだろう。
悩ましい。

 

そんなことを考えながら、誰がAdvertisingのタイムアウト割り込みを発生させているのか探してみたが、どうもSWI2のようだ。
ソフトウェア割り込みだ。