Schnelles Prototyping von Bluetooth-IoT-Anwendungen mit einem Entwicklungskit und handelsüblichen Erweiterungskarten

Die Nachfrage nach intelligenten, vernetzten Produkten bietet breite Möglichkeiten für Entwickler, Konzepte schnell in funktionierende IoT-Anwendungen (IoT: Internet der Dinge) umzusetzen. Die Verfügbarkeit energieeffizienter Prozessoren, drahtloser Vernetzungsoptionen und einer breiten Palette von Hardware-Peripheriekomponenten bietet eine solide Grundlage für die Implementierung geeigneter stromsparender, produktionsreifer Designs.

In der frühen Phase der Produktdefinition benötigen die Entwickler jedoch eine flexible Entwicklungsplattform für den Aufbau schneller Prototypen, die auf der gleichen Klasse von Prozessoren, Netzwerk-Subsystemen und Peripheriekomponenten basieren. Die Fähigkeit, schnell funktionierende Prototypen zu erstellen und auf einfache Weise Funktionen hinzuzufügen, ist für die Bereitstellung früher Konzeptnachweise und für die Unterstützung der kundenspezifischen Softwareentwicklung unerlässlich.

Dieser Artikel zeigt, wie Entwickler mit Hard- und Software von Silicon Labs schnell spezialisierte energieeffiziente vernetzte IoT-Geräteprototypen mit einer breiten Auswahl an leicht erhältlichen, handelsüblichen Erweiterungskarten bauen können.

Schnelles Prototyping

Bei der Erkundung neuer Möglichkeiten für batteriebetriebene drahtlose IoT-Geräte können sich Entwickler durch die vielen Details, die mit der Erstellung einer funktionierenden Entwicklungsplattform verbunden sind, verzetteln. Mit ihren integrierten Subsystemen können fortschrittliche System-on-Chip-Bausteine (SoC) den Kern einer solchen Plattform bilden, aber Entwickler müssen dennoch ein komplettes System um sie herum aufbauen.

Um eine geeignete Entwicklungsplattform für diese Geräte zu erstellen, müssen die Entwickler nicht nur die grundlegenden Anforderungen an eine robuste Leistung und eine lange Akkulaufzeit erfüllen, sondern auch Flexibilität einbauen, um die spezifischen Anforderungen der jeweiligen Anwendung zu unterstützen. Das Explorerkit BGM220-EK4314A von Silicon Labs erfüllt diese Kombination von Anforderungen und ermöglicht es Entwicklern, sich auf das schnelle Prototyping neuer Designkonzepte zu konzentrieren, anstatt sich mit den Details beim Aufbau einer eigenen Entwicklungsplattform zu beschäftigen.

Flexible Plattform für schnelle Entwicklung

Das Explorerkit BGM220-EK4314A bietet eine kostengünstige Plattform für die Entwicklung von Bluetooth-basierten Anwendungen und kombiniert das Wireless-Gecko-Modul BGM220P (BGM220PC22HNA) von SiLabs, einen integrierten J-Link-Debugger von SEGGER, einen Taster, eine Leuchtdiode (LED) und mehrere Erweiterungsoptionen (Abbildung 1).

Abbildung 1: Das Explorerkit BGM220-EK4314A von SiLabs bietet die Kombination aus Verarbeitungsleistung, Energiemanagement und Konfigurationsflexibilität, die für den schnellen Aufbau von Prototypen und die Evaluierung verschiedener Peripherie-Hardwarekonfigurationen erforderlich ist. (Bildquelle: Silicon Labs)

Das BGM220P-Modul dient als Komplettlösung für kleine batteriebetriebene IoT-Geräte. Das integrierte Blue-Gecko-SoC EFR32BG22 zeichnet sich durch einen extrem niedrigen Stromverbrauch, Funktionen für Bluetooth-Einfallswinkel- (AoA) und -Austrittswinkel (AoD) sowie eine Ortungsgenauigkeit von weniger als einem Meter aus - alles Eigenschaften, die für eine wachsende Anzahl beliebter Bluetooth-Anwendungen benötigt werden, wie z. B. Tags zur Anlagenverfolgung, intelligente Türschlösser, Fitnessgeräte und vieles mehr.

