SWDR001
v2.5.2
このパッケージは、 LR11XX無線コンポーネントのドライバーのCでの実装を提案します。
ドライバーはいくつかのコンポーネントで分割されています。
このコンポーネントは、ファームウェアの更新に使用されます。
このコンポーネントは、レジスタまたは内部メモリからのデータの読み取り /書き込みに使用されます。
このコンポーネントは、クロックソース、統合されたRFスイッチなどのシステム全体のパラメーターと対話するために使用されます。
このコンポーネントは、異なるモデム（LORAおよびGFSK）を介してデータを送信 /受信するか、LORA CAD（チャネルアクティビティ検出）を実行するために使用されます。パワーアンプの選択、出力電力、フォールバックモードなどのパラメーターも、このコンポーネントを介してアクセスできます。
これにより、Sigfoxの機能も公開されます。 Bluetooth®-low-Energy-Beaconing互換性は、LR1110/LR1120のこのコンポーネントにも提供されています。
このコンポーネントは、LR-FHSS関連関数を提供します。
このコンポーネントは、ジオロケーションを要求するために共有できるWi-Fi信号のパッシブスキャンを構成および開始するために使用されます。
このコンポーネントは、ジオロケーションを要求するために共有できるGNSS信号の取得を構成および開始するために使用されます。
このコンポーネントは、内部キーチェーンのキーを設定および導出し、統合されたハードウェアアクセラレータを使用して暗号操作を実行するために使用されます。
このコンポーネントは、デバイスのLORAラウンドトリップ時間のフライト（RTTOF）機能の構成と操作に使用されます。
各コンポーネントは、異なるファイルに基づいています。
HAL（ハードウェア抽象化レイヤー）は、ユーザーがホストにプラットフォーム依存の呼び出しを書くために実装する機能のコレクションです。関数のリストは次のとおりです。
チップが保持によりスリープモードから目覚めると、パラメーターは適切に再構成されません。この誤解は、その後のすべての送信で、予想外に高い隣接するチャネル電力につながる可能性があります。
この問題は、500kHzと800kHzを除くすべての帯域幅について、Lora変調でのみ表示されます。
次のファームウェアバージョンが影響を受けます。
回避策は、チップが保持によりスリープモードから目覚めたときに、レジスタ0x00F30054のビット30をリセットすることです。
この回避策は、 LR11XX_RADIO_MODE_SLEEPがlr11xx_radio_auto_tx_rxで構成され、チップがRXモードに設定されている場合を解決しません。これは、保持によりスリープモードから目覚めた後にチップによって自動的に起動される、後続の送信の前に回避策を適用できないという事実の会費です。
ドライバーでデフォルトで有効にされている最初の実装は、送信にチップを設定できる各関数にパラメーターを更新する暗黙的な呼び出しを追加します - 直接かどうか -
lr11xx_radio_set_tx_with_timeout_in_rtc_steplr11xx_radio_set_tx_infinite_preamblelr11xx_radio_set_rx_with_timeout_in_rtc_step lr11xx_radio_auto_tx_rxが有効になっていますlr11xx_radio_set_cad -case in case LR11XX_RADIO_CAD_EXIT_MODE_TXはlr11xx_radio_set_cad_paramsで設定されていますこの実装は、Macro LR11XX_DISABLE_HIGH_ACP_WORKAROUNDを定義することにより無効にできます。この無効化は、将来、修正を統合する新しいファームウェアがリリースされ、回避策が必要ない場合に役立ちます。
この実装の主な利点は、アプリケーションを変更せずにドライバーを更新するだけでいいユーザーに対して透明であることです。主な欠点は、暗黙の呼び出しが必要でない場合でも体系的に行われることです。
2番目の方法では、ユーザーは、チップが保持とともにスリープモードから目覚めたときに関数lr11xx_radio_apply_high_acp_workaround明示的に呼び出す必要があります（注：実装を容易にするために、チップが任意のスリープモードから目覚めるときに呼び出されます）。
この方法では、Macro LR11XX_DISABLE_HIGH_ACP_WORKAROUNDを定義する必要があります。これにより、回避策の実装1（デフォルトで有効）が無効になっています。
次のファームウェアバージョンが影響を受けます。
チップが2.4 GHzバンドの受信を終了すると、パラメーターは適切に再構成されません。この誤解により、その後のGNSSスキャンが適切に機能することができなくなります。
2.4GHzバンドの受信とGNSSスキャンの間にチップが次の状態に入る場合、パラメーターが適切に再構成され、制限が表示されないことに注意することが重要です。
回避策は、GNSSスキャンを起動する前に、チップが2.4GHzバンドの受信を終了するときに、レジスタ0x00F30024にビット4を設定することです。
LR1110ファームウェアバージョンを使用する場合、この回避策は必要ありません。それにもかかわらず、回避策が非アクティブ化されていない場合、LR1110が適切に動作することを妨げません。
最初の実装 - デフォルトでドライバーで有効になっている - は、GNSSスキャンモードでチップを設定できる各関数にパラメーターを更新する暗黙的な呼び出しを追加します。
lr11xx_gnss_scanこの実装は、Macro LR11XX_DISABLE_MIXER_CFG_WORKAROUNDを定義することで無効にできます。この無効化は、将来、修正を統合する新しいファームウェアがリリースされ、回避策が必要ない場合に役立ちます。
この実装の主な利点は、アプリケーションを変更せずにドライバーを更新するだけでいいユーザーに対して透明であることです。主な欠点は、暗黙の呼び出しが必要でない場合でも体系的に行われることです。
2番目の方法では、ユーザーがこの制限の説明で指定された状態のいずれかを通過することなく、GNSSスキャンが計画されていない場合、チップが2.4GHzのレセプションを終了する場合、 lr11xx_gnss_apply_mixer_cfg_workaround lr11xx_gnss_apply_mixer_cfg_workaroundを明示的に呼び出す必要があります。
この方法では、Macro LR11XX_DISABLE_MIXER_CFG_WORKAROUNDを定義する必要があります。これにより、回避策の実装1（デフォルトで有効）が無効になっています。
