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

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. Nach den Vorbereitungen im ersten Teils [7] folgt jetzt die Umsetzung in der Praxis.

Als Erstes sollte generell das UART-Interface programmiert werden, damit es während der weiteren Programmierung für Debug-Ausgaben verwendet werden kann. Das Interface ist insbesondere bei der Erstellung der BLE-Routinen äußerst hilfreich, um beispielsweise die Rückgabewerte von Funktionen und Ereignissen ausgeben zu können. Weil das UART-Interface ansonsten nur zur späteren Steuerung des DUT durch den IoT-Mark-BLE-Benchmark zum Einsatz kommt, hat der UART-Einsatz keine Auswirkungen auf das Testergebnis.

Der zu implementierende Event Handler (s. Teil 1 Schritt 12) bildet eine Rückruffunktion, die bei Ereignissen (Events) im BLE Stack mit zwei Parametern aufgerufen wird und auf die Events reagiert. Diese Parameter enthalten Informationen über den Typ des Events und gegebenenfalls die dazugehörigen Daten.

In der main-Funktion wird eine Funktion periodisch aufgerufen, die den BLE Stack auf neue Events hin abfragt und diese dann abarbeitet. Die Periodendauer der Abfrage sollte dabei kleiner sein als das Verbindungsintervall des DUT. Für das GATT-Profil ist ein benutzerdefinierter Service zu erstellen, der zwei Charakteristiken für den Datentransfer (TX, RX) enthält. Dies umzusetzen war beim PSoC4 BLE von Cypress dank des PSoC Creator relativ einfach durchzuführen, wogegen sich für die anderen drei Kandidaten spätestens an dieser Stelle entschied, ob und wie es weitergeht.

Durch eine API sollte der notwendige Software-Aufwand für die Nutzung von Peripherieblöcken möglichst gering sein. Bei Cypress, Silicon Labs und Toshiba ist dies der Fall. So genügt hier beispielsweise für die I2C-Bus-Initialisierung eine Zeile, wie IOM_I2C_Start() bei Cypress, oder SYS_API_SetI2cEnable(0x01, 0x81) bei Toshiba, weil die dahinterstehenden APIs alles Weitere erledigen.

Beim RSL10 von ON Semiconductor dagegen müssen erst alle Interrupts maskiert und disabled sowie die DIO-Pins konfiguriert werden, bevor I2C als Master festgelegt und mit den jeweiligen Leitungen (SCL, SDA) eingestellt werden kann. Danach sind abschließend die Interrupts wieder zu aktivieren und die Maskierung ist wieder aufzuheben, was dann allein zu einem Codeabschnitt von über 20 Zeilen führt. Für andere DIO-Pins, etwa damit sie als UART fungieren, ist beim RSL10 im Prinzip die gleiche Prozedur notwendig, was vergleichsweise aufwendig und fehleranfällig ist.

Wie erwartet, ist die Codeerstellung für BLE die größte Herausforderung. Auch hier macht es On Semiconductor dem Programmierer nicht leicht, denn für die BLE-Funktion muss in den Compiler-Einstellungen der IDE eine Reihe von Makros definiert sein, die als Konfiguration notwendig sind. Ohne diese Makros, die nirgendwo dokumentiert sind, sondern nur stillschweigend ohne jegliche Erwähnung im offiziellen Beispielcode (peripheral_server) auftauchen, bleibt BLE hier komplett außen vor. Im Bild 8 sind die hierfür notwendigen Festlegungen gezeigt.

Außerdem sind noch verschiedene Bibliotheken erforderlich, die zudem in der richtigen Reihenfolge importiert werden müssen, andernfalls lässt sich das Projekt zwar kompilieren, der Build-Vorgang scheitert jedoch beim Linken, weil die Funktionen in den Headern zwar angegeben, jedoch nicht in der erforderlichen Art und Weise eingebunden werden können.

Obwohl sich diese Probleme noch beheben ließen, mussten wir die Funktionsprogrammierung beim Versuch, das erforderliche GATT-Profil zu erstellen, nach einiger Zeit abrechen, denn von On Semiconductor ist diesbezüglich keinerlei Support oder Hilfe zu erwarten. Mehrere konkrete Anfragen verliefen dort im Sande mit der abschließenden Aussage des zuständigen Field Application Engineers von On Semiconductor in der Schweiz, dass seiner Meinung nach für den Benchmark keine BLE Services notwendig seien. Mit anderen Worten: On Semiconductor hat offensichtlich noch nicht mitbekommen, dass beim IoTMark-BLE die BLE-Funktion als wichtigstes Kriterium auf dem Prüfstand steht, was besonders erstaunlich ist, weil On Semiconductor Mitglied im EEMBC-Konsortium ist.

Der Benchmark konnte vom RSL10 nur bis zum neunten Schritt absolviert werden, bei dem ein Time-Out (Bild 9) ausgewiesen wird. In diesem Schritt (emon start-trace) hat das DUT demnach innerhalb 10 s nicht geantwortet, was als ein grundlegendes Problem anzusehen ist, denn hiermit konnte noch nicht einmal die Initialisierung des Systems (Bild 1) komplett absolviert werden, weil das UART-Interface nicht antworten wollte. Der Grund dafür ist, dass das Modul einem Strom von über 20 mA zieht, was für den Powermanager zu viel ist, sodass die Versorgungsspannung daraufhin zusammenbricht, der RSL10 einen Reset ausführt und der ganze Vorgang dann wieder von vorn beginnt.

Ein Betrieb des RSL10 ist in der EEMBC-Testumgebung für den IoTMark-BLE demnach nicht möglich. Dann hätte man sich natürlich auch gleich die Software-Erstellung für Bluetooth sparen können (s. o.). Mit so einem Fauxpas haben wir jedoch nicht gerechnet.

Die Software und die Dokumentation für den Toshiba TC35678FSG war zum Zeitpunkt der Benchmark-Programmierung zwar noch nicht ganz fertig, was aber durch die schnelle und sehr kompetente Unterstützung von Toshiba Electronics in Düsseldorf mehr als wett gemacht wurde.

Aufgrund der bereits vorhandenen Erfahrungen mit den Mikrocontrollern der Gecko-Serie von Silicon Labs konnten die Routinen für das Modul BGM113 ohne größere Probleme programmiert werden, wofür die gute Dokumentation und die gelieferten Beispiele – insbesondere das Projekt soc-empty – im Simplicity Studio mit verantwortlich sind.