Benchmark: IoT-Mikrocontroller mit BLE IoTMark-BLE in der Praxis – Teil 1

Test-Vorbereitung für IoT-Mikrocontroller mit BLE in einer Testumgebung aus Hard- und Software.
Test-Vorbereitung für IoT-Mikrocontroller mit BLE in einer Testumgebung aus Hard- und Software.

Im Rahmen eines Elektronik-Projekts wurde an der TU Hamburg der Benchmark IoTMark-BLE des Embedded Microprocessor Benchmark Consortium (EEMBC) – eine Testumgebung aus Hard-und Software – genauer untersucht. Im Teil 1 geht es um die Test-Vorbereitungen, in Teil 2 folgt die Umsetzung in der Praxis.

Ein IoT-Gerät verfügt üblicherweise über einen Funktransceiver, der, ungeachtet der jeweiligen Technik (WLAN, BLE, Zigbee, Z-Wave) von allen integrierten Mikrocontroller-Einheiten die höchste Stromaufnahme aufweist. Das erfordert eine an die jeweilige Anwendung angepasste Programmierung, damit der Transceiver möglichst lange in einem Stromsparmodus verweilen kann. Wie hoch die Stromaufnahme in der Praxis ausfällt, hängt auch ganz maßgeblich vom internen Aufbau des jeweiligen IC ab und wie sich der Mikrocontroller programmieren lässt.

Die in den Datenblättern angegebenen Werte stellen sich meist nicht ein und lassen sich auch selten zwischen ICs verschiedener Hersteller vergleichen, weil hier jeder Hersteller unterschiedliche (eigene) Kriterien zugrunde legt. Deshalb hat das EEMBC den Benchmark-Test IoTMark-BLE entwickelt, der mit den Testkandidaten für dieses Elektronik-Projekt in [1] ausführlich vorgestellt wurde. An dieser Stelle wird lediglich der Messaufbau für den IoTMark-BLE nochmals gezeigt (Bild 1).

Ein Arduino Uno fungiert dabei als E/A-Manager, ein Raspberry Pi als Funk-Manager, der den BLE-Client für das Device Under Test (DUT) bildet. Das X-Nucleo-Board von STMicroelectronics stellt das zentrale Element, den Powermanager, dar. Die Software für diese drei Komponenten sowie die PC-Software für das Host-System (iotconnect.exe) wird von EEMBC geliefert.

Von den sechs Kandidaten, mit denen wir das Elektronik-Projekt starteten [1], sind nur noch zwei übriggeblieben, wobei zwei weitere im Projektverlauf hinzugekommen sind, sodass wir den Benchmark IoTMark-BLE mit den folgenden vier Mikrocontrollern mit integriertem BLE-Transceiver untersuchen konnten:

  • PSoC 4 BLE, BT 4.2, Cortex M0 von Cypress,
  • RSL 10, BT 5.0, Cortex M3, von ON Semiconductor,
  • EFR32BG1 Blue Gecko Bluetooth Smart SoC, BT 4.2, Cortex M4 von Silicon Labs und
  • TC35678FSG, BT 4.2, Cortex M0 von Toshiba

Die notwendigen Testroutinen (ca. 75 KB) wurden unter IAR Embedded Workbench programmiert – soweit es möglich war.

Die Gründe dafür, warum einige der ursprünglich angetretenen Kandidaten auf der Strecke geblieben sind, hatten sich bereits wie in [1] beschrieben angekündigt und liegen im Wesentlichen an mangelhaften Dokumentationen sowie ungenügender bis auch überhaupt nicht stattfindender Unterstützung durch die Hersteller.

Das CY8CKIT-042-BLE-A (PSoC4 BLE) von Cypress [2] machte in puncto Aufbau, Ausstattung, Dokumentation sowie verfügbarer Software von Anfang an einen guten Eindruck.

Toshiba ersetzte wie angekündigt das BLE-4.2-Starterkit, was als Vorserienmodell auf einer Europlatine mit zahlreichen Jumpern versehen war, durch ein kompaktes Evaluation Board (Bild 2), das direkt an den USB-Anschluss eines PC gesteckt wird.

Beide Toshiba-Systeme verwenden den TC35678FSG [3], sodass es für die Software-Entwicklung im Prinzip keinen Unterschied macht, welches der beiden Systeme verwendet wird.

