Get best of the week

O que é o novo nRF Connect SDK for Nordic? Evolução, revolução ou alternativa?

Na semana passada, a Nordic Semiconductor adicionou o suporte da série nRF52 ao nRF Connect SDK.



A principal questão que a maioria das pessoas tem é o que é e por que é importante? Esta pergunta é especialmente relevante para aqueles que têm experiência com o nRF5 SDK, e existem muitos deles.

Observo imediatamente que o artigo foi escrito principalmente para aqueles que usam abordagens tradicionais no desenvolvimento de dispositivos Cortex-M ou de dispositivos próximos. Portanto, algumas definições e analogias podem não parecer completamente corretas do ponto de vista daqueles que trabalham em um nível alto (olha o que está acontecendo no lado Linux), mas será mais fácil de entender para aqueles que estão começando dessa maneira.

Comentários e esclarecimentos são sempre bem-vindos.

Um pouco sobre quem é nórdico e como eles estão indo bem agora
Nordic . , , Bluetooth Low Energy, 90% . : Starline, Pandora, Scher-Khan . Redmond, Ready4Sky. . 2 .

Nordic Semiconductor 40%, 2.5 , (TI). , . , Samsung Xiaomi Nordic , , .

, Nordic, , . nRF5x STM ( ).

:

  • ( )
  • SDK
  • ( )
  • Altium

, Nordic Semiconductor .

Aqui surge a principal questão: por que o novo SDK foi lançado e como ele difere do atual? Nesse caso, está tudo bem com a solução atual.

O atual nRF5 SDK funciona com base em uma fila simples e, na maioria dos casos, isso é suficiente para implementar praticamente qualquer tarefa (embora algumas empresas ainda usem seus próprios SDKs, mas essas são exceções às regras). O novo nRF Connect SDK usa uma abordagem radicalmente diferente, baseada no Zephyr RTOS. Considere as diferenças em mais detalhes.
O RTOS (RTOS) traz certas vantagens e desvantagens conhecidas. Estes últimos incluem:

  • sobrecarga adicional para manter o sistema operacional
  • grande complexidade de desenvolvimento em projetos simples
  • maior complexidade de compilação

O restante dos RTOS são:

  • maior confiabilidade devido ao controle de fluxos individuais

Na Nordic, isso se tornou interessante e relevante desde a introdução do novo sistema em pacote (SIP) com LTE Cat-M / NB-IoT / GPS - a série nRF91. Esse SIP tem desempenho superior devido ao novo núcleo Cortex-M33 e outros requisitos para o componente de rede, que surgiram devido à transição do BLE para as redes celulares. Outra inovação aqui foi o modem SDR, que funciona em um núcleo separado e com o qual foi necessário organizar a interação internuclear. Pela primeira vez, o SDK baseado em RTOS apareceu aqui e, para aqueles que encontraram uma nova abordagem pela primeira vez, levantou várias questões, começando na fase de preparação. Um assistente especial também foi lançado para a montagem correta do ambiente de desenvolvimento - Assistente de Introdução. Ele informa quais componentes você precisa instalar (existem muitos deles, veja abaixo) e verifica se tudo está instalado corretamente.

imagem

Deste ponto de vista, podemos comparar a transição para Zephyr com a aparência do primeiro ARM Cortex-M em massa e a transição para 32 bits. Agora a maioria usa MKs de 32 bits como principais, sobre os quais há um artigo sobre Habré. Ele também fala sobre a transição, que inicialmente parecia desnecessariamente complicada. Mas com o tempo, quase todo mundo chegou à conclusão de que isso se tornou o padrão.

Vale ressaltar que o Zephyr OS não é o único RTOS rodando em chips nórdicos. Exemplos de projetos com o FreeRTOSDisponível no SDK v.11 a partir de 2016, e ainda mais cedo no SDK v.9 havia suporte Keil RTX para a família nRF51 (2015). No entanto, anteriormente, essas eram mais funções experimentais e o suporte era fornecido em maior medida pelos fabricantes de RTOS. O que, em princípio, é verdade agora.

O suporte não oficial do Zephyr para as famílias nRF5x apareceu em 2016 .

A Zephyr Nordic decidiu criar um SDK completamente novo no RTOS agora.

Há vários pré-requisitos para isso:

  • Várias tecnologias são herdadas do Linux:

    • trabalhar com fluxos, filas em tempo real (especialmente importante para protocolos dependentes de tempo, como o BLE)
    • bibliotecas para rede e segurança
    • modelo flexível de descrição de hardware com otimização de energia
    • bibliotecas para trabalhar com periféricos (sensores, etc.)

  • :




    • , Nordic,

  • ( )
  • ( ) . , , .