Das BGM220P-Modul kann als eigenständiges System betrieben werden und kombiniert den EFR32BG22-SoC mit 512 KByte Flash, 32 KByte Arbeitsspeicher (RAM), Hochfrequenz(HF)- und Niederfrequenz(LF)-Quarzen (XTAL) sowie einem 2,4-GHz-Anpassungsnetzwerk und einer Keramikantenne für die drahtlose Vernetzung (Abbildung 2).

Abbildung 2: Das Modul BGM220P von SiLabs kann als eigenständiges System eingesetzt werden und kombiniert den Blue-Gecko-SoC EFR32BG22 mit zusätzlichen Komponenten, die zur Implementierung eines Bluetooth-fähigen Geräts benötigt werden. (Bildquelle: Silicon Labs)

Neben seiner Fähigkeit, als eigenständiger Host für IoT-Designs mit geringem Platzbedarf zu dienen, kann das Modul auch als Netzwerk-Coprozessor (NCP) für einen Host-Prozessor dienen, der über die UART-Schnittstelle des Moduls angeschlossen ist. Sein integrierter Bluetooth-Stack führt drahtlose Dienste für Anwendungen aus, die in Standalone-Designs auf dem Modul laufen, oder verarbeitet vom Host empfangene Befehle, wenn sie in NCP-Designs laufen.

Energieeffizientes Funk-SoC

Der Bluetooth-Funk-SoC EFR32BG22 des BGM220P-Moduls integriert einen 32-Bit-Arm-Cortex-M33-Kern, ein 2,4-GHz-Funkgerät, Sicherheits- und Energiemanagement-Subsysteme sowie mehrere Timer und Schnittstellenoptionen. Der EFR32BG22-SoC wurde speziell für batteriebetriebene Designs mit extrem niedrigem Stromverbrauch entwickelt und verfügt über mehrere Energiemanagement-Funktionen, die einen Betrieb mit Knopfzellenbatterien für bis zu zehn Jahre ermöglichen.

Der SoC wird mit einer einzigen externen Spannungsquelle betrieben und nutzt seine interne Energieverwaltungseinheit, um interne Versorgungsspannungen zu erzeugen. Während des Betriebs steuert die Energiemanagementeinheit die Übergänge zwischen den fünf Energiemodi (EMs) des SoCs. Jeder Modus reduziert den Stromverbrauch weiter, indem immer weniger aktive Funktionsblöcke beibehalten werden, wenn der SoC vom aktiven Modus (EM0) in den Schlafmodus (EM1), Tiefschlafmodus (EM2), Stoppmodus (EM3) oder Abschaltmodus (EM4) übergeht (Abbildung 3).

Abbildung 3: Die Energiemanagementeinheit des SoC EFR32BG22 steuert die Übergänge zwischen den Energiemodi EM0, EM1, EM2, EM3 und EM4 (Farbcode am unteren Bildrand). (Bildquelle: Silicon Labs)

Im aktiven Modus (EM0) bei 76,8 MHz und 3 Volt, unter Verwendung des internen DC/DC-Wandlers, zieht das SoC 27 Mikroampere pro Megahertz (μA/MHz). EM0 ist der normale Betriebsmodus und ist der einzige, in dem der Cortex-M33-Prozessorkern und alle Peripherieblöcke verfügbar sind.

Alle Peripherieblöcke sind im Ruhezustand (EM1) verfügbar, wobei weniger aktiv bleiben, wenn das System in noch stromsparendere Modi wechselt. In den stromsparenden Modi führt die Reduzierung der aktiven Takte und Funktionsblöcke zu einer deutlich geringeren Leistungsaufnahme:

• 17 μA/MHz im Ruhemodus (EM1)
• 1,40 μA im Tiefschlafmodus (EM2) mit 32 KByte RAM-Erhalt und Echtzeituhr (RTC), betrieben vom LFXO
• 1,05 μA im Stoppmodus (EM3) mit 8 KByte RAM-Erhalt und RTC, die vom integrierten 1kHz-RC-Oszillator (ULFRCO) des SoCs betrieben wird
• 0,17 μA im Abschaltmodus (EM4)

Einige batteriebetriebene Geräte benötigen mehr als die Fähigkeit, den Prozessor in Betriebsarten mit geringem Stromverbrauch zu betreiben. Viele Bluetooth-fähige Anwendungen weisen typischerweise längere Zeiträume mit geringer oder keiner Aktivität auf, erfordern aber eine Reaktionsfähigkeit mit geringer Latenz, wenn die Aktivität wieder einsetzt. Selbst wenn eine Anwendung geringere Anforderungen an die Latenzzeit hat, verschwendet eine langsame Aufwachzeit Strom, da der Prozessor keine nützliche Arbeit ausführt, während er den Aufwachprozess abschließt und in den aktiven Modus übergeht (oder den Prozess des Übergangs von einem Modus mit höherer Leistung in einen Modus mit geringerer Leistung abschließt).

Da die Zeit zwischen den aktiven Perioden schrumpft, kann die Verwendung eines energiesparenden Ruhemodus sogar kontraproduktiv werden, wenn eine langsame Aufwach- oder Aktivmodus-Eintrittszeit mehr Energie verbraucht, als wenn der Prozessor während der inaktiven Periode in einem Modus mit höherer Leistung verbleibt. Infolgedessen werden Entwickler, die an der Optimierung der Akkulaufzeit arbeiten, manchmal einen Prozessor in einem höheren Stromverbrauchsmodus halten, als es die Verarbeitungsanforderungen der Anwendung erfordern.

Durch die Verwendung eines Prozessors mit schnelleren Aufwach- und Eintrittszeiten können Entwickler die stromsparenden Modi des Prozessors besser ausnutzen. In EM1 wacht das EFG32BG22 in drei Takten/1,24 Mikrosekunden (µs) auf und hat eine Eintrittszeit von 1,29 µs, die sich in EM4 auf 8,81 Millisekunden (ms) bzw. 9,96 µs erhöht (Tabelle 1).

Tabelle 1: Aufwach- und Aktivmodus-Eintrittszeiten für das SoC EFG32BG22. (Tabellenquelle: Silicon Labs)

Die Methode, mit der der Prozessor bei Wiederaufnahme der Aktivität aufgeweckt wird, kann sich ebenfalls erheblich auf die Akkulaufzeit auswirken. Obwohl einige Anwendungen - z. B. in der Industrie - Systeme mit gepollter Verarbeitung erfordern, um ein striktes periodisches Timing zu gewährleisten, verwenden viele Anwendungen im Verbraucherbereich eine ereignisbasierte Verarbeitung, um auf bestimmte Aktivitäten zu reagieren. Die Verwendung von Polling-Methoden für ereignisbasierte Anwendungen kann z. B. die Batterielebensdauer erheblich beeinträchtigen, wenn der Prozessor wiederholt unnötig aufwacht.

So wie viele sensorbasierte Designs die Wake-on-Interrupt-Funktionalität nutzen, um ein wiederholtes Aufwecken des Prozessors zu vermeiden, nur um die Aktivität zu überprüfen, ermöglicht eine Wake-on-RF-Funktion, die in das Funk-Subsystem des EFG32BG22-SoCs integriert ist, einen ähnlichen interruptgesteuerten Ansatz. Dies ermöglicht es den Entwicklern, den Prozessor in einem Energiemodus mit geringerer Leistung zu halten, bis Hochfrequenzaktivität (HF) auftritt.

