Protótipo rápido de aplicações Bluetooth IoT com um kit de desenvolvimento e placas de expansão prontas

By Stephen Evanczuk

Contributed By Digi-Key's North American Editors

A demanda por produtos inteligentes conectados oferece amplas oportunidades para desenvolvedores que são capazes de transformar rapidamente conceitos em aplicações de Internet das Coisas (IoT) funcionais. A disponibilidade de processadores com eficiência energética, opções de conectividade sem fio e uma ampla gama de periféricos de hardware oferece uma base robusta para a implementação de projetos adequados de baixa potência e prontos para produção.

No estágio inicial da definição do produto, entretanto, os desenvolvedores precisam de uma plataforma de desenvolvimento flexível para construir protótipos rápidos baseados na mesma classe de processadores, subsistemas de conectividade e periféricos. A capacidade de construir rapidamente protótipos de trabalho e adicionar facilmente funcionalidade é essencial para fornecer provas antecipadas de conceito e para apoiar o desenvolvimento de software personalizado.

Este artigo mostra como os desenvolvedores podem usar hardware e software da Silicon Labs para construir rapidamente protótipos especializados de dispositivos IoT conectados com eficiência energética usando uma ampla seleção de placas adicionais prontamente disponíveis para uso.

Possibilitando a prototipagem rápida

Ao explorar novas possibilidades de dispositivos IoT sem fio alimentados por bateria, os desenvolvedores podem se ver atolados pelos muitos detalhes envolvidos na criação de uma plataforma de desenvolvimento funcional. Com seus subsistemas integrados, dispositivos avançados system-on-chip (SoC) podem fornecer o núcleo de tal plataforma, mas os desenvolvedores ainda precisam construir um sistema completo em torno deles.

Para construir uma plataforma de desenvolvimento adequada para estes dispositivos, os desenvolvedores não só precisam atender aos requisitos fundamentais de desempenho robusto e vida útil prolongada da bateria, mas também precisam criar flexibilidade para suportar os requisitos específicos de cada aplicação. O kit Explorer BGM220-EK4314A da Silicon Labs atende a esta combinação de necessidades, permitindo que os desenvolvedores se concentrem na prototipagem rápida de novos conceitos de projeto em vez de lidarem com os detalhes envolvidos na construção de sua própria plataforma de desenvolvimento.

Plataforma de desenvolvimento rápido e flexível

Oferecendo uma plataforma de baixo custo para o desenvolvimento de aplicações baseadas em Bluetooth, o kit Explorer BGM220-EK4314A combina o módulo da SiLabs BGM220P Wireless Gecko (BGM220PC22HNA), um depurador SEGGER J-Link na placa, um pushbutton, um diodo emissor de luz (LED), e múltiplas opções de expansão (Figura 1).

Imagem do kit Explorer SiLabs BGM220-EK4314AFigura 1: O kit Explorer SiLabs BGM220-EK4314A fornece a combinação de desempenho de processamento, gerenciamento de energia e flexibilidade de configuração necessária para construir rapidamente protótipos e avaliar diferentes configurações de hardware periférico. (Fonte da imagem: Silicon Labs)

O módulo BGM220P serve como uma solução completa para pequenos dispositivos IoT alimentados por bateria. Seu EFR32BG22 Blue Gecko SoC integrado apresenta consumo de energia ultrabaixo, Bluetooth com ângulo de chegada (AoA) e ângulo de partida (AoD), e precisão de localização inferior a um metro — tudo o que é necessário em uma gama crescente de aplicações Bluetooth populares, incluindo etiquetas de rastreamento de ativos, fechaduras inteligentes de portas, fitness e muito mais.

Capaz de operar como um sistema autônomo, o módulo BGM220P combina o SoC EFR32BG22 com 512 Kbytes de flash, 32 Kbytes de memória de acesso aleatório (RAM), cristais (XTAL) de alta frequência (HF) e baixa frequência (LF), e uma rede de casamento de 2,4 gigahertz (GHz) e antena cerâmica para conectividade sem fio (Figura 2).

