Utfør hurtig prototyping av Bluetooth IoT-programmer med et utviklingssett og standard tilleggskort

Etterspørselen etter smarte tilkoblede produkter gir mange muligheter for utviklere, som raskt kan gjøre konsepter om til fungerende IoT-programmer. Tilgjengeligheten av energieffektive prosessorer, alternativer for trådløs tilkobling og et bredt utvalg av maskinvareperiferiutstyr, gir et solid grunnlag når det er snakk om å implementere egnede produksjonsklare konstruksjoner med lavt energiforbruk.

Under den tidlige fasen av produktdefinisjonen trenger imidlertid utviklerne en fleksibel utviklingsplattform for å bygge raske prototyper basert på samme prosessorklasser, konnektivitetsdelsystemer og periferiutstyr. Muligheten til å raskt bygge fungerende prototyper og enkelt legge til funksjonalitet er avgjørende for å gi tidlig bevis på konsept og legge til rette for tilpasset programvareutvikling.

Denne artikkelen viser hvordan utviklere kan bruke maskinvare og programvare fra Silicon Labs til å raskt bygge spesialiserte energieffektive tilkoblede IoT-enhetsprototyper ved hjelp av et bredt utvalg av lett tilgjengelige standard tilleggskort.

Muliggjøre rask prototyping

Når man utforsker nye muligheter for batteridrevne trådløse IoT-enheter, blir gjerne utviklere overveldet av de mange detaljene som er involvert i å lage en fungerende utviklingsplattform. Med de integrerte delsystemene kan avanserte «system på en brikke»-enheter (SoC – System on Chip) gi grunnleggende funksjonalitet til en slik plattform, men utviklere må fortsatt bygge et komplett system rundt disse.

For å bygge en egnet utviklingsplattform for disse enhetene, må utviklere oppfylle grunnleggende krav til robust ytelse og forlenget batterilevetid, i tillegg til å bygge inn fleksibilitet for å støtte de spesifikke kravene for hvert program. Silicon Labs BGM220-EK4314A-utforskersettet (Explorer Kit) dekker denne kombinasjonen av behov, slik at utviklere kan fokusere på å raskt lage nye konstruksjonskonsepter istedenfor å håndtere alle detaljene som er involvert i å bygge sin egen utviklingsplattform.

Fleksibel plattform for rask utvikling

BGM220-EK4314A-utforskersettet (Explorer Kit), som tilbyr en lavprisplattform for utvikling av Bluetooth-baserte programmer, kombinerer SiLabs sin BGM220P Wireless Gecko-modul (BGM220PC22HNA), en integrert SEGGER J-Link-feilsøker, en trykknapp, en lysdiode (LED) og flere utvidelsesalternativer (figur 1).

Figur 1: SiLabs BGM220-EK4314A Explorer Kit gir en kombinasjonen av behandlingssytelse, energistyring og konfigurasjonsfleksibilitet, noe som er nødvendig for å raskt bygge prototyper og evaluere forskjellige konfigurasjoner for periferimaskinvare. (Bildekilde: Silicon Labs)

BGM220P-modulen fungerer som en ferdigløsning for små batteridrevne IoT-enheter. Den integrerte EFR32BG22 Blue Gecko SoC-en har svært lavt strømforbruk, egenskaper for Bluetooth-ankomstvinkel (AoA – Angle of Arrival) og -utgangsvinkel (AoD – Angle of Departure) og lokaliseringsnøyaktighet på under én meter – alt som trengs på tvers av et voksende utvalg av populære Bluetooth-konstruksjoner, deriblant merker for sporing av eiendeler, smarte dørlåser, trening og mer.

BGM220P-modulen, som er i stand til å fungere som et frittstående system, kombinerer EFR32BG22 SoC-en med 512 kbyte flash, 32 kbyte RAM-minne, høyfrekvente (HF) og lavfrekvente (LF) krystaller (XTAL) og et samsvarende 2,4 gigahertz (GHz) nettverk og keramisk antenne for trådløs tilkobling (figur 2).

Figur 2: SiLabs BGM220P-modulen, som er i stand til å fungere som et frittstående system, kombinerer EFR32BG22 Blue Gecko SoC-en med andre komponenter som er nødvendige for å implementere en Bluetooth-aktivert enhet. (Bildekilde: Silicon Labs)