In der Praxis versetzen Entwickler den Funk-SoC EFG32BG22 in einen der drei Modi EM2, EM3 oder EM4 mit ultraniedriger Leistungsaufnahme und verlassen sich auf die Wake-on-RF-Fähigkeit, um den SoC aufzuwecken, wenn HF-Energie erkannt wird. Bei der einfachen Erkennung von Energie oberhalb des Schwellenwerts verbraucht die RFSENSE-Funktion 131 Nanoampere (nA). Ein selektiverer RFSENSE-Modus verbraucht mit 138 nA etwas mehr Strom, aber in diesem Modus filtert RFSENSE eingehende HF-Signale, um zu vermeiden, dass er auf HF-Rauschen statt auf ein gültiges HF-Signal aufweckt.

In einigen Fällen muss der EFG32BG22-SoC den Prozessorkern möglicherweise gar nicht aufwecken, um auf externe Ereignisse zu reagieren: Das Peripheral Reflex System (PRS) von SiLabs ermöglicht es Peripheriekomponenten, auf Ereignisse zu reagieren und zu arbeiten, ohne den Prozessorkern aufzuwecken. Peripheriekomponenten können direkt miteinander kommunizieren, und ihre Funktionen können kombiniert werden, um eine komplexe Funktionalität bereitzustellen. Durch die Verwendung von PRS-Funktionen mit niedrigeren Energiemodi können Entwickler den Stromverbrauch erheblich reduzieren, ohne kritische Funktionen wie die Sensordatenerfassung zu beeinträchtigen.

Eingebautes Debugging und einfache Erweiterung

Eingebaut in das Explorerkit-Board BGM220, bringt das BGM220P-Modul alle Energiemanagement- und Verarbeitungsfunktionen des SoCs EFR32BG22 in batteriebetriebene Bluetooth-Designs. Wenn es notwendig ist, schnell Prototypen zu bauen, um neue Designkonzepte zu erforschen, helfen andere Funktionen der Karte, die Entwicklung zu beschleunigen.

Über den USB-Micro-B-Anschluss des Boards ermöglicht ein integrierter SEGGER J-Link-Debugger den Code-Download und das Debugging sowie einen virtuellen COM-Port für den Zugriff auf die Host-Konsole. Der Debugger unterstützt auch die PTI-Funktion (Packet Trace Interface) von SiLabs zur Analyse von Paketen, die über ein drahtloses Netzwerk gesendet oder empfangen werden.

Für das Rapid Prototyping bietet das Board durch die Unterstützung mehrerer Erweiterungsoptionen die Flexibilität, neue Design-Ideen zu erforschen, die unterschiedliche Kombinationen von Sensoren, Aktuatoren, Konnektivitätsoptionen und anderen Peripheriegeräten benötigen. Aus der großen Vielfalt an verfügbaren mikroBUS-Zusatzkarten und Qwiic-Connect-System-Hardware verschiedener Hersteller können Entwickler schnell eine Entwicklungsplattform für jede Anwendung konfigurieren.

In den mikroBUS-Sockel des Boards eingesteckt, verbindet sich ein mikroBUS-Board über I²C-, SPI- oder UART-Schnittstellen mit dem BGM220P-Modul. Der Qwiic-Steckverbinder stellt die I²C-Schnittstelle des Qwiic-Systems für die Verbindung einer oder mehrerer Qwiic-Platinen über Entfernungen bis zu ca. 1,2 Meter (m) zur Verfügung. Für Verbindungen über größere Entfernungen können Entwickler das QwiicBus-EndPoint-Board (COM-16988) von SparkFun verwenden, das eine differentielle Signalisierung verwendet, um die I²C-Signalintegrität bei Entfernungen bis zu ca. 30 m zu erhalten.

Schnelle Anwendungsentwicklung

SiLabs wendet das Konzept der schnellen Expansion auf die Entwicklung von Anwendungssoftware an. Neben Board-Support-Paketen, Treibern, Bibliotheken und Headern für die kundenspezifische Entwicklung bietet das Unternehmen mehrere Beispielanwendungen, die in der Entwicklungsumgebung Simplicity Studio gebündelt sind, sowie zusätzliche Projekte, die in den GitHub-Repositories von SiLabs verfügbar sind. Tatsächlich können Entwickler die Entwicklung von Sensoranwendungen mit einer mitgelieferten Beispiel-Temperaturanwendung beginnen, die den internen Temperatursensor des SoC EFR32BG22 als Datenquelle nutzt.

