Prototipazione rapida di applicazioni IoT Bluetooth con un kit di sviluppo e schede aggiuntive disponibili di serie

Di Stephen Evanczuk

Contributo di Editori nordamericani di Digi-Key

La domanda di prodotti intelligenti connessi offre ampie opportunità agli sviluppatori capaci di trasformare rapidamente i concetti in applicazioni funzionanti per Internet delle cose (IoT). La disponibilità di processori ad alta efficienza energetica, opzioni di connettività wireless e una vasta gamma di periferiche hardware offre una solida base per implementare progetti adeguati a bassa potenza e pronti per la produzione.

Nella fase iniziale della definizione del prodotto, tuttavia, gli sviluppatori hanno bisogno di una piattaforma di sviluppo flessibile per creare prototipi rapidi basati sulla stessa classe di processori, sottosistemi di connettività e periferiche. La capacità di creare rapidamente prototipi funzionanti e di aggiungere facilmente funzionalità è essenziale per i primi proof of concept e per sostenere lo sviluppo di software personalizzato.

Questo articolo mostra agli sviluppatori come utilizzare l'hardware e il software di Silicon Labs per creare rapidamente prototipi di dispositivi connessi IoT ad alta efficienza energetica utilizzando un'ampia selezione di schede aggiuntive disponibili di serie.

Promuovere la prototipazione rapida

Quando esplorano nuove possibilità per i dispositivi IoT wireless alimentati a batteria, gli sviluppatori possono trovar difficile districarsi tra i mille dettagli della creazione di una piattaforma di sviluppo funzionante. Con i loro sottosistemi integrati, i dispositivi System-on-Chip (SoC) avanzati possono essere il cuore di una tale piattaforma, ma agli sviluppatori spetta sempre l'arduo compito di crearvi attorno un sistema completo.

Per creare una piattaforma di sviluppo adatta a questi dispositivi, gli sviluppatori non solo devono soddisfare i requisiti fondamentali di prestazioni robuste e durata estesa della batteria, ma devono anche integrare la flessibilità per supportare i requisiti specifici di ogni applicazione. BGM220-EK4314A Explorer Kit di Silicon Labs soddisfa tutte queste esigenze, permettendo agli sviluppatori di concentrarsi sulla prototipazione rapida di nuovi concetti senza doversi occupare dei dettagli di creazione di una propria piattaforma di sviluppo.

Piattaforma di sviluppo rapido flessibile

Come piattaforma a basso costo per lo sviluppo di applicazioni basate su Bluetooth, il kit BGM220-EK4314A Explorer combina il modulo BGM220P Wireless Gecko (BGM220PC22HNA) di SiLabs, un debugger SEGGER J-Link, un pulsante, un diodo luminoso (LED) e molte opzioni di espansione (Figura 1).

Immagine di BGM220-EK4314A Explorer Kit di SiLabsFigura 1: BGM220-EK4314A Explorer Kit di SiLabs fornisce la combinazione di prestazioni di elaborazione, gestione dell'energia e flessibilità di configurazione necessaria per creare rapidamente prototipi e valutare diverse configurazioni hardware periferiche. (Immagine per gentile concessione di Silicon Labs)

Il modulo BGM220P fa da soluzione completa per piccoli dispositivi IoT alimentati a batteria. Il suo SoC integrato EFR32BG22 Blue Gecko è caratterizzato da un bassissimo consumo energetico, capacità Bluetooth per angolo di arrivo (AoA) e angolo di partenza (AoD) e da una precisione di localizzazione inferiore al metro, tutte necessarie in una gamma crescente di comuni applicazioni Bluetooth, tra cui i tag di tracciabilità patrimoniale, serrature intelligenti, fitness e altro.

In grado di funzionare come sistema autonomo, il modulo BGM220P combina il SoC EFR32BG22 con 512 kB di flash, 32 kB di memoria ad accesso casuale (RAM), cristalli ad alta frequenza (HF) e bassa frequenza (LF) (XTAL), una rete di adattamento a 2,4 GHz e un'antenna ceramica per la connettività wireless (Figura 2).

Schema del modulo BGM220P di SiLabsFigura 2: Capace di funzionare come sistema autonomo, il modulo BGM220P di SiLabs combina il SoC EFR32BG22 Blue Gecko con componenti aggiuntivi necessari per implementare un dispositivo abilitato al Bluetooth. (Immagine per gentile concessione di Silicon Labs)