Diagrama do módulo SiLabs BGM220PFigura 2: capaz de servir como sistema autônomo, o módulo SiLabs BGM220P combina o EFR32BG22 Blue Gecko SoC com os componentes adicionais necessários para implementar um dispositivo habilitado por Bluetooth. (Fonte da imagem: Silicon Labs)

Além de sua capacidade de servir como um host autônomo para projetos IoT de pequenas dimensões, o módulo também pode servir como um co-processador de rede (NCP) para um processador host conectado através da interface UART do módulo. Sua pilha Bluetooth integrada executa serviços sem fio para aplicações que rodam no módulo em projetos autônomos, ou processa comandos recebidos do host quando rodar em projetos NCP.

SoC sem fio com eficiência energética

O EFR32BG22 Bluetooth sem fio SoC do módulo BGM220P integra um núcleo Cortex-M33 Arm de 32 bits, um rádio de 2,4 GHz, segurança, subsistemas de gerenciamento de energia e vários temporizadores e opções de interface. Projetado especificamente para projetos de energia ultrabaixa, alimentados por bateria, o SoC EFR32BG22 utiliza múltiplos recursos de gerenciamento de energia que podem permitir a operação por bateria de célula do tipo moeda por até dez anos.

Operando a partir de uma única fonte de tensão externa, o SoC utiliza sua unidade interna de gerenciamento de energia para gerar tensões internas de alimentação. Durante a operação, a unidade de gerenciamento de energia controla as transições entre os cinco modos de energia (EMs) do SoC. Cada modo reduz ainda mais o consumo de energia, mantendo progressivamente menos blocos funcionais ativos à medida que o SoC transita do modo ativo (EM0) para o modo de suspensão (EM1), modo de suspensão profunda (EM2), modo de parada (EM3) ou modo de desligamento (EM4) (Figura 3).

Diagrama do Silicon Labs EFR32BG22 SoC (clique para ampliar)Figura 3: A unidade de gerenciamento de energia do SoC EFR32BG22 controla as transições entre os modos de energia EM0, EM1, EM2, EM3 e EM4 (código de cores na parte inferior da imagem). (Fonte da imagem: Silicon Labs)

No modo ativo (EM0) a 76,8 MHz e 3 volts, usando seu conversor CC/CC interno, o SoC drena 27 microamperes por megahertz (μA/MHz). O EM0 é o modo de operação normal e é o único onde o núcleo do processador Cortex M33 e todos os blocos periféricos estão disponíveis.

Todos os periféricos estão disponíveis em modo de suspensão (EM1), com menos ativos remanescentes à medida que o sistema entra em modos de potência ainda mais baixas. Em seus modos de menor potência, a redução dos clocks ativos e dos blocos funcionais resulta em níveis significativamente menores de consumo de energia:

  • 17 μA/MHz em modo de suspensão (EM1)
  • 1,40 μA em modo de suspensão profunda (EM2) com retenção de 32 Kbytes de RAM e relógio em tempo real (RTC) funcionando a partir do LFXO
  • 1,05 μA em modo de parada (EM3) com retenção de 8 Kbytes de RAM e RTC funcionando a partir do oscilador RC (resistor-capacitor) integrado do SoC de frequência ultrabaixa de 1 kilohertz (kHz) (ULFRCO)
  • 0,17 μA em modo de desligamento (EM4)

Alguns dispositivos alimentados por bateria precisam mais do que a capacidade de operar o processador em modos de operação de baixa potência. Muitas aplicações habilitadas para o Bluetooth apresentam, normalmente, períodos prolongados de pouca ou nenhuma atividade, mas exigem baixa latência de resposta quando a atividade é retomada. De fato, mesmo que uma aplicação tenha requisitos de latência mais brandos, um tempo de despertar lento desperdiça energia porque o processador não realiza nenhum trabalho útil ao completar o processo de despertar e entrar em modo ativo (ou completar o processo de entrar em modo de menor potência a partir de um modo de maior potência).