Para entender como ocorreram mudanças dramáticas, o diagrama estrutural da documentação oficial é adequado. Cinza indica os componentes que fazem parte do Zephyr.

imagem

Na prática, ao implementar essa abordagem, surgem vários problemas cognitivos. Os desenvolvedores acostumados ao produto e às soluções experimentam dissonância com um grande número de alterações.

Considere a versão do desenvolvimento no Windows, pois isso causará mais perguntas sobre aqueles que estão acostumados a desenvolver no Linux.

Os seguintes pacotes são necessários:

  • Chocolatey (gerenciador de pacotes)
  • Git (sistema de controle de versão)
  • Ninja (sistema de compilação orientado à velocidade)
  • CMake (sistema de compilação de alto nível)
  • DTC-MSYS2 ( (device tree))
  • GPerf ( )
  • west ( )
  • pip ( Python)
  • Python3
  • GNU Arm Embedded Toolchain (GCC, GDB ARM)

Para alguém que se depara com um conjunto semelhante de utilitários pela primeira vez, pode parecer que tudo é desnecessariamente complicado e o antigo paradigma pode ser usado, que as abordagens existentes para o desenvolvimento são bastante eficazes. No entanto, se você olhar mais fundo, tudo se torna muito mais interessante.

Por exemplo, Chocolatey e pip permitem instalar todos os pacotes necessários por meio do console do SO e Python, respectivamente. E o próprio Python, como a maioria do software em questão, é colocado em um comando:

hoco install python xxx

Também é atualizado com um comando:

choco upgrade all

A abordagem é um pouco incomum para usuários do Windows, para aqueles que estão familiarizados com os gerenciadores de pacotes de console no Linux (apt, zypper etc.), nada de novo. Eu sempre notei a situação em que os desenvolvedores de software do MK atualizam o software apenas ao reinstalar o SO em um PC. Sobre por que é ruim não falarmos, só notei que aqui esse problema é resolvido automaticamente.

As inovações no campo de configuração e montagem de projetos são muito mais interessantes.

O Ninja foi projetado e posicionado como um substituto para a marca e focado na velocidade de construção. É especialmente bom em aplicativos quando é necessário recriar projetos com vários arquivos pequenos, onde não houve alterações. O efeito pode ser uma ordem de magnitude, ou até duas, ver testes .

Cmakepor sua vez, permite gerar arquivos de configuração para o Ninja em uma linguagem de alto nível (script) para a plataforma na qual o assembly ocorrerá. Sobre o Cmake pode ser lido em Habré, por exemplo, aqui , aqui e aqui , o
GPerf gera uma tabela de ponteiros, que economiza memória, consulte a etapa 3 da montagem abaixo.

Também devemos prestar atenção a uma nova abordagem para a descrição do ferro. O Devicetree apareceu , descrevendo a estrutura de hardware do dispositivo. Este é um resultado direto do suporte do Zephyr pela Linux Foundation.

As vantagens são que a descrição do hardware agora está em um arquivo .dts separado, que possui uma estrutura simples, é fácil modificar e, como resultado, portar o código entre diferentes famílias de chips.
Como exemplo, o quanto eu posso ilustrar claramente o dtsi básico no nRF52840 , que por sua vez é usado na descrição da placa nRF52840-DK nrf52840dk_nrf52840.dts.O
número de placas-mãe suportadas pelo Zephyr já é superior a 200 .

Como afirmado anteriormente, a Nordic lançou o Zephyr pela primeira vez na série nRF91, depois na nRF53, e agora finalmente atingiu o nRF52 mais maciço.

A mudança para o RTOS permite, por sua vez, resolver o problema de adaptação do código para o novo hardware. Mesmo entre os chips de uma família, a transição exigia certos recursos do lado do desenvolvimento, se fosse acompanhada de uma transição para outro dispositivo (a biblioteca BLE pré-compilada). Sem mencionar a transição, por exemplo, das séries 51 ou 91 para 52, quando a própria plataforma de hardware muda significativamente. Agora, essa tarefa será resolvida com muito mais facilidade e rapidez.

O ferro na Nordic está sendo constantemente aprimorado, mas isso deve ser escrito separadamente. Na estrutura deste artigo, podemos observar apenas que o foco está na integração com o RTOS, segurança, eficiência energética e melhoria do canal de rádio (BLE 5.2). Obrigado pode dizer o dual-core Cortex-M33, ARM Cryptocell e ARM TrustZone.