Oltre alla sua capacità di fungere da host autonomo per progetti IoT compatti, il modulo può anche essere un coprocessore di rete (NCP) per un processore host collegato attraverso l'interfaccia UART del modulo. Lo stack Bluetooth integrato esegue i servizi wireless per le applicazioni in esecuzione sul modulo nei progetti standalone oppure elabora i comandi ricevuti dall'host quando è in esecuzione nei progetti NCP.

SoC wireless ad alta efficienza energetica

Il SoC wireless Bluetooth EFR32BG22 del modulo BGM220P integra un core Arm Cortex-M33 a 32 bit, una radio a 2,4 GHz, sottosistemi di sicurezza e di gestione dell'energia, nonché molteplici timer e opzioni di interfaccia. Progettato specificamente per progetti a bassissimo consumo e alimentati a batteria, il SoC EFR32BG22 utilizza varie caratteristiche di gestione dell'energia che possono consentire l'operatività della batteria a bottone fino a dieci anni.

Operando da una singola fonte di tensione esterna, il SoC utilizza la sua unità interna di gestione dell'energia per generare tensioni di alimentazione interne. Durante il funzionamento, l'unità di gestione dell'energia controlla le transizioni tra le cinque modalità energetiche (EM) del SoC. Ogni modalità riduce ulteriormente il consumo energetico mantenendo progressivamente meno blocchi funzionali attivi quando il SoC passa dalla modalità attiva (EM0) alla modalità di sospensione (EM1), sospensione profonda (EM2), arresto (EM3) o spegnimento (EM4) (Figura 3).

