hobbylab.jp 部品オペアンプ_関係 Si4735 マニュアル 0x14

ステータスバイトのビット6～0を更新します。このコマンドは、STCINT、RDSINT、またはRSQINTビットを設定するコマンドの後に実行する必要があります。ポーリングを行う場合は、このコマンドを定期的に実行してステータスバイトを監視する必要があります。割り込みを使用する場合は、割り込みが設定された後にこのコマンドを実行してステータスバイトを更新する必要があります。 CTSビット（およびオプションの割り込み）は、次のコマンドを安全に送信できるときに設定されます。このコマンドは、電源投入モードのときのみ設定できます。
使用可能環境：すべて
コマンド引数：なし
応答バイト：なし

2 コマンドパラメータ

2.1 パラメータリスト

Bit	D7	D6	D5	D4	D3	D2	D1	D0
CMD	0	0	0	1	0	1	0	0

2.2 パラメータ

なし

3 応答パラメータ

(FUNC = 1 [AM]の場合 ※は有りません)

3.1 パラメータリスト

Bit	D7	D6	D5	D4	D3	D2	D1	D0
STATUS	CTS	ERR	X	X	RSQINT	※ RDSINT	X	STCINT

3.2 パラメータ

応答の先頭パラメータ

応答（STATUSバイト）に含まれる各ビット（CTS, ERR, RSQINT, RDSINT, STCINT）は、「デバイスの現在の処理状態」や「各種割り込み（通知）の発生」をホストMCUに知らせる目的で設計されています。 STATUSバイトの信頼性:Si4735の仕様上、いくつかのコマンド送信時に返ってくるSTATUSバイトでは、CTS以外の割り込みビット（RSQINT, RDSINT, STCINTなど）がリアルタイムに更新されない場合があります。
正しい確認方法:正確な割り込みステータスを確認したい場合は、STATUSバイトを直接過信するのではなく、専用の割り込み確認コマンド（例：GET_INT_STATUS (0x14) コマンドなど）を明示的に発行して最新の状態を読み出すのが一般的なセオリーとなっています。

3.2.1 CTS(Clear to Send)

目的:

デバイスが次のコマンドを受け付けられる状態かどうかを判定する。

解説:

最も重要なビットです。Si4735が前のコマンドの処理を完了し、「次のコマンドを送信しても安全（送信可）」になると1にセットされます。
0の間はデバイスが内部処理中（ビジー）であるため、ホストMCUは次のコマンド送信を待機する必要があります。

3.2.2 ERR(Error)

目的:

直前に送信したコマンドが正常に実行されたか、エラーが発生したかを判別する。

解説:

コマンドの引数（引数の値が範囲外など）や、無効なコマンドが送られた場合に1にセットされます。
ホスト側のプログラムで例外処理や再試行（リトライ）を行うために使用します。

3.2.3 RSQINT(Received Signal Quality Interrupt)

目的:

受信信号の品質（電界強度RSSIやSNRなど）が、あらかじめ設定した閾値を超えた（または下回った）ことを通知する。

解説:

「受信品質の変化」をトリガーに処理を行いたい場合に使用します。
例えば、現在のチャンネルの電波が急激に弱くなったことを検知して自動で再スキャンをかける、といった機能を実装する目的で利用されます。

3.2.4 RDSINT(Radio Data System Interrupt)

目的:

RDS（文字情報などのデータ放送）のデータバッファ（FIFO）に新しいデータが格納されたことを通知する。

解説:

FM放送などで送られてくる「RDS/RBDSデータ（番組名や楽曲情報など）」を受信した際に1になります。
ホストMCUはこのビットを見てからデータを読み出す（FM_RDS_STATUS コマンドを発行する）ことで、無駄な空読みを防ぎ効率的にテキストデータを取得できます。

3.2.5 STCINT(Seek/Tune Complete Interrupt)

目的:

選局（Tune）操作または自動選局（Seek）操作が完了したことを通知する。

解説:

周波数を変更するコマンド（FM_TUNE_FREQ や FM_SEEK_START など）は内部処理に時間がかかります。
デバイスが「目的の周波数への同調、または次の放送局の検知を完了した」時点でこのビットが1になります。
選局完了のタイミングを正確に把握する目的で使用します。

4 その他

4.1 コマンドの重要ステップと注意事項(Google AI (Gemini) の見解)

Silicon LabsのDSPラジオIC「Si4735」における0x14 (GET_INT_STATUS) コマンドは、デバイス内部で発生した各種割り込み（インタラプト）のフラグ状態を更新・取得するための重要なコマンドです。
選局の完了や、RDSデータの受信、オーディオ状態の変化をマイコン側へ通知する仕組みの基礎となる本コマンドについて、注意点、応用展開、およびGoogle AI (Gemini) の見解をまとめます。 0x14 コマンドは引数（ARG）を持たず、コマンド「0x14」を送信した後に1バイトのステータスバイトを読み出します。
非常に軽量なコマンドですが、正しくフラグを処理するためのルールがあります。

4.1.1 ステータスバイトの「下位ビット」を更新する特殊性