Como o tempo entre os períodos ativos diminui, o uso de um modo de suspensão de baixa potência pode até se tornar contraproducente, quando um tempo de despertar lento ou de entrada no modo de energia utiliza mais energia do que seria consumido se o processador permanecesse em um modo de maior potência durante o período inativo. Como resultado, os desenvolvedores que trabalham para otimizar a vida útil da bateria às vezes manterão um processador em um modo de potência maior do que o requerido pelas necessidades de processamento da aplicação.

Ao usar um processador com tempos de despertar e entrada mais rápidos, os desenvolvedores podem aproveitar melhor os modos de menor potência do processador. No EM1, o EFG32BG22 desperta em três clocks/1,24 microssegundos (µs) e tem um tempo de entrada de 1,29 µs, subindo para 8,81 milissegundos (ms) e 9,96 µs, respectivamente, no EM4 (Tabela 1).

Modo de energia Despertar (execução da RAM/Flash) Entrada (execução da Flash)
EM1 3 clocks / 1,24 μs 1,29 μs
EM2 5,15 / 13,22 μs 5,23 μs
EM3 5,15 / 13,21 μs 5,23 μs
EM4 8,81 ms (somente Flash) 9,96 μs

Tabela 1: Tempos de despertar e de entrada do modo de energia para o SoC EFG32BG22. (Fonte da tabela: Silicon Labs)

O método usado para despertar o processador quando a atividade é retomada também pode afetar significativamente a vida útil da bateria. Embora algumas aplicações — como os sistemas industriais — exijam o uso de processamento de sondagem para garantir uma temporização periódica rigorosa, muitas aplicações em áreas de consumo utilizam processamento baseado em eventos para responder a atividades específicas. O uso de métodos de sondagem para aplicações baseadas em eventos, por exemplo, pode derrubar significativamente a vida útil da bateria quando o processador desperta repetidamente sem necessidade.

Da mesma forma que muitos projetos baseados em sensores usam a funcionalidade wake-on-interrupt para evitar despertar repetidamente o processador apenas para verificar a atividade, um recurso wake-on-RF incorporado no subsistema de rádio do SoC EFG32BG22 permite uma abordagem similar, baseada em interrupções. Isto permite aos desenvolvedores manter o processador em um modo de energia mais baixo até que ocorra a atividade de radiofrequência (RF).

Na prática, os desenvolvedores colocam o SoC sem fio EFG32BG22 em um modo EM2, EM3 ou EM4 de consumo ultrabaixo e confiam na capacidade wake-on-RF para despertar o SoC quando a energia de RF for detectada. Ao simplesmente detectar energia acima do limiar, a capacidade RFSENSE consome 131 nanoamperes (nA). Um modo RFSENSE mais seletivo consome um pouco mais de corrente a 138 nA, mas neste modo, o RFSENSE filtra os sinais de RF que chegam para evitar o despertar no ruído de RF em vez de um sinal de RF válido.

Em alguns casos, o EFG32BG22 SoC pode não precisar despertar o núcleo do processador para responder a eventos externos: o Peripheral Reflex System (PRS) da SiLabs permite que os periféricos respondam aos eventos e operem sem despertar o núcleo do processador. Os periféricos podem se comunicar diretamente uns com os outros, e suas funções podem ser combinadas para fornecer funcionalidades complexas. Ao usar os recursos do PRS com modos de energia mais baixos, os desenvolvedores podem reduzir substancialmente o consumo de energia sem comprometer a funcionalidade crítica, como a aquisição de dados dos sensores.

Depuração embutida e fácil expansão

