SWDR001
v2.5.2
Ce package propose une implémentation en C du pilote pour le composant radio LR11xx .
Le conducteur est divisé en plusieurs composants:
Ce composant est utilisé pour mettre à jour le firmware.
Ce composant est utilisé pour lire / écrire des données à partir de registres ou de mémoire interne.
Ce composant est utilisé pour interagir avec les paramètres à l'échelle du système comme les sources d'horloge, les commutateurs RF intégrés, etc.
Ce composant est utilisé pour envoyer / recevoir des données via les différents modems (LORA et GFSK) ou effectuer une LORA CAD (détection d'activité de canal). Des paramètres comme la sélection de l'amplificateur de puissance, les modes de puissance de sortie et de secours sont également accessibles via ce composant.
Cela expose également les fonctionnalités de Sigfox. La compatibilité Bluetooth®-Low-Energy-Beaconing est également fournie dans ce composant pour LR1110 / LR1120.
Ce composant fournit des fonctions liées à LR-FHSS.
Ce composant est utilisé pour configurer et initier le balayage passif des signaux Wi-Fi qui peuvent être partagés pour demander une géolocalisation.
Ce composant est utilisé pour configurer et initier l'acquisition de signaux GNSS qui peuvent être partagés pour demander une géolocalisation.
Ce composant est utilisé pour définir et dériver des clés dans le clés interne et effectuer des opérations cryptographiques avec l'accélérateur matériel intégré.
Ce composant est utilisé pour configurer et exploiter la fonctionnalité de temps de vol aller-retour LORA de l'appareil (RTTOF).
Chaque composant est basé sur différents fichiers:
Le HAL (Mardware Abstraction Layer) est une collection de fonctions que l'utilisateur doit implémenter pour rédiger des appels dépendants de la plate-forme à l'hôte. La liste des fonctions est la suivante:
Lorsque la puce se réveille du mode de sommeil avec rétention, un paramètre n'est pas reconfiguré correctement. Cette mauvaise configuration peut conduire à une puissance de canal adjacente inattendue dans toutes les transmissions ultérieures.
Le problème n'apparaît que dans la modulation LORA, pour toutes les bandes passantes, sauf pour 500 kHz et 800 kHz.
Les versions du micrologiciel suivantes sont affectées:
La solution de contournement est de réinitialiser le bit 30 dans le registre 0x00F30054 lorsque la puce se réveille du mode de sommeil avec rétention.
Cette solution de contournement ne résout pas le cas où LR11XX_RADIO_MODE_SLEEP est configuré avec lr11xx_radio_auto_tx_rx et la puce est définie sur le mode RX. Il s'agit de cotisations au fait que la solution de contournement ne peut pas être appliquée avant la transmission ultérieure, automatiquement lancée par la puce après s'être réveillée du mode de sommeil avec rétention.
La première implémentation - activée par défaut dans le pilote - ajoute un appel implicite à jour le paramètre à chaque fonction qui pourrait définir la puce en transmission - directement ou non -:
lr11xx_radio_set_tx_with_timeout_in_rtc_steplr11xx_radio_set_tx_infinite_preamblelr11xx_radio_set_rx_with_timeout_in_rtc_step - Dans le cas où lr11xx_radio_auto_tx_rx a été activélr11xx_radio_set_cad - Dans le cas où LR11XX_RADIO_CAD_EXIT_MODE_TX a été défini avec lr11xx_radio_set_cad_params Cette implémentation peut être désactivée en définissant la macro LR11XX_DISABLE_HIGH_ACP_WORKAROUND . Cette désactivation sera utile lorsque, à l'avenir, un nouveau firmware intégrant un correctif est publié et ne nécessite plus la solution de contournement.
Le principal avantage de cette implémentation est qu'il est transparent pour l'utilisateur qui n'a besoin de mettre à jour le pilote sans modifier son application. L'inconvénient principal est que l'appel implicite est effectué systématiquement même lorsqu'il n'est pas nécessaire.
La deuxième méthode nécessite que l'utilisateur appelle explicitement la fonction lr11xx_radio_apply_high_acp_workaround Lorsque la puce se réveille à partir du mode de sommeil avec rétention (Remarque: Pour soulager l'implémentation, il peut être appelé lorsque la puce se réveille à partir de n'importe quel mode de sommeil).
Cette méthode nécessite que le macro LR11XX_DISABLE_HIGH_ACP_WORKAROUND soit défini afin que l'implémentation 1 de la solution de contournement (activée par défaut) soit désactivée.
Les versions du micrologiciel suivantes sont affectées:
Lorsque la puce termine une réception dans la bande 2,4 GHz, un paramètre n'est pas reconfiguré correctement. Cette mauvaise configuration empêchera un scan GNSS ultérieur de fonctionner correctement.
Il est important de noter que si la puce entre dans l'un des états suivants entre la réception dans la bande 2,4 GHz et le scan GNSS, le paramètre est correctement reconfiguré et la limitation n'apparaît pas:
La solution de contournement est de régler le bit 4 dans le registre 0x00F30024 lorsque la puce termine une réception dans la bande 2,4 GHz avant de lancer un scan GNSS.
Cette solution de contournement n'est pas nécessaire lors de l'utilisation d'une version du micrologiciel LR1110. Néanmoins, il n'empêche pas un LR1110 de fonctionner correctement si la solution de contournement n'est pas désactivée.
La première implémentation - activée par défaut dans le pilote - ajoute un appel implicite à jour le paramètre à chaque fonction qui pourrait définir la puce en mode d'analyse GNSS:
lr11xx_gnss_scan Cette implémentation peut être désactivée en définissant le macro LR11XX_DISABLE_MIXER_CFG_WORKAROUND . Cette désactivation sera utile lorsque, à l'avenir, un nouveau firmware intégrant un correctif est publié et ne nécessite plus la solution de contournement.
Le principal avantage de cette implémentation est qu'il est transparent pour l'utilisateur qui n'a besoin de mettre à jour le pilote sans modifier son application. L'inconvénient principal est que l'appel implicite est effectué systématiquement même lorsqu'il n'est pas nécessaire.
La deuxième méthode nécessite que l'utilisateur appelle explicitement la fonction lr11xx_gnss_apply_mixer_cfg_workaround lorsque la puce termine une réception dans la 2,4 GHz si un scan GNSS est planifié après, sans passer par l'un des états spécifiés dans la description de cette limitation.
Cette méthode nécessite que le macro LR11XX_DISABLE_MIXER_CFG_WORKAROUND soit défini, de sorte que l'implémentation 1 de la solution de contournement (activée par défaut) est désactivée.
