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のようだ。
ソフトウェア割り込みだ。
0 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。