I tillegg til å kunne fungere som en frittstående vert for små IoT-konstruksjoner, kan modulen også fungere som en nettverkskoprosessor (NCP – network coprocessor) for en vertsprosessor som er koblet til via modulens UART-grensesnitt. Den integrerte Bluetooth-stakken utfører trådløse tjenester for programmer som kjører på modulen i frittstående konstruksjoner, eller behandler kommandoer mottatt fra verten når den kjører i NCP-konstruksjoner.

Energieffektiv trådløs SoC

BGM220P-modulens trådløse EFR32BG22 Bluetooth SoC integrerer en 32-biters Arm Cortex-M33-kjerne, en 2,4 GHz-radio, sikkerhet, energistyringsdelsystemer og flere alternativer for timere og grensesnitt. EFR32BG22 SoC-en er utviklet spesielt for batteridrevne konstruksjoner med ultralavt strømforbruk, og den bruker flere energistyringsfunksjoner som kan muliggjøre knappcellebatteridrift i opptil ti år.

SoC-en styres fra én enkelt ekstern spenningskilde, og den bruker den interne energistyringsenheten til å generere interne forsyningsspenninger. Under drift styrer energistyringsenheten overgangene mellom SoC-ens fem energimoduser (EM-er – energy modes). Hver enkelt modus reduserer strømforbruket ytterligere ved å opprettholde gradvis færre aktive funksjonelle blokker når SoC-en går fra aktiv modus (EM0) til hvilemodus (EM1), dvalemodus (EM2), stopp-modus (EM3) eller avstengningsmodus (EM4) (figur 3).

Figur 3: Energistyringssystemet til EFR32BG22 SoC-en styrer overganger mellom energimodusene EM0, EM1, EM2, EM3 og EM4 (fargekode nederst på bildet). (Bildekilde: Silicon Labs)

I aktiv modus (EM0) ved 76,8 MHz og 3 volt, trekker SoC-en 27 mikroampere per megahertz (μA/MHz) ved å bruke den interne DC/DC (likestrøm/likestrøm)-omformeren. EM0 er den normale driftsmodusen, og det er den eneste modusen der Cortex M33-prosessorkjernen og alle periferiblokker er tilgjengelige.

Alt periferiutstyr er tilgjengelig i hvilemodus (EM1), der færre forblir aktive når systemet går inn i enda lavere strømmoduser. I de mer effektsparende modusene fører reduksjonen i aktive klokke- og funksjonsblokker til betydelig lavere strømforbruk:

• 17 μA/MHz i hvilemodus (EM1)
• 1,40 μA i dvalemodus (EM2) med 32 Kbyte RAM-lagring og sanntidsklokke (RTC– real-time clock) som kjører fra LFXO
• 1,05 μA i stopp-modus (EM3) med 8 Kbyte RAM-lagring og RTC som kjører fra SoC-ens integrerte motstand-kondensator (RC – resistor-capacitor)-oscillator (ULFRCO – Ultra-Low Frequency Resistor-Capacitor Oscillator) med en ultralav frekvens på 1 kilohertz (kHz)
• 0,17 μA i avstengningsmodus (EM4)

Noen batteridrevne enheter trenger mer enn å kunne betjene prosessoren i driftsmoduser med lavt energiforbruk. Mange Bluetooth-aktiverte programmer vil vanligvis utvise lengre perioder med liten eller ingen aktivitet, men krever reaksjonsfølsomhet med lav latenstid når aktiviteten gjenopptas. Faktisk, selv om et program har mer ettergivende krav når det kommer til latenstid, sløser en langsom vekketid strøm siden prosessoren ikke utfører noe nyttig arbeid når den utfører vekkeprosessen og går over til aktiv modus (eller fullfører prosessen med å gå inn i en modus med lavere strømforbruk fra en modus med høyere strømforbruk).

Etter hvert som tiden mellom aktive perioder krymper, kan bruken av hvilemodus med lavt strømforbruk til og med virke mot sin hensikt når en langsom oppføringstid for vekking eller strømmodus bruker mer energi enn det som ville blitt brukt hvis prosessoren forble i en høyere strømmodus i den inaktive perioden. Som et resultat vil utviklere som jobber med å optimalisere batterilevetiden noen ganger holde en prosessor i en høyere strømmodus enn det som kreves av prosesseringsbehovet til programmet.

