シリアル送信割込み

情報の送信処理関数（serial_send_byte）でシリアルに情報を流すわけですが、流しても可能かの判断を送信可能関数（serial_is_send_enable）で実施します。

SCIの送信バッファが１文字しか格納できない単純な構成であるため、前の文字の出力が完了するまでは、次の文字を与えられては困るため。

実はここに無駄があり、ビジーループで待ち合わせている間に別の処理はできずCPUが空回りしている状態。マルチスレッドならその間にほかの処理を進めることができるためCPUを無駄使いしていることになる。

①シリアル送信の割込みハンドラと、シリアル送信スレッドを作成。
②シリアル送信スレッドは送信要求を受けたら、送信バッファに送信する文字列を書き込み、先頭の一文字を送信。送信後には、割込み待ち状態に入る。
③１文字の送信が完了すると、シリアル送信割込みが発生。割込みハンドラでは送信バッファを参照し未送信の文字列が残っているならば次の１文字を送信する。
④送信が完了すると再度送信割り込みが入る。この手順が繰り返される。



スレッドと割込みのコラボは実際に動作させてみて行くことにする。

シリアル受信割込み

割込み処理は極力短くということでスレッドを登場させた。こんなかんじで設計。

①シリアル受信割込みのハンドラでは、受信文字を取り出す。そこからメッセージでコマンド応答スレッドに送信する。

②コマンド応答スレッドは、メッセージを受信したら文字を組み立ててコマンドとして解釈し、そのコマンドの処理を実施する。

このようにすれば、シリアル受信の割込みハンドラは、シリアル・コントローラのレジスタを見て受信文字を取得し、割込みのクリアを行い、コマンド応答スレッドに受信文字を送信するだけで済むことになります。

「割込み処理は極力短く書く」でスレッド作成

シリアル送受信をスレッドにすることをします。
「割込み処理は極力短く書く」という鉄則を守るためです。

そもそもなんでかというと、割込みの延長である処理を実施したときにその処理の最中は一切割込みを受け付けられなくなります。要はスレッド切替ができなくなるわけです。

たとえばシリアルからの受信文字を組み立ててコマンドとして解釈し応答するということを考えて見ます。

それなりに複雑な処理になるということで、これを割込みの内部で実施するには適さないのです。

そんな場合は、割込みハンドラですべての処理を実施するのではなく、処理用スレッドを別に起動しておいて、そちらに受信文字を渡してもらいたいという構造が適しています。