Schema del SoC EFR32BG22 di Silicon Labs (fare clic per ingrandire)Figura 3: L'unità di gestione dell'energia del SoC EFR32BG22 controlla le transizioni tra le modalità energetiche EM0, EM1, EM2, EM3 e EM4 (codice dei colori in basso nell'immagine). (Immagine per gentile concessione di Silicon Labs)

Nella modalità attiva (EM0) a 76,8 MHz e 3 V, utilizzando il suo convertitore c.c./c.c. interno, il SoC assorbe solo 27 μA/MHz. EM0 è la modalità operativa normale ed è l'unica in cui il core del processore Cortex M33 e tutti i blocchi periferici sono disponibili.

Tutte le periferiche sono disponibili nella modalità di sospensione (EM1), con un numero minore che rimane attivo quando il sistema entra in modalità di potenza più bassa. Nelle sue modalità a bassa potenza, la riduzione dei clock attivi e dei blocchi funzionali si traduce in livelli di consumo energetico significativamente inferiori:

  • 17 μA/MHz in modalità di sospensione 0 (EM1)
  • 1,40 μA in modalità di sospensione profonda (EM2) con 32 kB di memoria RAM e clock in tempo reale (RTC) in esecuzione da LFXO
  • 1,05 μA in modalità di arresto (EM3) con 8 kB di memoria RAM e RTC in esecuzione dal SoC con un resistore-condensatore (RC) oscillatore (ULFRCO) integrato a frequenza ultrabassa di 1 kHz
  • 0,17 μA in modalità di spegnimento (EM4)

Alcuni dispositivi alimentati a batteria richiedono anche della capacità di far funzionare il processore in modalità operative a basso consumo. Molte applicazioni abilitate al Bluetooth presentano tipicamente periodi prolungati di poca o nessuna attività, ma richiedono una reattività a bassa latenza quando l'attività riprende. Infatti, anche se un'applicazione ha requisiti di latenza più tolleranti, un tempo di riattivazione lento spreca energia perché il processore non esegue alcun lavoro utile mentre completa la riattivazione ed entra in modalità attiva (o completa il processo di entrare in una modalità a basso consumo da una modalità a più alto consumo).

Man mano che il tempo tra i periodi attivi si riduce, l'uso di una modalità di sospensione a basso consumo può persino diventare controproducente quando una riattivazione lenta o un lungo tempo di entrata in modalità di alimentazione utilizza più energia di quella che verrebbe consumata se il processore rimanesse in una modalità a più alto consumo durante il periodo inattivo. Di conseguenza, gli sviluppatori che lavorano per ottimizzare la durata della batteria a volte mantengono un processore in una modalità di potenza superiore a quella richiesta dalle esigenze di elaborazione dell'applicazione.

Usando un processore con tempi di riattivazione e di entrata più veloci, gli sviluppatori possono sfruttare meglio le modalità di potenza più bassa del processore. In EM1, EFG32BG22 si riattiva in tre clock/1,24 µs e ha un tempo di entrata di 1,29 µs, che sale a 8,81 ms e 9,96 µs, rispettivamente, in EM4 (tabella 1).

Modalità di energia Riattivazione (esecuzione da RAM/Flash) Entrata (esecuzione da Flash)
EM1 3 clock / 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 (solo Flash) 9,96 μs

Tabella 1: Tempi di riattivazione e di entrata in modalità di alimentazione per il SoC EFG32BG22. (Tabella per gentile concessione di Silicon Labs)

Anche il metodo usato per riattivare il processore quando riprende l'attività può influenzare significativamente la durata della batteria. Sebbene alcune applicazioni, come quelle industriali, richiedano ai sistemi di usare l'elaborazione in polling per assicurare una rigorosa tempistica periodica, molte applicazioni nel settore consumer usano l'elaborazione basata sugli eventi per rispondere ad attività specifiche. L'utilizzo di metodi di polling per applicazioni basate su eventi, per esempio, può erodere significativamente la durata della batteria quando il processore si riattiva ripetutamente e inutilmente.

Nello stesso modo in cui molti progetti basati su sensori usano la funzionalità wake-on-interrupt per evitare di riattivare ripetutamente il processore solo per controllare l'attività, una caratteristica wake-on-RF integrata nel sottosistema radio del SoC EFG32BG22 permette un approccio simile guidato da interrupt. Questo permette agli sviluppatori di mantenere il processore in una modalità di bassa potenza fino a quando non si verifica l'attività di radiofrequenza (RF).

In pratica, gli sviluppatori portano il SoC wireless EFG32BG22 in una modalità EM2, EM3 o EM4 a bassissimo consumo e si affidano alla capacità wake-on-RF per riattivare il SoC quando viene rilevata l'energia RF. Quando rileva l'energia sopra la soglia, la capacità RFSENSE consuma 131 nA. Una modalità RFSENSE più selettiva consuma leggermente di più, 138 nA, ma in questa modalità, RFSENSE filtra i segnali RF in entrata per evitare di riattivarsi al rumore RF piuttosto che in presenza di un segnale RF valido.

In alcuni casi, il SoC EFG32BG22 potrebbe non aver bisogno di riattivare il core del processore per rispondere agli eventi esterni: Peripheral Reflex System (PRS) di SiLabs permette alle periferiche di rispondere agli eventi e operare senza riattivare il core del processore. Le periferiche possono comunicare direttamente tra loro e le loro funzioni possono essere combinate per fornire funzionalità complesse. Utilizzando le capacità del PRS con modalità di energia inferiore, gli sviluppatori possono ridurre notevolmente il consumo energetico senza compromettere le funzionalità critiche come l'acquisizione dei dati da parte del sensore.

Debug incorporato e facile espansione

Integrato nella scheda BGM220 Explorer Kit, il modulo BGM220P offre tutte le capacità di gestione ed elaborazione dell'energia del SoC EFR32BG22 ai progetti Bluetooth alimentati a batteria. Quando c'è bisogno di creare rapidamente dei prototipi per esplorare nuovi concetti, altre caratteristiche della scheda aiutano a velocizzare lo sviluppo.

Accessibile attraverso il connettore USB Micro-B della scheda, un debugger J-Link di SEGGER consente il download e il debug del codice, e offre anche una porta COM virtuale per l'accesso alla console host. Il debugger supporta anche la capacità dell'interfaccia PTI di SiLabs per analizzare i pacchetti trasmessi o ricevuti su una rete wireless.

Per la prototipazione rapida, il supporto della scheda di varie opzioni di espansione offre la flessibilità per esplorare nuove idee di progettazione che hanno bisogno di diverse combinazioni di sensori, attuatori, connettività e periferiche. Attingendo all'ampia varietà di schede aggiuntive mikroBUS disponibili e all'hardware Qwiic Connect System di svariati fornitori, gli sviluppatori possono configurare rapidamente una piattaforma di sviluppo per ogni applicazione.

Inserita nello zoccolo mikroBUS della scheda, una scheda mikroBUS si collega al modulo BGM220P tramite interfacce I2C, SPI o UART. Il connettore Qwiic fornisce l'interfaccia I2C del sistema per collegare una o più schede Qwiic su distanze fino a circa 1 metro. Per le connessioni su distanze più lunghe, gli sviluppatori possono utilizzare la scheda QwiicBus EndPoint di SparkFun (COM-16988), che utilizza la segnalazione differenziale per mantenere l'integrità del segnale I2C a distanze fino a circa 30 metri.

Sviluppo rapido di applicazioni

SiLabs applica il concetto di espansione rapida allo sviluppo di software applicativo. Insieme ai pacchetti di supporto della scheda, driver, librerie e basette per lo sviluppo personalizzato, l'azienda offre diverse applicazioni campione nell'ambiente di sviluppo Simplicity Studio, così come ulteriori progetti disponibili dai repository GitHub di SiLabs. Infatti, gli sviluppatori possono iniziare ad esplorare lo sviluppo di applicazioni con sensori con un'applicazione di esempio di temperatura in bundle che utilizza come fonte di dati il sensore di temperatura interno del SoC EFR32BG22.

Basata sul servizio standard Bluetooth Health Temperature, l'applicazione di temperatura offre una dimostrazione pronta per l'uso del flusso di elaborazione attraverso una generica applicazione Bluetooth IoT creata sull'architettura software di SiLabs. L'applicazione chiama una serie di routine di inizializzazione dei servizi di sistema e servizi applicativi che impostano i gestori di interrupt e callback. Dopo aver completato l'inizializzazione, l'applicazione si assesta in un ciclo infinito di attesa eventi (Listato 1).

Copy
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
}
Listato 1: Le applicazioni di esempio Bluetooth di SiLabs usano un framework di esecuzione generico in cui un ciclo infinito permette ai gestori di eventi e callback di elaborare le azioni del sistema e dell'applicazione dopo l'inizializzazione. (Codice sorgente per gentile concessione di Silicon Labs)