Ved å bruke en prosessor med raskere vekketid og oppføringstid, kan utviklere dra full nytte av prosessorens moduser med lavere strømforbruk. I EM1 våkner EFG32BG22 i løpet av tre klokker/1,24 mikrosekunder (µs), og den har en oppføringstid på 1,29 µs, som stiger til henholdsvis 8,81 millisekunder (ms) og 9,96 µs i EM4 (tabell 1).

Tabell 1: Oppføringstider for oppvåknings- og strømmodus for EFG32BG22 SoC. (Tabellkilde: Silicon Labs)

Måten som brukes til å vekke prosessoren på når aktiviteten gjenopptas, kan også påvirke batterilevetiden betydelig. Selv om noen programmer – for eksempel industrielle – krever at systemer bruker pollet prosessering til å sikre streng periodisk timing, bruker mange programmer i forbrukermarkedet hendelsesbasert prosessering til å respondere på spesifikk aktivitet. Bruk av pollingmetoder for hendelsesbaserte programmer, for eksempel, kan i høy grad tære på batterilevetiden når prosessoren våkner gjentatte ganger unødvendig.

På samme måte som mange sensorbaserte konstruksjoner bruker oppvekking-ved-avbrudd-funksjonalitet (wake-on-interrupt) til å unngå å gjentatte ganger vekke prosessoren bare for å se etter aktivitet, muliggjør en oppvekking-ved-RF (wake-on-RF)-funksjonalitet integrert i EFG32BG22 SoC-ens radioundersystem en lignende avbruddsstyrt tilnærming. Dette gjør det mulig for utviklere å holde prosessoren i en energimodus med lavere strømforbruk inntil radiofrekvensaktivitet oppstår.

I praksis setter utviklerne den trådløse SoC-en EFG32BG22 i en EM2-, EM3- eller EM4-modus med ultralavt energiforbruk, og er avhengig av oppvekking-ved-RF-funksjonaliteten for å vekke SoC-en når RF-energi detekteres. Når det kun detekteres energi over terskelen, bruker RFSENSE-funksjonen 131 nanoampere (nA). En mer selektiv RFSENSE-modus bruker litt mer strøm, 138 nA, men i denne modusen filtrerer RFSENSE innkommende RF-signaler for å unngå å vekke ved RF-støy i stedet for et gyldig RF-signal.

I noen tilfeller trenger kanskje ikke EFG32BG22 SoC-en å vekke prosessorkjernen i det hele tatt for å respondere på eksterne hendelser: SiLabs sitt PRS-system (PRS – Peripheral Reflex System) gjør det mulig for periferienheter å respondere på hendelser og fungere uten å vekke prosessorkjernen. Periferiutstyr kan kommunisere direkte med hverandre, og funksjonene deres kan kombineres for å gi kompleks funksjonalitet. Ved å bruke PRS-funksjoner med lavere energimoduser, kan utviklere redusere strømforbruket betydelig uten at det går på akkord med kritisk funksjonalitet som sensordatainnsamling.

Innebygd feilsøking og enkel utvidelse

BGM220P-modulen, som er integrert i BGM220 Explorer Kit-kortet, bringer hele funksjonssettet for energistyring og prosessering fra EFR32BG22 SoC-en til batteridrevne Bluetooth-konstruksjoner. Når det er behov for å raskt bygge prototyper for å utforske nye konstruksjonskonsepter, bidrar andre funksjoner i kortet til å fremskynde utviklingen.

En integrert SEGGER J-Link-feilsøker, som er tilgjengelig via kortets Micro-B-kontakt, muliggjør nedlasting og feilsøking av kode, samt en virtuell COM-port for vertskonsolltilgang. Feilsøkingsprogrammet støtter også SiLabs sitt pakkesporingsgrensesnitt (PTI – packet trace interface) for analyse av pakker som overføres eller mottas over et trådløst nettverk.

