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

Benchmark-Durchlauf

Nach dem erfolgreichen Build-Vorgang ist die Software auf den jeweiligen Mikrocontroller zu »flashen«, woraufhin sie als Firmware auf die EEMBC-Benchmark-Befehle reagiert. Dass der Benchmark dann sofort ohne Probleme durchläuft, ist unwahrscheinlich, denn es gibt bei der Firmware-Erstellung eine ganze Reihe von Unwägbarkeiten; ein erfolgreicher Compiler-Durchlauf und Flash-Vorgang bedeuten keineswegs, dass nicht noch Änderungen oder Korrekturen für den EEMBC-Benchmark notwendig sind. Anhaltspunkte dahingehend, was dann im Einzelnen noch falsch läuft, sind allein die Statusmeldungen im Konsolenfenster (siehe auch Bild 9) der Benchmark-Software.

Der Benchmark verläuft nach der Initialisierung (13 Schritte) grob in den drei Phasen Standby, Advertise und Connected Active Mode, in denen der aufgenommene Strom gemessen wird. In [6] ist dieser grundsätzliche Ablauf prinzipiell erläutert, in [1] etwas ausführlicher. Diese Informationen helfen zu verstehen, was in über 30 Schritten – die von über 250 Meldungen begleitet werden – genau abläuft. Aber sie reichen noch längst nicht aus, um etwa Fehler im eigenen Programmcode anhand der Meldungen identifizieren zu können.

Die notwendigen Routinen konnten für den PSoC4 BLE von Cypress, für den TC35678FSG von Toshiba und für den EFR32BG im BGM113 von Silicon Labs komplett implementiert werden, sodass der Benchmark IoTMark-BLE auch fehlerfrei durchlief. EEMBC empfiehlt als Versorgungspannung 3 V, die demnach auch bei allen drei Kandidaten verwendet wurde. Als Benchmark-Ergebnis erreicht der PSoC4 BLE dabei einen Score von 21,4, der TC35678FSG einen Wert von 20,8 und der EFR32BG (BGM113) einen Wert von 14,7.

Mit höherer Versorgungspannung von 3,3 V sinkt der Score (19,5/16,1/9,66) und mit niedriger (2,0 V) steigt der Score dementsprechend an (33,4/379/119). Diese Werte sind aber allesamt zu niedrig, denn laut EEMBC-Dokumentation sind hier Werte von 9500 und mehr zu erwarten.

Die einzelnen ermittelten Leistungsaufnahmen (Standby Power, Advertise Power, Active Power) sind bei unseren Messungen demnach um Zehnerpotenzen zu hoch.

Woran das im Einzelnen liegt, hätten wir gern vom EEMBC und den Herstellern erfahren, was uns mit Hinweisen auf Interna leider verweigert wurde. Gleichwohl sind unsere Ergebnisse reproduzierbar und liefern über mehrere Versionen des IoTMark-BLE tendenziell vergleichbare Ergebnisse.

Dabei sind für keinen der Mikrocontroller mit integriertem Bluetooth-Transceiver irgendwelche Optimierungen durchgeführt worden, es kam lediglich die zur Verfügung stehende Software mit den öffentlichen Dokumentationen zum Einsatz. Der Einfluss der I2C-Bus-Frequenz sowie die Datengröße, die über den I2C-Bus transportiert wird, was neben der Versorgungsspannung weitere einstellbare Optionen für den Test sind, führte kaum zu Veränderungen in der Stromaufnahme.

Interessant ist, wie sich der Score aus den Messwerten ergibt. Hierfür hat EEMBC mit der Version 1.0.x die folgende Formel veröffentlicht:

 

S c o r e subscript I o T M A r k minus B L E end subscript equals fraction numerator 10 to the power of 6 over denominator left parenthesis 1 comma 0 cross times c o n n e c t e d space mu J right parenthesis plus left parenthesis 0 comma 1 cross times a d v e r t i s e space mu J right parenthesis end fraction

 

Demnach errechnet sich der Score aus Connected Power und Advertise Power, was in den ersten Zeilen unter Benchmark Results (Bild 10) abzulesen ist – wenn man davon ausgeht, dass mit Active Power auch Connected Power gemeint ist, was aus den EEMBC-Dokumenten nicht eindeutig hervorgeht. Die jeweilige Leistungsangabe ist mit der dazugehörigen aktiven Zeit zu multiplizieren, die unter Decoded Timestamps und im Diagramm Energy Monitor ablesbar ist.

Es fällt zunächst auf, dass Stand-by Power überhaupt nicht mit in den Score eingeht, obwohl diese Messung ca. 30 s lang dauert. Die Low-Power-Funktionen (Sleep, Deep Sleep) sind im Prinzip ein wichtiger Teil des Benchmarks, deren Implementierung außerdem zu den schwierigeren Aufgaben bei der Programmierung gehört.

Dies ist kein Versehen, sondern von EEMBC so beabsichtigt, wie es in [6] angegeben ist und als Additional Information bezeichnet wird. Die Stand-by Power wird lediglich als Angabe bei den Benchmark Results geführt. Bei den vorherigen Versionen (<1.0.x) des IoTMark-BLE ging in die Score-Berechnung noch nicht einmal Advertise Power, sondern lediglich Active Power ein, was die Score-Angabe noch weniger aussagekräftig machte. In der Tabelle sind die Scores mit den einzelnen Leistungsmesswerten angegeben.