Incorporado à placa do kit Explorer BGM220, o módulo BGM220P traz o conjunto completo de capacidades de processamento e gerenciamento de energia do SoC EFR32BG22 para projetos Bluetooth alimentados por bateria. Quando há a necessidade de construir rapidamente protótipos para explorar novos conceitos de design, outras características da placa ajudam a acelerar o desenvolvimento.

Acessado através do conector USB Micro-B da placa, um depurador J-Link SEGGER na placa permite o download e a depuração de códigos, bem como uma porta COM virtual para acesso ao console do host. O depurador também suporta a capacidade da interface de rastreamento de pacotes (PTI) da SiLabs para analisar os pacotes transmitidos ou recebidos através de uma rede sem fio.

Para prototipagem rápida, o suporte da placa para múltiplas opções de expansão oferece a flexibilidade para explorar novas idéias de projeto que necessitam de diferentes combinações de sensores, atuadores, opções de conectividade e outros periféricos. Extraindo da extensa variedade de placas adicionais mikroBUS disponíveis e hardware Qwiic Connect System de vários fornecedores, os desenvolvedores podem configurar rapidamente uma plataforma de desenvolvimento para cada aplicação.

Conectada ao soquete mikroBUS da placa, uma placa mikroBUS se conecta ao módulo BGM220P através de interfaces I2C, SPI ou UART. O conector Qwiic fornece a interface I2C do sistema Qwiic para conectar uma ou mais placas Qwiic em distâncias de até cerca de 1,2 metros. Para conexões em distâncias maiores, os desenvolvedores podem usar a placa SparkFun QwiicBus EndPoint (COM-16988), que usa sinalização diferencial para manter a integridade do sinal I2C em distâncias de até cerca de 30 metros.

Rápido desenvolvimento de aplicativos

A SiLabs aplica o conceito de expansão rápida ao desenvolvimento de software aplicativo. Junto com os pacotes de suporte à placa, drivers, bibliotecas e cabeçalhos para desenvolvimento personalizado, a empresa oferece vários exemplos de aplicações agrupadas em seu ambiente de desenvolvimento Simplicity Studio, bem como projetos adicionais disponíveis nos repositórios GitHub da SiLabs. De fato, os desenvolvedores podem começar a explorar o desenvolvimento de aplicações de sensores com um aplicativo de exemplo de temperatura agrupada que usa o sensor de temperatura interna do SoC EFR32BG22 como uma fonte de dados.

Construído em torno do serviço padrão Bluetooth Health Temperature, o aplicativo de temperatura oferece uma demonstração pronta para uso do fluxo de processamento através de um aplicativo genérico Bluetooth IoT construído sobre a arquitetura do software SiLabs. O aplicativo chama uma série de rotinas de inicialização para serviços de sistema e serviços de aplicação que configuram manipuladores de interrupções e retornos de chamadas. Após completar a inicialização, o aplicativo se assenta em um loop infinito para esperar por eventos (Listagem 1).

Copiar
int main(void)
{
  // Initialize Silicon Labs device, system, service(s) and protocol stack(s).
  // Note that if the kernel is present, processing task(s) will be created by
  // this call.
  sl_system_init();



  // Initialize the application. For example, create periodic timer(s) or
  // task(s) if the kernel is present.
  app_init();



#if defined(SL_CATALOG_KERNEL_PRESENT)
  // Start the kernel. Task(s) created in app_init() will start running.
  sl_system_kernel_start();
#else // SL_CATALOG_KERNEL_PRESENT
  while (1) {
    // Do not remove this call: Silicon Labs components process action routine
    // must be called from the super loop.
    sl_system_process_action();



    // Application process.
    app_process_action();



#if defined(SL_CATALOG_POWER_MANAGER_PRESENT)
    // Let the CPU go to sleep if the system allows it.
    sl_power_manager_sleep();
#endif
  }
#endif // SL_CATALOG_KERNEL_PRESENT
}
Listagem 1: os aplicativos de exemplo de Bluetooth da SiLabs utilizam uma estrutura de execução genérica, onde um loop infinito permite que os retornos de chamadas e manipuladores de eventos processem as ações do sistema e da aplicação após a inicialização. (Fonte do código: Silicon Labs)

