作業進んでません。というわけで、別の話題を。

組込みの場合、OSなし、iTRONやVxWorksなどのリアルタイムOS、組込みLinuxなど、タスクやスレッドの管理をどう行うかがマチマチです。

OSなしの場合、タイマーを使ってタスク管理を行ったり、はたまた、

int main()
{
    init();

    for(;;) {
        application_task();
        bluetooth_task();
    }
}

みたいな、順次実行するだけの仕組だったりします。

送受信のタスク処理をどの場合でもポーティングできるように設計しておく必要があるわけです。

>> 続く

Bluetooth上位レイヤーの場合、処理は大きく分けて送信と受信があります。
当然受信はいつ来るかわからないイベントになります。
送信はアプリ側から要求があって行われますが、じゃあ送信処理はアプリ側のタスクで動かせばいいかと言うと、そうでもありません。

例えば接続処理などでは、アプリからの要求が完了するまでに相手からの受信が必要になります。
タイムアウトを指定して相手からの受信を待つインターフェースにすれば、シンプルで使いやすいかもしれませんが、その間はロックされてCPUパワーが無駄になります。
それにデータ送信で時間がかかる場合に、送信終了まで待っていてはやはりCPUパワーの無駄です。

1. 送信処理は別タスク
   　
   1. イベントドリブン方式でコールバックする 　
   2. 処理はすぐ返すけれども、処理が終わったかはアプリ側に確認させる
2. 送信処理はアプリ側タスク
   　
   1. 処理が終わるまでロックする

が考えられるのではないかと思います。もしくは複数用意しておくか。
接続処理とデータ送信は別方式というのも考えられます。
今後I/Fを考えながら決めていきますが、接続処理を途中でキャンセル可能にと考えると、別タスクになりますね。

また受信処理は受信割込みで行うことになるでしょうが、この処理に時間がかかるとデータの取りこぼしが起こるので、「割込みで行う処理は最低限」というのは鉄則です。
従って、受信したデータのパケット解析は受信割り込みではなく、別タスクになります。

なので、

1. 受信割込み処理
2. 送信割込み処理
3. 受信タスク
4. 送信タスク
5. アプリ側タスク

の５つの処理単位が存在するわけです。
勿論、OSなしの場合に後半３つを逐次実行しても、動作可能にしておく必要があります。

それに各処理単位間の通信をどうするかも考える必要があります。
OSなしだとやはりvolatileグローバル変数を経由しかないですね。

実はiTRONやVxWorksなどのリアルタイムOSを使ったことがないのです。
iTRONの仕様や解説を読んだことはありますが、かなり忘れているので、もう一度よく理解しておこうと思います。
最近はT-KernelやuT-Kernelなんかも出てきているので、こちらも調べておこうかな。
実際に触ってみた方がいいんですけどね。