組み込みシステム設計者のためのLIN2.0マイコン実装術（後編）　――スレーブ・ノード用ドライバ・ソフトウェア開発のポイント

● レスポンス衝突時のブレーク受信に注意

　同期バイト処理では，イベント・トリガ・フレーム時にレスポンスの衝突が起こった場合，注意が必要です．

　図11は，故意にこの現象を起こしたものです．図のいちばん下は，マスタ・ノードの送信波形です．イベント・トリガ・フレームのヘッダに続いて，レスポンスを送信しています（通常，別のスレーブ・ノードがレスポンスを送信するが，ここでは実験の便宜上，マスタ・ノードに送信させている）．

　中段の波形は，別のスレーブ・ノードがイベント・トリガのヘッダに対してレスポンスを送信しているものです．LINバスでは，ドミナント（"L"レベル）が優先されるので，たまたま(1)と(2)のような波形がタイミング良く重なると，LINバス上では(3)のように11ビットを超えるロー・パルスが生成されてしまう場合があります．ドライバ・ソフトウェアは，これをフレーム途中のブレークと解釈してしまう可能性があり，その場合，後に続くパルス列を計測してボーレート値を求めてしまいます．異常なボーレート値を算出しても±14％のガードをかけておけば，2度と通信できなくなるような状態に陥ることは免れます（コラム「ボーレート補正範囲のなぞ」を参照）．しかし，内部の処理状態は保護ID受信に遷移するので，次に来る正しいブレークをうまく認識できず，1フレーム受信しそこなってしまうかもしれません^注4．

 注4；保護ID以降の受信において，ロー・パルスをブレークと判断する方法には，先に述べたようにフレーミング・エラーを利用している．このため，ボーレートが大きく（±5％以上，±14%以内）ずれると，ブレークとは認識できず単なる受信エラーとなる可能性がある．

図11　衝突時のロー・パルス合成
同時に複数のノードが送信を行うと，LINバス上では負論理の論理和の波形となる．