In questa applicazione, quando un timer impostato durante l'inizializzazione inizia il conto alla rovescia, una routine di callback associata misura la temperatura. Dopo aver creato l'applicazione e completato la scheda, gli sviluppatori possono usare EFR Connect di SiLabs, un'applicazione mobile Bluetooth generica che funziona con tutti i kit e i dispositivi Bluetooth di Silicon Labs. Oltre a fornire la struttura per le applicazioni personalizzate, questa applicazione aiuta nello sviluppo fornendo una visione delle caratteristiche supportate associate a un servizio Bluetooth come il servizio Bluetooth Health Thermometer utilizzato in questa applicazione di esempio (Figura 4).

Immagine dell'app EFR Connect di SiLabsFigura 4: L'app EFR Connect di SiLabs mostra le caratteristiche dei servizi Bluetooth utilizzati in un'applicazione, non solo velocizzando lo sviluppo di prototipi, ma anche fornendo un quadro per lo sviluppo di app personalizzate. (Immagine per gentile concessione di Silicon Labs)

In Simplicity Studio, gli sviluppatori possono importare una serie di esempi applicativi Bluetooth che dimostrano vari scenari di utilizzo, compresi i progetti basati su schede Qwiic o mikroBUS, separatamente o combinati. Ad esempio, questa applicazione dimostra l'uso dei servizi standard di frequenza cardiaca (HR) e pulsossimetro (SpO2) Bluetooth in combinazione con la click board mikroBUS MIKROE-4037 Heart Rate 2 di MikroElektronika, contenente il biosensore MAX86161 di Maxim Integrated. MAX86161 fa da sottosistema completo a bassa potenza in grado di fornire misurazioni accurate di HR e SpO2 a un processore host connesso attraverso la sua interfaccia I2C. (Per ulteriori informazioni sull'uso di MAX86161, vedere Creare un dispositivo indossabile true wireless da orecchio per il fitness - Parte 1: Misurazione di frequenza cardiaca e SpO2).

Con la sua necessità di un driver aggiuntivo e un algoritmo di elaborazione più impegnativo rispetto all'applicazione della temperatura, questa applicazione è una dimostrazione più complessa dell'architettura di un'applicazione software per dispositivi IoT (Figura 5).

Schema dell'applicazione HR/SpO2Figura 5: Progetti di esempio come un'applicazione HR/SpO2 aiutano ad accelerare lo sviluppo di prototipi e dimostrano un tipico flusso di processo per applicazioni di sensori Bluetooth a bassa potenza. (Immagine per gentile concessione di Silicon Labs)

Come per l'applicazione della temperatura appena menzionata, questa applicazione si basa su una serie di routine di inizializzazione per impostare il sistema e i servizi dell'applicazione. Dove la routine app_process_action è vuota nell'applicazione della temperatura, questa applicazione aggiunge una chiamata a una routine hrm_loop, in app_process_action. Ciò porta a una chiamata a hrm_loop ad ogni passaggio attraverso il ciclo infinito di primo livello mostrato prima nel Listato 1. Inoltre, un timer software aggiorna periodicamente i dati HR e SpO2.