Die Temperaturanwendung basiert auf dem Standarddienst „Bluetooth Health Temperature“ und bietet eine sofort einsatzbereite Demonstration des Verarbeitungsablaufs durch eine generische Bluetooth-IoT-Anwendung, die auf der SiLabs-Softwarearchitektur basiert. Die Anwendung ruft eine Reihe von Initialisierungsroutinen für Systemdienste und Anwendungsdienste auf, die Interrupt-Handler und Callbacks einrichten. Nach Abschluss der Initialisierung begibt sich die Anwendung in eine Endlosschleife, um auf Ereignisse zu warten (Listing 1).

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

In dieser Anwendung führt eine zugehörige Callback-Routine eine Temperaturmessung durch, wenn ein bei der Initialisierung gesetzter Timer herunterzählt. Nachdem Entwickler die Anwendung erstellt und in den Flash-Speicher des Boards geschrieben haben, können sie die App EFR Connect von SiLabs verwenden - eine generische mobile Bluetooth-App, die mit allen Bluetooth-Kits und -Geräten von Silicon Labs funktioniert. Neben der Bereitstellung des Frameworks für benutzerdefinierte Apps unterstützt die App die Entwicklung, indem sie eine Ansicht der unterstützten Merkmale bereitstellt, die mit einem Bluetooth-Dienst wie dem in dieser Beispielanwendung verwendeten Bluetooth-Health-Thermometer-Dienst verbunden sind (Abbildung 4).

Abbildung 4: Die SiLabs-App „EFR Connect“ zeigt die Eigenschaften der in einer Anwendung verwendeten Bluetooth-Dienste an und beschleunigt damit nicht nur die Entwicklung von Prototypen, sondern bietet auch einen Framework für die Entwicklung eigener Apps. (Bildquelle: Silicon Labs)

In Simplicity Studio können Entwickler eine Reihe von verschiedenen Bluetooth-Anwendungsbeispielen importieren, die unterschiedliche Einsatzszenarien demonstrieren, einschließlich Designs, die mit Qwiic- oder mikroBUS-Boards gebaut wurden, einzeln oder in Kombination. Zum Beispiel eine Beispielanwendung, die den Einsatz der Standard-Dienste „Bluetooth Heart Rate“ (HR) und „Bluetooth Pulse Oximeter“ (SpO2) in Kombination mit dem Heart-Rate-2-Click-mikroBUS-Board MIKROE-4037 von MikroElektronika demonstriert, das den Biosensor MAX86161 von Maxim Integrated enthält. Der MAX86161 bietet ein komplettes Subsystem mit geringem Stromverbrauch, das in der Lage ist, genaue HR- und SpO2-Messungen an einen über seine I²C-Schnittstelle angeschlossenen Host-Prozessor zu liefern. (Weitere Informationen zur Verwendung des MAX86161 finden Sie unter Entwicklung von echten Wireless-Fitness-Hearables – Teil 1: Herzfrequenz- und SpO2-Messung).

Mit ihrem Bedarf an einem zusätzlichen Treiber und einem anspruchsvolleren Verarbeitungsalgorithmus als bei der Temperaturanwendung bietet diese Anwendung eine komplexere Demonstration einer IoT-Geräte-Softwareanwendungsarchitektur (Abbildung 5).

Abbildung 5: Beispielprojekte wie eine HR/SpO2-Anwendung helfen, die Prototypenentwicklung zu beschleunigen und demonstrieren gleichzeitig einen typischen Prozessablauf für Bluetooth-Sensoranwendungen mit geringer Leistungsaufnahme. (Bildquelle: Silicon Labs)