Para construir devicetree usadoDevice Tree Compiler , que faz parte do MSYS2 (sistema de compilação aprimorado baseado em Cygwin e MinGW-64).

A segunda parte da configuração do projeto está no KConfig (Kernel config), que também foi herdado do Linux. Permite selecionar os blocos necessários por meio de uma interface gráfica e definir parâmetros de montagem para uma tarefa específica, o que é especialmente importante nas condições de recursos limitados dos sistemas em um chip.

Você pode usar utilitários tradicionais como menuconfig ou , dentro da estrutura do Segger Embedded Studio (o IDE oficial recomendado), há uma interface interna que pode ser iniciada através do item de menu correspondente: Projeto> Configurar projeto do nRF Connect SDK



Um exemplo de configuração de projeto com SSL / TLS baseado no nRF9160 é apresentado abaixo. Como você pode ver, é possível configurar os recursos de hardware do projeto (plataforma, número de threads, módulos de plug-in do kernel) e software (chaves, endereços, etc.).





Considere as etapas da montagem do projeto: Existem cinco no total:

  • Configuração - processamento preliminar de todas as configurações (devicetree, KConfig); na saída, obtemos arquivos de cabeçalho que descrevem o hardware e a configuração do Ninja
  • Pré-montagem (I) - processando estruturas em alto nível, compilando arquivos e compensações do sistema (offset), criando tabelas de chamadas
  • Montagem inicial (II) - compilação dos principais códigos fonte e empacotá-los em arquivos, vinculando
  • (III) — (GPerf),
  • - (IV) — hex, bin

Você pode ler mais sobre o sistema de montagem Zephyr com fotos na documentação oficial . Como existem muitos textos e figuras, não consideraremos os detalhes na estrutura deste artigo.
É importante entender que as ferramentas usadas aqui não substituem o pré-processador C (cpp) e o vinculador C (ld). Ambos são usados ​​em todas as etapas, exceto no pós-processamento. No entanto, o resultado de seu trabalho está sujeito a melhorias adicionais, que permitem reduzir significativamente o tempo de montagem e os requisitos de memória.

Você não pode comparar diretamente os resultados dos programas criados em dois SDKs. Como as bibliotecas e abordagens são muito diferentes e ainda não existem testes. Definitivamente, pode-se dizer que a solução é boa em chips médios e de ponta da linha (nRF52832 e superior), e ainda existe uma grande reserva de recursos. No entanto, não se pode dizer que o novo SDK não se aplica a chips mais novos como o nRF52810. É necessário considerar o problema com mais detalhes.

Voltando à questão no título do artigo, podemos dizer que esse paradigma é definitivamente uma nova realidade. O que, à primeira vista, traz melhorias significativas. Pelo menos 2 novas famílias de chips do maior fabricante de BLE do mundo trabalham com precisão e somente nessa tecnologia e não se espera retorno. Na minha opinião, esta é uma revolução que foi preparada com antecedência.

Atualização : em 14 de maio, a Nordic realizou um webinar sobre o novo SDK no qual anunciou que todas as versões do BLE anteriores a 5.0 estarão disponíveis apenas no nRF Connect SDK. Assim, o Directino Finding, também conhecido como AoA / AoD (BLE 5.1) e LE Audio (BLE 5.2), que muitos estão esperando, trará novas ferramentas este ano e as mudanças no desenvolvimento ocorrerão mais cedo do que o previsto.

Constatações:

  • As alterações são radicais, o código que trabalha com o nRF5 SDK atual não é compatível com o novo (nRF Connect SDK)
  • A mudança para o RTOS com Devicetree e KConfig permite obter um nível adicional de abstração para hardware, o que, por sua vez, acelera significativamente o desenvolvimento e a transferência do projeto para uma nova plataforma.
  • A mudança para o Zephyr oferece suporte a um grande número de protocolos e bibliotecas prontas para uso; para dispositivos IoT, os mais interessantes são as funções de rede e segurança, onde o Linux é tradicionalmente forte
  • O Zephyr OS usa várias ferramentas durante a montagem, o que pode reduzir significativamente o tempo de montagem e os requisitos de memória, o que é especialmente importante para aplicativos incorporados
  • O novo SDK permite o uso de desenvolvedores de nível superior, que são muito mais no mercado do que os de nível inferior. Isso resolve a questão do pessoal e aumenta a participação de mercado.

More articles:


All Articles