LoRa STM32WB55
1.0.0
WIP
Status do projeto:
A idéia principal é poder usar o Shield Semtech Lora SX1272MB2DAS em uma placa de núcleos STM32WB55. Infelizmente, o código disponível por ST (I-Cube-Lrwan) para este escudo está disponível apenas para algumas placas de núcleos (L053RG, L073RZ, L152RE e L476RG).
As idéias derivadas são se casar com Lora e BLE, hoje em dia muitos objetos de IoT são acessíveis por vários motivos (configurações, provisões, fuota, ...), mas principalmente porque é compatível com smartphones. A série STM32WL não tem BLE e a STM32WB Serie não tem recursos de Lora.
Bem, tive a oportunidade de criar um par com SX1272 e WB55 e permitir uma combinação de dois chips para o projeto de IoT flexível. Lembre -se de que a série WB55 não se limita a Ble. O firmware do coprocessador pode lidar com protocolos laterais de 2,4 GHz, como ZigBee e OpenHread. Portanto, a combinação de comunicações de RF de longo alcance e alcance é interessante.
Este projeto é apenas uma porta de códigos e bibliotecas existentes, mas pode economizar tempo de configuração para alguns desenvolvedores, pois existem alguns problemas técnicos a serem resolvidos.
Com o próximo Lora 2,4 GHz, isso deve ser considerado como trabalho de transição. O SX1280 combinará comunicação de curto e longo alcance em um único chip. Você pode querer dar uma olhada mais de perto.
É fácil encontrar. O escudo semtech SX1272MB2XAS LORA MBED é o escudo compatível com Arduino e as placas de núcleos têm o conector correspondente. Resumo técnico:
Como mencionado, a série STM32WB55 é o alvo aqui e o P-nucleo-WB55RG é uma boa placa para brincar. Resumo técnico:
Uma vez conectado (é um acéfalo), aqui está o objeto resultante. 
Nunca se esqueça de conectar a antena antes de ligar as placas. Você pode danificar a saída do amplificador de RF (embora seja uma potência bastante baixa). Obviamente, comprar dois de cada um é um pouco necessário para o pingue -pongue.
| Pacote | Versão |
|---|---|
| STM32Cubeide | 1.7 |
| STM32CUBEMX | 6.3.0 |
| Fw_wb | 1.12.1 |
| I-Cube-lrwan | 2.0 |
A maior parte do código é coberta por ST e Semtech sublicensing. Confira os respectivos acordos para uso adequado:
| Componente | Direitos autorais | Licença |
|---|---|---|
| Fonte de aplicação original | Stmicroelectrônico | Contrato de licença ST SLA0044 |
| Pilhas de Lorawan® | Semtech | BSD revisado licenciado para peças semtech |
| Cortex®-m cmSis | Arm Ltd | BSD-3-cláusula ou licença Apache 2 |
Meu ambiente de desenvolvimento favorito é o Linux, mas as ferramentas ST também estão disponíveis para Mac e Windows. Os dois primeiros são mais fáceis de configurar, geralmente sem problemas ou problemas de motorista. Bem, já sabe isso.
Embora eu não seja um ótimo fã de Ides, o STM32CUDEIDE funciona bem e os plugins ST ajudaram (MX, Expansões de software download, ...). O STMICRO fornece um pacote de expansão de software para alguns escudos Lora. Como vinculado acima, é o I-Cube-Lrwan e contém projetos de exemplo e bibliotecas como drivers SX1272 de baixo nível (através do SPI) e da pilha Lorawan (1.0.3 compatível).
O projeto pode ser facilmente aberto no STM32CUDEIDE sem dependências. Todo o código não há necessidade de instalar o WB ou o Lorawan firmare a partir do ST. Abra o projeto e crie -o (testado no Linux e MacOS). No entanto, você precisa do firmware da pilha BLE instalada para o CPU2. Aqui, STM32WB5X_BLE_STACK_FULL_FW.BIN foi exibido. Todos os firmware das pilhas são fornecidos em Projetos/STM32WB_COPRO_WIRESSELY_BINARIES/STM32WB5X Diretórios do pacote de firmware STM32CUBEWB, bem como como programar as placas para isso. Ele precisa ser feito uma vez .
Todo o experimento precisava de algumas ferramentas extras. Usei o poderoso dongle USB NRF52840 com NRF Connect para o Desktop 3.7.0 (disponível no Linux, Mac e Windows) do semicondutor nórdico para testar a conexão BLE. Sei que os smartphones podem fazer isso, eu uso o LightBlue no iOS ou no Android, mas quando você mexe com uuids ou nomes de dispositivos, as plataformas tendem a se perder com seus dados em cache, por isso gosto de descobrir o que está acontecendo com ferramentas de desenvolvimento como as nórdicas.
Para a parte de Lorawan, o TTN é ótimo e eu escolhi comprar um gateway de Lorawan barato, um ttig (mais barato que os chapéus rak para Raspberry Pi) para testes locais. O gateway é codificado para os serviços TTN, mas deve haver uma maneira de se conectar ao seu próprio LNS.
Esse foi o primeiro passo. Fazer as coisas funcionarem e eu escolhi o exemplo de transmissão de RF de baixo nível para isso. Portar o código ST/Semtech foi uma questão de lidar com a reconfiguração do WB55 para:
Mapeamento de pinos entre a placa Nucleo WB55 e o SX1272MB2DAS SHIELD:
| SX1272MB2DAS | P-nucleo-STM32WB55 | Nome do pino do conector Arduino |
|---|---|---|
| Dio0 | PC6 | D2 |
| Dio1 | PA10 | D3 |
| Dio2 | PC10 | D4 |
| DIO3 | PA15 | D5 |
| NSS | PA4 | D10 |
| Sclk | PA5 | D13 |
| Miso | PA6 | D12 |
| Mosi | PA7 | D11 |
| REINICIAR | PC0 | A0 |
Portanto, nada incompatível à primeira vista. Conjunto de pinos SPI1, NSS e pinos de redefinição também estão ok. Mas aqui vem o primeiro hickup com as linhas IRQ. O PC6 usa a linha EXTI6 IRQ (EXTI9_5_IRQN), tudo bem, mas PA10, PC10 e PA15 compartilham a mesma linha de exti IRQ, que é exti15_10_irqn.
Portanto, a definição da interface de rádio foi modificada para corresponder à placa Nucleo-WB55 (SX1272MB2DAS_CONF.H). E os manipuladores IRQ foram modificados para verificar os estados do GPIO (DIOX) antes de chamar os manipuladores de IRQ SX1272 correspondentes (confira o arquivo de origem STM32WBXX_IT.C)
O RTC tem fonte de relógio definida como LSE.
O layout original do arquivo de projeto também foi ligeiramente modificado. A integração dos arquivos originais foi feita em um projeto gerado pelo MX (SX1272.ioc) para preservar a possibilidade de alterar o projeto. No entanto, alguns cautelosos devem ser tomados como um código conflitante talvez gerado.
A programação de duas placas com esse código funciona e, como esperado, a primeira placa que recebe uma resposta de pong a uma mensagem de ping se torna mestre que o outro se torna escravo . Fiz o status de LED refletir isso (como planejado anteriormente no código original). Um está piscando vermelho, onde o outro tem o LED verde piscando após um curto período de tempo: vídeo.
O código BLE é um MX completamente gerado. Ter um que funciona imediatamente não foi simples, pois muitas coisas precisam ser definidas corretamente no projeto MX (que poderia um artigo separado). Configurei um projeto de teste BLE separadamente para esse fim, uma vez que funcionou, mesclei o código no projeto Lora para fazer com que os dois corriam lado a lado.
Portanto, o software de teste BLE é apenas um código periférico de RHS (sensor de frequência cardíaca). É baseado em uma estrutura de timer completamente diferente, chamada servidor de timer de hardware (HW_TS). A Biblioteca Semtech Lora não se baseia nessa, mas em um utilitário STM32_Timer, com base no driver HAL RTC. Eu removi a biblioteca de utilitários e o adaptador RTC para que todo o projeto deite -se apenas em HW_TS. A biblioteca Lora realmente conta com uma API intermediária (timer.h), que foi fácil de reescrever para que o HW_TS seja usado. O aplicativo Ping Pong, por outro lado, depende da antiga biblioteca de serviços públicos. Algumas alterações feitas nessa parte fizeram com que todo o código dependesse apenas HW_TS.
Preciso mesclar os TaskIds definidos pelo aplicativo Ping Pong e pelo código BLE. Felizmente, os dois usam o utilitário STM32_SENECHER . Uma vez feito corretamente, fiz com sucesso o aplicativo Lora Ping Pong e uma aplicação de HRS BLE, executando simultaneamente e sem falhas na placa STM32WB55.
Modifiquei o código app_ble.c para que o nome publicado (visível) seja baseado no STM32 UDN para que possamos distinguir as placas em execução ao mesmo tempo.
Para uma demonstração útil, escrevi um serviço GATT dedicado para que ambas as placas pudessem ser interrogadas via BLE para que você possa saber qual papel o nó Lora possui (mestre ou escravo) e número de ping/pong enviado/recebido. Para isso, adaptei ligeiramente o código BLE, de modo que o LED azul reflete o estado de conexão BL. O serviço personalizado (não gerado pelo MX, é muito confuso), possui duas características, uma para conhecer a função do nó (mestre ou escravo após a sincronização de pingue -ppon. Aqui está a captura de tela do NRF conectada conectada às duas placas sincronizadas: 
Feito isso, eu preferia gastar mais tempo em um aplicativo LORA ligeiramente diferente, controlado pela BLE, que é a próxima etapa.
A pilha de Lorawan é a da Semtech fornecida no pacote I-Cube-Lrwan. É 1.0.3 compatível e inclui pacote de software de certificação se a certificação da Lora Alliance for necessária para o dispositivo final.
Novamente, o código depende de um invólucro RTC diferente da pilha BLE, por isso foi modificada para isso. O número de temporizadores foi aumentado porque a configuração inicial do HW TimerServer é muito limitada para a execução das duas pilhas simultaneamente (arquivo hw_if.h alterado após o IOC modificado).
O exemplo original, Lorawan End Node, envia um conjunto muito completo de dados, reduzi drasticamente o quadro de teste para um texto simples.
O dispositivo está definido para ingressar na rede usando OTAA, para que 3 elementos sejam necessários: Deveui, Joineui e AppKey. Deveui é um identificador exclusivo para um dispositivo de hardware e é construído a partir do STM32 "Número de série". O identificador JOINEUI (ou antigo appeui) é usado para separação de aplicativos no lado do servidor. O AppKey é muito importante (uma chave AES128) de que os Muts sejam mantidos muito secretamente. O código -fonte arbitrário o define como um valor que deve ser alterado para uso final. O segredo é feito pelo Código Semtech usando uma API de elemento seguro, no nosso caso, é um SE virtual, mas é muito conveniente se você usar um real.
O JUNINEUI e o AppKey são codificados no arquivo SE-Identity.h ( Lorawan_App_Key e Lorawan_Nwk_Key devem ser os mesmos valores para o OTAA, este último é usado para calcular o microfone e é necessário para que o junção seja válido no LNS).
Testar com TTN e TTIG Gateway fornece estes:
Para a parte declarativa.
Uma vez que as duas placas tiveram uma resposta positiva de seu respectivo junção.
Um serviço GATT especial foi escrito para expor:
| Atributo | Acesso | Comentário |
|---|---|---|
| Status | Ler | Se o juntrequest concluiu ou não |
| Deveui | Ler | Leitura de Deveui computado |
| JUNINEUI | Ler | Readout de junto com código hard -codificado/appeui |
| Dados | Escrever | Dados que serão enviados (16 bytes máx.). Padrões para "STM32WB55 aqui!" |
| Período | Escrever | Período em segundos em que os dados são enviados (padrão para 10 segundos) |
| Rssi | Ler | Atualizado quando a mensagem de downlink é recebida |
| Snr | Ler | Atualizado quando a mensagem de downlink é recebida |
Nota: Não mexa no período, há uma limitação do ciclo de trabalho de 1%. Com as configurações padrão, o módulo envia 15 bytes a cada 10 segundos. No SF7BW125, isso pode ser feito no período mais baixo de ~ 7 segundos.
Aqui, uma ilustração das características expostas quando conectado a ele:
continua
