SWDR001
v2.5.2
Este pacote propõe uma implementação em C do driver para o componente de rádio LR11XX .
O motorista está dividido em vários componentes:
Este componente é usado para atualizar o firmware.
Este componente é usado para ler / gravar dados de registros ou memória interna.
Este componente é usado para interagir com parâmetros em todo o sistema, como fontes de relógio, interruptores de RF integrados, etc.
Este componente é usado para enviar / receber dados através dos diferentes modems (LORA e GFSK) ou executar um LORA CAD (detecção de atividade do canal). Parâmetros como a seleção do amplificador de potência, os modos de potência de saída e fallback também são acessíveis através deste componente.
Isso também expõe recursos para o Sigfox. A compatibilidade com Bluetooth®-Low-Low-Energy-Baconing também é fornecida neste componente para LR1110/LR1120.
Este componente fornece funções relacionadas ao LR-FHSS.
Esse componente é usado para configurar e iniciar a varredura passiva dos sinais Wi-Fi que podem ser compartilhados para solicitar uma geolocalização.
Este componente é usado para configurar e iniciar a aquisição de sinais GNSS que podem ser compartilhados para solicitar uma geolocalização.
Esse componente é usado para definir e derivar teclas no chaveiro interno e executar operações criptográficas com o acelerador de hardware integrado.
Esse componente é usado para configurar e operar o recurso Lora-ida e volta do dispositivo (RTTOF).
Cada componente é baseado em diferentes arquivos:
A HAL (camada de abstração de hardware) é uma coleção de funções que o usuário deve implementar para gravar chamadas dependentes da plataforma para o host. A lista de funções é a seguinte:
Quando o chip acorda do modo de suspensão com retenção, um parâmetro não é reconfigurado corretamente. Essa configuração incorreta pode levar a uma potência inesperadamente alta do canal adjacente em todas as transmissões subsequentes.
A questão aparece apenas na modulação de Lora, para todas as larguras de banda, exceto 500kHz e 800kHz.
As seguintes versões de firmware são afetadas:
A solução alternativa é redefinir o bit 30 no registro 0x00F30054 quando o chip acorda do modo de suspensão com retenção.
Esta solução alternativa não resolve o caso em que LR11XX_RADIO_MODE_SLEEP está configurado com lr11xx_radio_auto_tx_rx e o chip está definido como o modo RX. Isso é de quotas para o fato de que a solução alternativa não pode ser aplicada antes da transmissão subsequente, lançada automaticamente pelo chip depois de acordar do modo de suspensão com retenção.
A primeira implementação - ativada por padrão no driver - adiciona uma chamada implícita atualizando o parâmetro a cada função que pode definir o chip na transmissão - diretamente ou não -:
lr11xx_radio_set_tx_with_timeout_in_rtc_steplr11xx_radio_set_tx_infinite_preamblelr11xx_radio_set_rx_with_timeout_in_rtc_step - Caso lr11xx_radio_auto_tx_rx foi ativadolr11xx_radio_set_cad - Caso LR11XX_RADIO_CAD_EXIT_MODE_TX foi definido com lr11xx_radio_set_cad_params Esta implementação pode ser desativada definindo o macro LR11XX_DISABLE_HIGH_ACP_WORKAROUND . Essa desativação será útil quando, no futuro, um novo firmware que integra uma correção é liberado e não exige mais a solução alternativa.
A principal vantagem dessa implementação é que ela é transparente para o usuário que só precisa atualizar o driver sem alterar seu aplicativo. A principal desvantagem é que a chamada implícita é feita sistematicamente, mesmo quando não é necessária.
O segundo método exige que o usuário chame explicitamente a função lr11xx_radio_apply_high_acp_workaround quando o chip acorda do modo de suspensão com retenção (Nota: Para facilitar a implementação, ele pode ser chamado quando o chip acordar de qualquer modo de sono).
Este método requer que o macro LR11XX_DISABLE_HIGH_ACP_WORKAROUND seja definido para que a implementação 1 da solução alternativa (ativada por padrão) esteja desativada.
As seguintes versões de firmware são afetadas:
Quando o chip termina uma recepção na banda de 2,4 GHz, um parâmetro não é reconfigurado corretamente. Essa configuração incorreta impedirá que uma varredura GNSS subsequente funcione corretamente.
É importante observar que, se o chip entrar em um dos seguintes estado entre a recepção na banda de 2,4 GHz e a varredura GNSS, o parâmetro será reconfigurado corretamente e a limitação não aparece:
A solução alternativa é definir o bit 4 no registro 0x00F30024 quando o chip terminar uma recepção na banda de 2,4 GHz antes de lançar uma varredura GNSS.
Esta solução alternativa não é necessária ao usar nenhuma versão do firmware LR1110. No entanto, não impede que um LR1110 funcione corretamente se a solução alternativa não for desativada.
A primeira implementação - ativada por padrão no driver - adiciona uma chamada implícita atualizando o parâmetro a cada função que pode definir o chip no modo de varredura GNSS:
lr11xx_gnss_scan Esta implementação pode ser desativada definindo o macro LR11XX_DISABLE_MIXER_CFG_WORKAROUND . Essa desativação será útil quando, no futuro, um novo firmware que integra uma correção é liberado e não exige mais a solução alternativa.
A principal vantagem dessa implementação é que ela é transparente para o usuário que só precisa atualizar o driver sem alterar seu aplicativo. A principal desvantagem é que a chamada implícita é feita sistematicamente, mesmo quando não é necessária.
O segundo método exige que o usuário chame explicitamente a função lr11xx_gnss_apply_mixer_cfg_workaround quando o chip termina uma recepção nos 2,4 GHz se uma varredura GNSS for planejada após, sem passar por um dos estados especificados na descrição dessa limitação.
Este método requer que o macro LR11XX_DISABLE_MIXER_CFG_WORKAROUND seja definido para que a implementação 1 da solução alternativa (ativada por padrão) esteja desativada.