Nesta aplicação, quando um temporizador definido durante a inicialização faz a contagem regressiva, uma rotina de retorno de chamada associada realiza uma medição de temperatura. Após os desenvolvedores construírem o aplicativo e atualizarem a placa, eles podem usar o SiLabs EFR Connect — um aplicativo genérico Bluetooth móvel que funciona com todos os kits e dispositivos Bluetooth da Silicon Labs. Além de fornecer a estrutura para aplicativos personalizados, o aplicativo ajuda no desenvolvimento, fornecendo uma visão das características suportadas associadas a um serviço Bluetooth, como o serviço Bluetooth Health Thermometer utilizado neste exemplo de aplicativo (Figura 4).

Imagem do aplicativo SiLabs EFR ConnectFigura 4: O aplicativo SiLabs EFR Connect exibe características dos serviços Bluetooth utilizados em uma aplicação, não apenas acelerando o desenvolvimento de protótipos, mas também fornecendo uma estrutura para o desenvolvimento de aplicativos personalizados. (Fonte da imagem: Silicon Labs)

No Simplicity Studio, os desenvolvedores podem importar uma série de diferentes exemplos de aplicações Bluetooth que demonstram vários cenários de uso, incluindo projetos construídos com placas Qwiic ou mikroBUS, separadamente ou em combinação. Por exemplo, um aplicativo de exemplo que demonstra o uso dos serviços padrão Bluetooth de frequência cardíaca (HR) e oxímetro de pulso (SpO2) em combinação com a placa MIKROE-4037 Heart Rate 2 Click mikroBUS da MikroElektronika, contendo o biosensor MAX86161 da Maxim Integrated. O MAX86161 fornece um subsistema completo de baixa potência capaz de fornecer medições precisas de HR e SpO2 a um processador host conectado através de sua interface I2C. (Para mais informações sobre o uso do MAX86161, consulte Crie um verdadeiro dispositivo auditivo de fitness — Parte 1: Medição da frequência cardíaca e SpO2).

Com sua necessidade de um driver adicional e um algoritmo de processamento mais exigente do que na aplicação de temperatura, esta aplicação fornece uma demonstração mais complexa de uma arquitetura de aplicativo de software de dispositivo IoT (Figura 5).

Diagrama de aplicação HR/SpO2Figura 5: Exemplos de projetos como uma aplicação HR/SpO2 ajudam a acelerar o desenvolvimento de protótipos enquanto demonstram um fluxo de processo típico para aplicações de sensores Bluetooth de baixa potência. (Fonte da imagem: Silicon Labs)

Como no aplicativo de temperatura mencionado acima, este aplicativo se baseia em uma série de rotinas de inicialização para configurar o sistema e os serviços do aplicativo. Onde a rotina app_process_action está vazia no aplicativo de temperatura, este aplicativo acrescenta uma chamada a uma rotina, hrm_loop, em app_process_action. Isto resulta em uma chamada para hrm_loop em cada passagem através do loop infinito de nível superior mostrado anteriormente na Listagem 1. Além disso, um temporizador de software é usado para atualizar periodicamente os dados de RH e SpO2.

A rotina hrm_loop, por sua vez, chama o maxm86161_hrm_process, que retira amostras de uma fila mantida por funções de ajuda e as entrega a uma rotina de processo de amostra. Isto, por sua vez, chama um par de rotinas, maxm86161_hrm_frame_process e maxm86161_hrm_spo2_frame_process, que executam algoritmos para validar e gerar resultados de HR e SpO2, respectivamente. Os desenvolvedores podem visualizar os resultados junto com outras características de serviço usando o aplicativo EFR Connect mencionado anteriormente.

