センサと接続する信号線のチェックを行うことができます。いうことは、エラーが検出されたからといってセンサ異常と判断するのではなく、配線異常と判断する必要もありそうです。DATARD8レジスタの内容は気圧データ(MSB)と兼用されていますが、EEPROMの「チェックサム計算結果」と気圧データが切り替わるタイミングがデータシートからは読み取ることができませんでした。少なくとも、センサ電源投入時はEEPROMのチェックサム結果を示すようです。なっているので診断を通過します。なる場合があるのではないでしょうか?今回公開したサンプルプログラムではマイコン側から積極的にセンサを初期設定することで問題回避(?)してます。(3)測定モード設定OPERATIONレジスタに測定モードを書き込むことでセンサは直ちに測定動作を開始します。低消費電力モードでは測定開始前に気圧データの分解能を指定することができます。この場合、CFGレジスタ(間接アクセスのみ)の値を変更する必要がありますが、指定しない場合の初期値は高解像度(17bitと称しています)です。現在測定中の場合は測定を停止してから新たな測定モードを指定することが必要です。・OPERATIONレジスタで測定停止を指示。・OPSTATUSレジスタで測定が停止していることを確認。・OPERATIONレジスタに新たな測定モードを指定。面倒な場合は、これですっきりします。(4)測定データ取得センサは測定完了後、DRDY信号をHighに切り替えます。マイコンはDRDYがHighであることを確認してから測定データを取得します。上図は定周期測定モードの例です。低消費電力モードではトリガを指定しない限りは測定が開始されませんが、測定が開始されれば上図と同様のデータ取得を行行います。続く測定の開始は、もちろんトリガの指定が必要です。DRDY信号の代わりにSTATUSレジスタのDRDYビットを確認する方法もありますが、ポーリングによるマイコン側の処理能力の低下を招く恐れがあるので勧められません(リアルタイムエラーを誘発する)。低消費電力モードの様な意識して測定開始(かつ、連続測定でない)を行うのであれば利用するメリットはあるかもしれません。■プログラム構成(1)はじめにサンプルプログラムの構成を「ざっくり」解説します。プログラムのステップ数は多くないので、プログラムを見た方が分かりやすいかもしれません。待ち、データを取得して表示を繰り返す構造です。当初は割り込み処理でセンサからのデータを取得すべきか考えましたが、動作タイミングを確認するため、また、シリアル通信を利用することから「割り込み処理なし」で処理を作成しました。割り込み処理は利用しませんが、割り込み要求フラグを利用しているので割り込み処理に置き換えることは容易です。今回使用したPIC12F683ではSPI通信をサポートしていません。そこで、汎用入出力ポートを利用した疑似的なSPI通信インタフェースを作成しました。信号操作のタイミング、例えばクロック信号の時間幅に対して積極的なウエイトは行っていません。原発振4MHzの実力で動作しています(「結果的な動作」とも言う)。高速の原発振を選択した場合、あるいは高度に最適化されたコンパイラやアセンブラを利用する場合は適度なウエイトが必要です。今回使用したPIC12F683ではシリアル通信をサポートしていません。そこで、汎用出力ポートを利用した疑似的な調歩同期式シリアル通信インタフェースを作成しました。調歩同期式シリアル通信ではビット時間が厳密に規定されます。今回はタイマ2をビット時間を生成するタイマとして利用しています。delay関数によるタイマを利用してもよいのですが、C言語でプログラムを作成しているので、コンパイラのバージョンにより処理時間のばらつきが発生する可能性があります。それ故タイマ2を利用し、そのコンペアマッチを監視することで時間のズレが少なく、かつ累積しないビットタイミングを作成しています。調歩同期式シリアル通信の「からくり」については別の機会で触れたいと思います。(5)通信データ測定だけでは動作が見えないので、測定結果を随時シリアル通信で出力しています(センサの測定周期に依存)。モニタ手段はパソコンに導入済みのターミナルソフトを利用しています。モニタ出力されるデータは助長的ですが、試食ということで御容赦。未使用バイナリデータを十進数に変換するための処理、シリアル通信処理を除外すれば半分以下の容量で済みます。結局はセンサとの通信処理よりも、人間との通信処理が大きなウェイトを占めています。これは仕方ありません。・データ変換(4バイト乗除算、2バイト乗除算他)です。気圧センサは定周期でマイコンに対して測定完了を通知しますが、測定データの読み出しが遅れるとリアルタイムエラーが発生しデータが抜け落ちてしまいます。今回試食を行うに当たりシミュレーションを利用して処理時間測定を行いました。その結果は「間に合う」でしたが、実際動作させてみないと分かりません。そこで、気圧センサのDRDY信号(Ch1:黄色)と調歩同期式通信(Ch2:桃色)の2つを実機でモニタしてみました。気圧センサからのDRDY信号は定周期で発生し、それに併せて調歩同期式通信が行われている...。Typ1.8Hz、約555ms周期です。確かに相当の時間でDRDY信号が変化しています。これに呼応する形でて調歩同期式通信が行われていることを確認しました。通信にかかわる時間が約50msでしょうか?ざっと見た感じでは絶対周期約555msに対して調歩同期式通信が約50ms。残約505msは「待ち」の時間です。約111ms周期)の場合でも今回のハード&ソフト構成で対応できそうです。何か重要なことを忘れてます。ソフトウェアで実現したSPI通信とデータ変換にかかわる時間が抜けています。処理の流れを見るとDRDY信号がセットされてからシリアル通信が始まるまでの間に処理があるはずです。確認したところでは数ms以内に完了していました。大した処理を行っているわけではないので、全体から見れば無きに等しい時間です。塵も積もれば山となる...とも言いますが、今回は試食なので(ry数百円で入手できるマイコンですが、いい仕事してます。(3)DRDY信号の落ちるタイミング気になったので調べてみました。気圧センサのDRDY信号(Ch1:黄色)、SPI通信のクロック信号(Ch2:桃色)になります。