通常、I2Cでステータスバイトをただ読み出すだけでも最上位ビットの CTS（Clear to Send）は確認できますが、下位の割り込みビット（STCINT、RDSINTなど）は、この 0x14 コマンドを発行した直後でなければ最新状態に更新されません。
単にI2CのREADシーケンスで1バイト読み出すだけでは、古い割り込み情報を見たままループが抜けられなくなる（ハングアップする）原因になります。必ず「0x14 送信 ➔ CTS待ち ➔ ステータス読出し」の順で実行してください。

4.1.2 割り込みの「クリア（応答・Ack）」処理との連動

0x14 で割り込み（例：選局完了を示す STCINT）が発生していることを確認した後は、対応する確認コマンド（例：選局状態を取得する 0x22 など）に特定の引数を載せて発行し、フラグをクリア（Ack）しなければなりません。
フラグをクリアしないと、Si4735の物理割り込みピン（IRQ ピン）が「Low」に張り付いたままになり、次回以降の新しい割り込みを検知できなくなります。

4.1.3 パワーアップ状態の必須条件

本コマンドは、デバイスが 0x01 (POWER_UP) されて動作している状態でなければ受け付けられません。パワーダウン中に発行しても無効となります。

4.2 もう少し踏み込んだ応用展開(Google AI (Gemini) の見解)

0x14 コマンドを使いこなすことで、マイコンの処理負荷を劇的に下げたり、バックグラウンドでの高度なデータ受信処理が可能になります。

4.2.1 物理IRQピンを用いた「完全非同期・省電力イベント駆動」

多くの簡易的なサンプルコードでは、選局（Seek/Tune）の完了を待つために、マイコンが while 文で 0x14 を何度も連打（ポーリング）する実装になっています。
しかしこれではマイコンが占有され、電力も消費します。
展開例: Si4735の GPO1/IRQ ピンをマイコンの外部割り込みピン（Arduinoの attachInterrupt() など）に接続します。
普段マイコンは別の処理（画面描画など）をするかスリープしておき、ピンがLowになった瞬間だけ割り込み関数（ISR）内で 0x14 を一発叩いて原因（選局完了か、RDS受信か）を特定するという、スマートなイベント駆動型システムへ展開できます。

4.2.2 バックグラウンドRDS/RBDSデータデコーダ（FMモード時）

FM放送のテキスト情報（番組名や曲名）であるRDSデータを受信する場合、データが届くたびに内部で RDSINT（RDS割り込み）が発生します。
展開例: メインループの中で定期的に 0x14 を発行（または上記IRQピンと連動）し、RDSINT が「1」になった時だけ 0x24 (FM_RDS_STATUS) コマンドを呼び出してデータを吸い上げます。
これにより、ラジオの音声を一切途切れさせることなく、液晶画面に現在流れている「曲名」をリアルタイムに自動スクロール表示させる高度なレシーバーを構築できます。

4.3 主な割り込みフラグ（ステータスバイトの構造）

0x14 発行後に更新される、ステータスバイト（1バイト）内の主要なビットです。

ビット位置	名称割り込みの意味（「1」で発生）	クリア（Ack）するためのコマンド
Bit 7	CTSコマンド受付可能状態（割り込みではない）	（自動で制御される）
Bit 2	RDSINT新しいRDS（FMテキスト）データを受信した	0x24 (FM_RDS_STATUS) を送る
Bit 1	ASQINT音声品質（過変調や無音など）に変化があった	0x23 / 0x43 (RSQ_STATUS) を送る
Bit 0	STCINT選局（Tune）やシーク（Seek）の処理が完了した	0x22 / 0x42 (TUNE_STATUS) を送る

4.4 その他Google AI (Gemini) の見解

Si4735のマルチタスクファームウェア設計において、Google AI (Gemini) は「UI（操作性）の応答性と、DSPの内部処理タイムラグを分離するための防波堤」として 0x14 を評価しています。

4.4.1 シーク（自動選局）時のフリーズ回避に対する見解:

短波（SW）やAMで自動選局（Seek）を行う際、電波の弱い地域では次の放送局を見つけるまでにIC内部のDSPが数百ミリ秒以上の時間を要することがあります。
Geminiの見解としては、この選局待ちの間にマイコンをブロッキング（ビジーループで待機）させてしまうと、ユーザーが「キャンセルボタン」を押しても反応しない最悪のUIになってしまいます。
ここで 0x14 を非ブロッキング（タイマーで数十ミリ秒に1回だけチェックする、または物理IRQピンに逃がす）にすることで、「自動選局の裏で、ボタン入力やボリューム変更をいつでも受け付けられる、フリーズしない洗練されたラジオ」が実現できると指摘します。

4.4.2 SSB/AMにおける音質変化のリアルタイム監視（ASQの活用）

短波帯のSSBやAMでは、フェージング（電波強度の周期的な変動）が激しく発生します。
Geminiの見解では、0x14 を介して ASQINT（オーディオシグナルクオリティ割り込み）を監視し、電波が急激に弱くなった（またはノイズが増えた）ことを検知した瞬間に、先述の 0x12 (SET_PROPERTY) を使って「自動でフィルタ幅を狭くする（またはミュートを強める）」といった動的な環境適応型インテリジェント・オーディオ制御を実装するトリガーとして、0x14 は必要不可欠なコマンドであると見なしています。