La routine hrm_loop a sua volta chiama maxm86161_hrm_process, che estrae i campioni da una coda mantenuta da funzioni di supporto e li passa a una routine di processo campione. Questo, a sua volta, chiama una coppia di routine, maxm86161_hrm_frame_process e maxm86161_hrm_spo2_frame_process, che eseguono algoritmi per convalidare e generare i risultati rispettivamente di HR e SpO2. Gli sviluppatori possono visualizzare i risultati insieme ad altre caratteristiche del servizio usando l'app EFR Connect summenzionata.

Un altro esempio mostra come gli sviluppatori possono creare su un'applicazione complessa come questa applicazione HR/SpO2 quando estendono la piattaforma hardware. Utilizzando la scheda BGM220-EK4314A Explorer Kit e l'ecosistema software di SiLabs, lo sviluppo partendo da hardware e software esistenti è relativamente semplice. SiLabs dimostra questo approccio con un'applicazione campione che aggiunge un display OLED alla piattaforma hardware/software utilizzata per l'applicazione HR/SpO2 di cui sopra. In questo esempio, una scheda aggiuntiva Qwiic con display OLED di SparkFun (LCD-14532) è collegata al connettore Qwiic della scheda, mentre la click board aggiuntiva Heart Rate 2 di MikroElektronika rimane invariata dall'applicazione campione HR/SpO2 precedente (Figura 6).

Immagine della scheda BGM220-EK4314A Explorer Kit di Silicon Labs con display OLEDFigura 6: Gli sviluppatori possono aggiungere rapidamente funzionalità a un progetto esistente costruito sulla scheda BGM220-EK4314A Explorer Kit - qui aggiungendo un display OLED a un prototipo HR/SpO2 esistente. (Immagine per gentile concessione di Silicon Labs)

A parte l'aggiunta di un driver e di servizi di supporto per la scheda OLED, l'applicazione software rimane in gran parte invariata per questa versione estesa dell'applicazione HR/SpO2. Il timer software menzionato sopra per l'applicazione HR/SpO2 aggiunge una chiamata alla funzione hrm_update_display, che visualizza i dati HR e SpO2 (Listato 2).

Copy
    /* 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;
Listato 2: Utilizzando il kit e l'ecosistema software, gli sviluppatori possono aggiungere funzionalità di visualizzazione a un'applicazione HR/SpO2 esistente collegando una scheda e apportando modifiche minime al software, oltre ad aggiungere una chiamata di funzione, hrm_update_display, al gestore del timer dell'applicazione esistente. (Codice sorgente per gentile concessione di Silicon Labs)

Questo approccio hardware e software estensibile permette agli sviluppatori di creare rapidamente applicazioni IoT funzionanti. Poiché sia l'hardware che il software possono essere facilmente aggiunti o rimossi, gli sviluppatori possono esplorare più facilmente nuove soluzioni progettuali e valutare configurazioni alternative.

Conclusione

I dispositivi IoT alimentati a batteria e abilitati al Bluetooth sono il cuore delle applicazioni più diffuse e sono il movente che soddisfa la continua domanda di più funzionalità e di una maggiore durata operativa. Per gli sviluppatori, soddisfare queste richieste contrastanti in modo efficace richiede la capacità di esplorare rapidamente nuovi progetti e valutare concetti progettuali alternativi. Utilizzando un kit di sviluppo e il software associato di Silicon Labs, gli sviluppatori possono creare rapidamente prototipi, aggiungendo e rimuovendo l'hardware come necessario per soddisfare i requisiti di applicazioni specifiche.

Esonero della responsabilità: le opinioni, le convinzioni e i punti di vista espressi dai vari autori e/o dai partecipanti al forum su questo sito Web non riflettono necessariamente le opinioni, le convinzioni e i punti di vista di Digi-Key Electronics o le sue politiche.

Informazioni su questo autore

Stephen Evanczuk

Stephen Evanczuk ha più di 20 anni di esperienza come autore sull'industria elettronica e ha scritto su una vasta gamma di argomenti tra cui hardware, software, sistemi e applicazioni, incluso l'IoT. Ha ricevuto un Ph.D. in neuroscienze sulle reti neuronali e ha lavorato nel settore aerospaziale su sistemi di sicurezza ampiamente distribuiti e sui metodi di accelerazione algoritmica. Attualmente, quando non scrive articoli su tecnologia e ingegneria, lavora su applicazioni di deep learning per i sistemi di riconoscimento e di raccomandazione.

Informazioni su questo editore

Editori nordamericani di Digi-Key