For rask prototyping, gir kortets støtte for flere utvidelsesalternativer fleksibilitet når det gjelder å utforske nye konstruksjonsideer som har behov for ulike kombinasjoner av sensorer, aktuatorer, tilkoblingsalternativer og annet periferiutstyr. Ved å benytte seg av det omfattende utvalget av tilgjengelige MikroBUS-tilleggskort og utstyr for Qwiic-kontaktsystem fra flere leverandører, kan utviklere raskt konfigurere en utviklingsplattform for hvert program.

Et mikroBUS-kort, som er plugget inn i kortets mikroBUS-kontakt, kobles til BGM220P-modulen via I²C-, SPI- eller UART-grensesnitt. Qwiic-kontakten leverer Qwiic-systemets I²C-grensesnitt, som kobles til ett eller flere Qwiic-kort over avstander på opptil omtrent 1,2 meter (4 fot). For tilkoblinger over lengre avstander, kan utviklere bruke SparkFun QwiicBus EndPoint-kortet (COM-16988), som bruker differensiell signalering til å opprettholde I²C-signalintegritet over avstander på opptil ca. 30 meter (100 fot).

Rask utvikling av programmer

SiLabs anvender konseptet om rask ekspansjon for utvikling av programvare. I tillegg til kortstøttepakker, drivere, biblioteker og headere for tilpasset utvikling, tilbyr selskapet flere eksempelprogrammer som er medfølgende i Simplicity Studio-utviklingsmiljøet, samt flere prosjekter som er tilgjengelige fra SiLabs sin GitHub-lagringsplass. Faktisk kan utviklere begynne å utforske utviklingen av sensorprogrammer med et medfølgende eksempeltemperaturprogram som bruker EFR32BG22 SoC-ens interne temperatursensor som datakilde.

Temperaturprogrammet er bygget rundt den standard Bluetooth Health Temperature-tjenesten, og tilbyr en bruksklar demonstrasjon av prosesseringsflyten gjennom et generisk Bluetooth IoT-program bygget på SiLabs-programvarearkitekturen. Programmet kaller opp en serie nullstillingsrutiner for systemtjenester og programtjenester som konfigurerer avbruddsbehandlere og tilbakekallinger. Når nullstillingen er ferdig, går programmet inn i en endeløs sløyfe for å vente på hendelser (liste 1).

Kopi
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
}

I dette programmet utfører en tilknyttet tilbakekallingsrutine en temperaturmåling når en timer som er satt under nullstillingen teller ned. Når utviklere har bygget programmet og flashet kortet, kan de bruke SiLabs EFR Connect-appen – en generisk Bluetooth-mobilapp som fungerer med alle Silicon Labs Bluetooth-sett og -enheter. I tillegg til å levere rammeverket for tilpassede apper, legger appen til rette for utvikling ved å gi en oversikt over støttede egenskaper knyttet til en Bluetooth-tjeneste, for eksempel Bluetooth Health Thermometer-tjenesten som brukes i dette eksempelprogrammet (figur 4).

Figur 4: SiLabs EFR Connect-appen viser egenskapene til Bluetooth-tjenester som brukes i et program, ikke bare for å fremskynde prototypeutvikling, men også for å gi et rammeverk for utvikling av tilpassede apper. (Bildekilde: Silicon Labs)

I Simplicity Studio kan utviklere importere en rekke forskjellige Bluetooth-programeksempler som viser ulike bruksscenarier, deriblant konstruksjoner bygget med Qwiic- eller mikroBUS-kort, separat eller i kombinasjon. For eksempel, et eksempelprogram som demonstrerer bruken av standardtjenester som Bluetooth Heart Rate (HR) og Bluetooth Pulse Oximeter (SpO2) i kombinasjon med MikroElektronika MIKROE-4037 Heart Rate 2 Click mikroBUS-kort, som omfatter Maxim Integrated MAX86161-biosensor. MAX86161 leverer et ferdig undersystem med lavt strømforbruk som er i stand til å gi nøyaktige HR- og SpO2-målinger til en vertsprosessor som er koblet til via I²C-grensesnittet. (For å få mer informasjon om bruken av MAX86161, kan du se Bygg en ekte smart-hodetelefon – del 1: Hjerterytme- og SpO2-måling (Build a True Wireless Fitness Hearable—Part 1: Heart Rate and SpO2 Measurement)).