Outro exemplo de aplicativo de software mostra como os desenvolvedores podem criar sobre uma aplicação complexa, como nesta aplicação HR/SpO2 quando estendem sua plataforma de hardware. Usando a placa do kit Explorer BGM220-EK4314A e o ecossistema de software SiLabs, criar a partir de hardware e software existentes é relativamente simples. SiLabs demonstra esta abordagem com um aplicativo de exemplo que adiciona um display OLED à plataforma de hardware/software utilizada para a aplicação HR/SpO2 acima. Neste exemplo, uma placa adicional Qwiic (LCD-14532) é anexada ao conector Qwiic da placa, enquanto a placa adicional MikroElektronika Heart Rate 2 Click permanece no lugar a partir da aplicação de exemplo anterior de HR/SpO2 (Figura 6).

Imagem da placa do kit Explorer Silicon Labs BGM220-EK4314A com display OLEDFigura 6: os desenvolvedores podem adicionar rapidamente funcionalidade a um projeto existente construído sobre a placa do kit Explorer BGM220-EK4314A — aqui adicionando um display OLED a um protótipo existente de HR/SpO2. (Fonte da imagem: Silicon Labs)

Além da adição de um driver e serviços de suporte para a placa OLED, o aplicativo de software permanece em grande parte o mesmo para esta versão estendida do aplicativo HR/SpO2. O temporizador de software mencionado anteriormente para a aplicação HR/SpO2 adiciona uma chamada à função hrm_update_display, que exibe os dados HR e SpO2 (Listagem 2).

Copiar
    /* Software Timer event */
    case sl_bt_evt_system_soft_timer_id:
      /* Check which software timer handle is in question */
      if (evt->data.evt_system_soft_timer.handle == HEART_RATE_TIMER) {
        heart_rate_send_new_data(connection_handle);
        break;
      }
 
      if (evt->data.evt_system_soft_timer.handle == PULSE_OXIMETER_TIMER) {
        pulse_oximeter_send_new_data(connection_handle);
        break;
      }
 
      if (evt->data.evt_system_soft_timer.handle == DISPLAY_TIMER) {
        hrm_update_display();
        break;
      }
      break;
Listagem 2: Usando o kit e o ecossistema de software, os desenvolvedores podem adicionar funcionalidade um aplicativo HR/SpO2 existente, conectando uma placa de display e fazendo alterações mínimas no software, além de adicionar uma chamada de função, hrm_update_display, ao manipulador do temporizador de software do aplicativo existente. (Fonte do código: Silicon Labs)

Esta abordagem extensível de hardware e software permite que os desenvolvedores criem rapidamente aplicações IoT funcionais. Devido ao hardware e ao software serem facilmente adicionados ou removidos, os desenvolvedores podem explorar mais facilmente novas soluções de projeto e avaliar configurações alternativas.

Conclusão

Os dispositivos IoT ativados por Bluetooth e alimentados por baterias estão no coração das aplicações populares e fornecem o principal capacitador para atender à demanda contínua por mais funcionalidade e tempo de operação maior. Para os desenvolvedores, atender eficazmente a essas exigências conflitantes requer a capacidade de explorar rapidamente novos projetos e avaliar conceitos alternativos de projeto. Usando um kit de desenvolvimento e software associado da Silicon Labs, os desenvolvedores podem construir rapidamente protótipos, adicionando e removendo hardware conforme necessário para atender às exigências específicas da aplicação.

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this author

Stephen Evanczuk

Stephen Evanczuk has more than 20 years of experience writing for and about the electronics industry on a wide range of topics including hardware, software, systems, and applications including the IoT. He received his Ph.D. in neuroscience on neuronal networks and worked in the aerospace industry on massively distributed secure systems and algorithm acceleration methods. Currently, when he's not writing articles on technology and engineering, he's working on applications of deep learning to recognition and recommendation systems.

About this publisher

Digi-Key's North American Editors