[ble][nrf51]スケジューラーって、何よ？

まだ電池を使った開発をしているわけじゃないけど、消費電力にはケチな私。
消費電力を抑えるためには、個々の消費が小さいのはもちろんだけど、消費しなくてよいようなシステムにするのが一番なのよね。

それはともかく。
個々の消費電力を抑える一般的な考え方は、こうなるだろう。

• なるべく長い時間、寝る
• 用があるときになったら、起きる
• 起きる時間は極力短くする

nRF51822の場合、動作クロックは16MHzで、低周波クロックとして32.768kHzがある。
感覚的にわかると思うが、32kHzで動く方が16MHzで動くよりも消費電力は少ない。
CPUとしては、動作するクロックの間隔が違うだけなので、同じことをするのに時間がよりかかるようになるだけだ。
まあ、機能によっては周波数が低いと動かせないものなんかもあるだろうが、まあ、そこは置いておこう。

「寝る」ときは、何もしたくないので、動作クロックは低い方にしておいた方が得だ。
でも、そこから「起きる」ことを考えると、簡単にはいかない。
寝てる状態から起きるためには、ハードウェアの力を借りることがほとんどだ。
だいたいが「割込み」を使うことになるだろう。
人間でいえば、たたいて起こすようなものか。

動作クロックを低くした状態で起こされたとき、それは非常に人間っぽい。
「なになに？」みたいな感じで、低い周波数で動くことになるからだ。
そこから、まずは動作クロックを高い方に持っていきたいだろう。
が、クロックは急には立ち上がらない。
それなりに動作が安定するまでに時間がかかるのだ。
安定するまで待って、動作クロックを高い方に切り替える、という感じか。
それに、「たたいて」から「たたかれた」がわかるまでも低い周波数で動くので、眠った状態からハイテンションになるまでには結構な時間がかかるのだ。

16000kHz・・・1クロックが62.5μ秒
00032kHz・・・1クロックが31.25m秒

単位がそもそも違うね。
マイコンとかの説明が、時間じゃ無くてクロックで書いてある理由がわかるであろう。
彼にとっての時間が「100」だったとしても、動かしている側から見ると、16MHzなら「6.25ミリ秒」で、32kHzなら「3.2秒」みたいなことになるからだ。

---

で、だ。
nRF51822だって、いやSoftDeviceだって、そういうことは十分に考えていると思うのだ。
BLEの「LE」はLow Energyなんだから、制御するSoftDeviceが電力制御をしてくれないと困るのだ。

s110のサンプルを見ていると、ぐるぐると監視するのではなく、スケジューラなるものを使っているっぽい。

static void power_manage(void)
{
    uint32_t err_code = sd_app_evt_wait();
    APP_ERROR_CHECK(err_code);
}
main()
{
    (略)
    for (;;)
    {
        app_sched_execute();
        power_manage();
    }
}

使っているようなんだけど、それが何をどうしてくれるのかわからない。

このまま泣き寝入りするしか無いのか・・・と思ったが、よく考えるとSoftDeviceの部分は非公開だけど、そうじゃない部分はかなりソースがあるんだった。
ただ、ここらへんは契約というか登録をしていないとダウンロードできないものだから、ここら辺に書くことができない。
うーん・・・nRF51822の普及をさせたいけど、SoftDeviceなしで話をするのは難しいから、どうやると深い話ができるんだろうか・・・・。

とりあえず、ここら辺のソースを実行すると、wfeを実行しているようだ、ということは伝えてもよいんじゃ無かろうかね。