Med behovet for en ekstra driver og en mer krevende prosesseringsalgoritme sammenlignet med temperaturprogrammet, tilbyr dette programmet en mer kompleks demonstrasjon av en programvarearkitektur for IoT-enheter (figur 5).

Figur 5: Eksempelprosjekter som et HR/SpO2-program bidrar til å fremskynde utviklingen av prototyper og samtidig demonstrere en typisk prosessflyt for Bluetooth-sensorprogrammer med lavt strømforbruk. (Bildekilde: Silicon Labs)

I likhet med temperaturprogrammet nevnt ovenfor, er dette programmet avhengig av en serie nullstillingsrutiner for å konfigurere systemet og programtjenestene. Der rutinen app_process_action er tom i temperaturprogrammet, legger dette programmet til et kall i en rutine, hrm_loop, i app_process_action. Dette resulterer i et kall til hrm_loop ved hver gjennomføring i den endeløse sløyfen på øverste nivå som ble vist tidligere i liste 1. I tillegg brukes en programvaretimer til periodisk oppdatering av HR- og SpO2-data.

Hrm_loop-rutinen kaller deretter maxm86161_hrm_process, som innhenter samplinger fra en kø som vedlikeholdes av hjelpefunksjoner og overleverer dem til en eksempelprosessrutine. Dette kaller deretter et par rutiner, maxm86161_hrm_frame_process og maxm86161_hrm_spo2_frame_process, som kjører algoritmer for å bekrefte og generere henholdsvis HR- og SpO2-resultater. Utviklere kan se resultatene sammen med andre tjenesteegenskaper ved hjelp av EFR Connect-appen som ble nevnt tidligere.

Et annet eksempel på en programvare viser hvordan utviklere kan bygge på et komplekst program som dette HR/SpO2-programmet når de utvider maskinvareplattformen sin. Ved å bruke BGM220-EK4314A Explorer Kit-kortet og SiLabs-programvareøkosystemet, er det relativt enkelt å bygge på eksisterende maskinvare og programvare. SiLabs demonstrerer denne tilnærmingen med et eksempelprogram som legger til en OLED-skjerm til maskinvare-/programvareplattformen som brukes for HR/SpO2-programmet ovenfor. I dette eksempelet er et Qwiic-tilleggskort (LCD-14532) for SparkFun OLED-skjermen festet til kortets Qwiic-kontakt, mens MikroElektronika Heart Rate 2 Click-tilleggskortet forblir der det er fra det forrige HR/SpO2-eksempelprogrammet (figur 6).

Figur 6: Utviklere kan raskt legge til funksjonalitet til en eksisterende konstruksjon bygget på BGM220-EK4314A Explorer Kit-kortet – her legger de til en OLED-skjerm til en eksisterende HR/SpO2-prototype. (Bildekilde: Silicon Labs)

Bortsett fra å legge til en driver og støttetjenester for OLED-kortet, forblir programvaren stort sett slik det er for denne utvidede versjonen av HR/SpO2-programmet. Programvaretimeren som ble nevnt tidligere for HR/SpO2-programmet legger til et kall til funksjonen hrm_update_display, som viser HR- og SpO2-data (liste 2).

Kopi
    /* 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;

Denne utvidbare maskinvare- og programvaretilnærmingen gjør det mulig for utviklere å raskt bygge fungerende IoT-programmer. Fordi både maskinvare og programvare enkelt kan legges til eller fjernes, kan utviklere enklere utforske nye konstruksjonsløsninger og evaluere alternative konfigurasjoner.

Konklusjon

Batteridrevne Bluetooth-aktiverte IoT-enheter er grunnmuren til populære programmer, og de er svært viktige når det gjelder å møte den kontinuerlige etterspørselen etter mer funksjonalitet og lengre levetid. Hvis utviklere skal kunne møte disse motstridende kravene effektivt må de ha muligheten til å raskt utforske nye konstruksjoner og evaluere alternative konstruksjonskonsepter. Ved å bruke et utviklingssett og tilhørende programvare fra Silicon Labs, kan utviklere raskt bygge prototyper og legge til og fjerne maskinvare etter behov for å møte spesifikke programkrav.