Wie bei der oben erwähnten Temperaturanwendung stützt sich diese Anwendung auf eine Reihe von Initialisierungsroutinen, um das System und die Anwendungsdienste einzurichten. Wenn die Routine app_process_action in der Temperaturanwendung leer ist, fügt diese Anwendung einen Aufruf der Routine hrm_loop zu app_process_action hinzu. Dies führt zu einem Aufruf von hrm_loop bei jedem Durchlauf durch die Endlosschleife der obersten Ebene, die zuvor in Listing 1 gezeigt wurde. Darüber hinaus wird ein Software-Timer verwendet, um die HR- und SpO2-Daten periodisch zu aktualisieren.

Die Routine hrm_loop ruft wiederum maxm86161_hrm_process auf, die Proben aus einer von Hilfsfunktionen gepflegten Warteschlange zieht und an eine Probenprozessroutine weitergibt. Dies wiederum ruft ein Paar von Routinen auf, maxm86161_hrm_frame_process und maxm86161_hrm_spo2_frame_process, die Algorithmen zur Validierung und Erzeugung von HR- bzw. SpO2-Ergebnissen ausführen. Entwickler können die Ergebnisse zusammen mit anderen Service-Merkmalen mit der bereits erwähnten EFR-Connect-App anzeigen.

Ein weiteres Anwendungsbeispiel zeigt, wie Entwickler auf eine komplexe Anwendung wie diese HR/SpO2-Anwendung aufbauen können, wenn sie ihre Hardware-Plattform erweitern. Mit dem Explorerkit-Board BGM220-EK4314A und dem Software-Ökosystem von SiLabs ist es relativ einfach, auf vorhandener Hardware und Software aufzubauen. SiLabs demonstriert diesen Ansatz mit einer Beispielanwendung, die die für die obige HR/SpO2-Anwendung verwendete Hardware/Software-Plattform um ein OLED-Display erweitert. In diesem Beispiel wird eine Qwiic-Zusatzplatine (LCD-14532) von SparkFun mit einem OLED-Display an den Qwiic-Anschluss der Platine angeschlossen, während die Heart-Rate-2-Click-Zusatzplatine von MikroElektronika aus der vorherigen HR/SpO2-Beispielanwendung an ihrem Platz bleibt (Abbildung 6).

Abbildung 6: Entwickler können einem bestehenden Design, das auf dem Explorerkit-Board BGM220-EK4314A aufgebaut ist, schnell Funktionalität hinzufügen - hier das Hinzufügen eines OLED-Displays zu einem bestehenden HR/SpO2-Prototyp. (Bildquelle: Silicon Labs)

Abgesehen von der Hinzufügung eines Treibers und von Unterstützungsdiensten für das OLED-Board bleibt die Softwareanwendung für diese erweiterte Version der HR/SpO2-Anwendung weitgehend gleich. Der bereits erwähnte Software-Timer für die HR/SpO2-Anwendung fügt einen Aufruf der Funktion hrm_update_display hinzu, die die HR- und SpO2-Daten anzeigt (Listing 2).

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

Dieser erweiterbare Hardware- und Software-Ansatz ermöglicht es Entwicklern, schnell funktionierende IoT-Anwendungen zu erstellen. Da sowohl Hardware als auch Software einfach hinzugefügt oder entfernt werden können, können Entwickler leichter neue Designlösungen erforschen und alternative Konfigurationen bewerten.

Fazit

Batteriebetriebene Bluetooth-fähige IoT-Geräte bilden das Herzstück beliebter Anwendungen und sind der Schlüssel, um die anhaltende Nachfrage nach mehr Funktionalität und längerer Lebensdauer zu erfüllen. Um diese widersprüchlichen Anforderungen effektiv erfüllen zu können, müssen Entwickler in der Lage sein, schnell neue Designs zu erforschen und alternative Designkonzepte zu bewerten. Mit Hilfe eines Entwicklungskits und der zugehörigen Software von Silicon Labs können Entwickler schnell Prototypen erstellen und je nach Bedarf Hardware hinzufügen oder entfernen, um spezifische Anwendungsanforderungen zu erfüllen.