Demnach kann der TC35678FSG von Toshiba bei einer Versorgungsspannung von 2 V den höchsten Wert erreichen. Bei 3 V liegt er fast gleichauf mit dem Cypress PSoC4 BLE, dessen Resultate relativ unabhängig von der Versorgungsspannung sind. Der EFR32BG (BGM113) von Silicon Labs kann bei 2 V punkten und landet bei den beiden anderen Spannungen an letzter Stelle. Die Leistungsaufnahme beim Stand-by scheint nur beim TC35678FSG programmiertechnisch Auswirkungen zu zeigen, sonst ist sie (fast) identisch ist mit Advertise Power und Active Power.

Ein Benchmark – viele offene Fragen

Während der anderthalb Jahre, in denen sich die Mitarbeiter am Institut für Mikrosystemtechnik der Technischen Universität Hamburg mit dem IoTMark-BLE beschäftigt haben, haben sie mit dem EEMBC sowie mit den verschiedenen Halbleiterherstellern kommuniziert, die Testexemplare ihrer IoT-Mikrocontroller zur Verfügung stellten. Der Benchmark IoTMark-BLE wurde in der Version 1.0.x und der dazugehöri­gen Dokumentation IoTMark-BLE User Guide offiziell im September 2018 veröffentlicht.

Das EEMBC hatte bei jeder neuen Version leider die Start-up Sequence sowie den Ablauf der Test-Kommandos (Benchmark Flow) verändert, sodass die Ausgabe im Konsolenfenster mit den vorherigen Versionen nicht direkt vergleichbar ist und stets eine erneute, genaue Überprüfung der Schritte durch den Programmierer erforderlich macht.

Sowohl der Test selbst als auch die Dokumentation haben sich bei den verschiedenen getesteten Versionen zwar nur in Details verändert, gleichwohl erfordert die finale Version 1.0.x gegenüber der vorherigen (0.0.12) Code-Veränderungen, weil BLE Write without Response nun nicht mehr funktioniert, was definitiv nicht am damit getesteten Toshiba TC35678 liegt, weil der mit der implementierten Funktion einwandfreie Ergebnisse liefert.

Dies trifft nicht nur auf die vorherige Benchmark-Version zu, sondern auch auf die Überprüfung mit einem Samsung Tablet Galaxy Note 10 und der empfehlenswerten nRF Connect App von Nordic Semiconductor. Das EEMBC teilte hierzu mit, dass es an dieser Stelle gegenüber der vorherigen Version keine Änderung gegeben hat, was nicht nachvollziehbar ist.

Auch mit der ersten finalen Version ist der Benchmark nicht einfacher geworden, und es bleiben nach wie vor wichtige Fragen offen, wovon die meisten durch die Halbleiterhersteller zu beantworten wären. Laut Peter Torelli vom EEMBC plant momentan keiner der vertretenen Firmen eine Veröffentlichung ihrer IoTMark-BLE Benchmark Scores. Sie sollen demnach nur für interne Analysen eingesetzt werden, was der ursprünglichen Intention der EEMBC Benchmarks eigentlich zuwiderläuft, zumal Ergebnisse anderer Benchmarks wie ULPBench bzw. ULPMark-PP veröffentlicht werden und – bei gutem Ergebnis – dann gern in der Werbung herausgestellt werden. Die Mitarbeiter des Instituts haben jedenfalls erstmalig und herstellerunabhängig Testergebnisse mit IoTMark-BLE veröffentlicht und sind gespannt, wie es mit dem IoTMark-BLE-Benchmark des EEMBC weitergeht.

Der Autor dank Filip Hölter, Nikolai Koert und Jan Burmeister für Ihre Mitarbeit an diesem Elektronik-Projekt zum Benchmark IoTMark-BLE des EEMBC.

 

Literatur

[1] Dembowski, K.: EEMBC-Benchmarks in der Praxis. Elektronik 2018, H. 4, S. 32 – 41, www.elektroniknet.de/elektronik/halbleiter/eembc-benchmarks-in-der-praxis-150857.html.

[2] PSoC 4 Bluetooth Low Energy (BLE) 4.1 Compliant Pioneer Kit, Cypress, www.cypress.com/documentation/development-kitsboards/cy8ckit-042-ble-bluetooth-low-energy-ble-pioneer-kit.

[3] TC35678FSG Ultra-Low Current Single-Chip Controller for Bluetooth Low Energy (4.2) With Built-In Flash ROM, Toshiba, https://toshiba.semicon-storage.com/eu/product/wireless-communication/bluetooth/tc35678.html.

[4] RSL10-002GEVB: Radio SoC evaluation board, version 1 (QFN based), On Semiconductor, www.onsemi.com/PowerSolution/evalBoard.do?id=RSL10-002GEVB.

[5] Blue Gecko BGM113 Bluetooth Low Energy Module, Silicon Labs, www.silabs.com/products/wireless/bluetooth/bluetooth-low-energy-modules/bgm113-bluetooth-low-energy-module.

[6] IoTMark-BLE an EEMBC Benchmark, www.eembc.org/iotmark.

[7] Dembowski, K.: Bechmark für IoT-Mikrocontroller mit BLE – Teil 1: IoTMark-BLE in der Praxis. Elektronik 2019, H. 4, S. 56 – 59, www.elektronik.de/iotmark-ble.

 

Der Autor

ist Wissenschaftlicher Angestellter im Institut für Mikrosystemtechnik an der Technischen Universität Hamburg. Sein Zuständigkeitsbereich beinhaltet die Entwicklung von Hard- und Software für Mikrosysteme mit dem Schwerpunkt Anwendungen von Energy Harvesting.

Er wurde 2011 und 2017 von der Redaktion der Elektronik für seine Fachaufsätze »Sensornetze mit energiesparender Funktechnik« und »Funkelektroden zur Messung bioelektrischer Signale: EKG ohne Kabel« als»„Autor des Jahres« ausgezeichnet.

dembowski@tuhh.de