Eingesetzt wurde der USB Evaluation Stick mit dem TC35678FSG-FSG002, der in einem auf der Platine aufgesetzten Modul von Panasonic (PAN1760A) untergebracht ist. Die Platine verfügt über Pfostenstecker, wo die Spannungsversorgung und die GPIO-Ports angeschlossen sind, über einen Reset-Taster, einige Konfigurations-Jumper sowie über einen integrierten USB-Adapter (FTDI) und einen J-Link-Adapter (Segger) für die Kommunikation, die Programmierung und das Debugging.

Für den Benchmark ist das Toshiba-Modul auf eine externe Spannungsversorgung (3-V-Jumper) und auf den Standalone-Modus einzustellen, bei dem der TC35678FSG-002 alle Funktionen übernimmt und nicht von einem externen Mikrocontroller (Host Mode) gesteuert wird.

Die Verbindungen zum Energie-Monitor und zum E/A-Manager sind wie folgt (Bild 3):

  • Stromversorgung: Masse- und UB (3-V-Anschluss)
  • Zeitstempel: GPIO 10
  • I2C SCL: GPIO 11
  • I2C SDA: GPIO 12
  • UART TX: GPIO 5
  • UART RX: GPIO 6

Die Firma On Semiconductor hatte von unseren Tests gehört und uns das Evaluationsboard RSL10-002GEVB [4] mit dem RSL10, der als einziger der Testkandidaten auch BLE 5.0 komplett unterstützt, zugeschickt, sodass wir dieses System ebenfalls mit in den Test aufgenommen haben.

Das Modul von On Semiconductor (Bild 4) verfügt über mehrere Jumper für die Festlegung der Spannungsversorgung, die standardmäßig 3,3 V beträgt, über zwei Taster (Reset, an DIO5) sowie über die Anschlüsse für die Kommunikation mit einem Host (PC an USB) und die Programmierung (JTAG).

Eine LED signalisiert die JTAG-Aktivität, die zweite ist an den Port DIO6 angeschlossen. Die Buchsenleiste ist Arduino-kompatibel, und eine Schaltung zur Anpassung der Logikpegel sorgt dafür, dass das mit 3,3 V betriebene Modul an seinen digitalen E/As mit den 5-V-Pegeln des Arduino umgehen kann. Als Besonderheit ist eine Buchse für die Strommessung eingebaut, die allerdings nur dann funktioniert, wenn eine externe Spannungsquelle eingesetzt wird, was dann eigentlich überflüssig ist.

Gute Erfahrungen hatten wir bereits in verschiedenen vorhergehenden Projekten mit den Gecko-Controllern und dem Funkmodul BGM113 [5] von Silicon Labs gesammelt (Bild 5). Für den Mikrocontroller mit BLE-Transceiver (EFR32BG) lag bereits geeigneter Quellcode vor und es bestand die Hoffnung, dass der Aufwand für die zusätzlichen Benchmark-Routinen relativ gering ist. Beim verwendeten BGM113 handelt es sich um ein Blue-Gecko-Modul (Transceiver), das auf ein Wireless Starter Kit Mainboard gesteckt wird. Dieses Mainboard kann mit verschiedenen Funkmodulen umgehen.

Auf dem Mainboard sind neben den üblichen Anschlüssen einige zusätzliche Peripherie-Elemente wie Sensoren und ein Display vorhanden, die für den Benchmark nicht notwendig sind und deren Stromaufnahme fälschlicherweise mit in das Ergebnis eingehen würde.

Deshalb ist es für den Benchmark-Test wichtig, dass sich unnötige Elemente komplett deaktivieren lassen. Dies gilt generell für alle Komponenten, die nicht für den Betrieb als DUT beim IoTMark-BLE notwendig sind, also auch für das USB-Interface und die Debugger-Schaltung. Beim Mainboard des Wireless Starter Kit von Silicon Labs müssen Peripherie-Elemente erst explizit aktiviert werden. Die jeweiligen Versorgungsleitungen werden hier vom Mikrocontroller auf dem Mainboard geschaltet, gleichwohl braucht er natürlich auch Strom.

Für die Tests haben wir bei allen Boards die Spannungsversorgung stets so angeschlossen, dass möglichst nur der zu prüfende IoT-Mikrocontroller mit der für ihn notwendigen Peripherie versorgt wird und alles andere abgeschaltet ist. Änderungen an der Hardware, wie etwa das Durchtrennen von Leitungen für die Spannungsversorgung oder Ähnliches, wurden allerdings nicht durchgeführt.