Startseite > Halbleiter > Mikrocontroller > EEMBC-Benchmarks in der Praxis

ioT-Mikrocontroller beurteilen

EEMBC-Benchmarks in der Praxis

21. Februar 2018, 11:24 Uhr | Von Klaus Dembowski

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Schrittweise zum Testprogramm

Der erste Schritt für die Erstellung einer angepassten Firmware ist die Beschaffung der für den einzusetzenden Mikrocontroller notwendigen Software (Entwicklungs-umgebung, Tools, Beispiele), was üblicherweise eine Registrierung beim jeweiligen Hersteller erfordert.

Die Installation und Konfiguration dieser Software kann bekanntermaßen bereits eine ganze Reihe von Problemen aufwerfen und insbesondere bei fehlender Erfahrung einen beschwerlichen Weg bis hin zum ersten funktionierenden Beispiel bedeuten.

Mit der Qualität der Software, den dazugehörigen Dokumentationen und dem Support, den der Hersteller dem Kunden zukommen lässt, hat sicherlich jeder Entwickler schon eigene Erfahrungen gesammelt, die von sehr gut bis hin zu ungenügend reichen, wie es sich auch bei den hier untersuchten Kandidaten für das Elektronik-Projekt zum Benchmark IoTMark-BLE zeigt (Tabelle 1).

Jobangebote+ passend zum Thema

Vertriebsinnendienst / Account Manager (m/w/d)

GLYN GmbH & Co. KG, Idstein

Trainee Vertrieb und Produktmanagement (m/w/d) für Bachelorabsolventen

GLYN GmbH & Co. KG, Idstein

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Soft- und Hardware für das Elektronik-Projekt zum IoTMark BLE

Jeder Halbleiterhersteller liefert für seine Mikrocontroller-Entwicklungskits ein eigenes SDK (Software Developer Kit) mit Treibern, API, Software, Dokumentation und mit mehr oder weniger brauchbaren Beispielen. Dabei ist es nicht immer einfach überhaupt die notwendigen Dateien auf den Internet-Seiten der Halbleiterhersteller zu finden. Die größte Sucherei gab es beim Atmel SAM11 Xplained Pro, was wohl (immer noch) der Umstrukturierung bzw. der Eingliederung von Atmel in Microchip nach deren Übernahme geschuldet ist.

Als Standard bei den Entwicklungsumgebungen haben sich Embedded Workbench von IAR und das Microcontroller Development Kit (MDK, mit µVision IDE) etabliert, die prinzipiell mit allen angeführten Systemen umgeben können.
Einige der Hersteller bieten eigene Entwicklungsprogramme an, z.B. Cypress Semiconductor den PSoC Creator, NXP die Umgebung MCUXpresso, was dann meist auf Eclipse basiert.

Bis auf die Entwicklungskits von Atmel/Microchip und Renesas (BLE 4.1) sind alle für das Elektronik-Projekt zur Verfügung gestellten Mikrocontroller BLE 4.2 spezifiziert. Ein komplettes Paket mit allem Drum und Dran hat eigentlich nur Cypress (CY8CKIT-042-BLE-A) geschnürt. Das andere Ende der Skala bildet das QN9080 Kit von NXP. Es soll laut Dokumentation wie das Kit von Cypress Semiconductor zwar einen separaten BLE-Host enthalten, der Lieferumfang besteht allerdings nur aus einer Platine, die in einer Antistatiktüte eingepackt ist.

Das Modul von STMicroelectronics verfügt als einziges auch über Sensoren, was für IoT-Applikationen prinzipiell vorteilhaft ist, für die Betrachtung der Energieeffizienz gemäß des EEMBC-Benchmarks aber nicht nötig, wahrscheinlich sogar kontraproduktiv ist, weil die Sensoren mit in die Messung der Energieaufnahme eingehen.

Gleiches gilt für eine Programmierschaltung auf dem Modul, die sich für die Strommessungen abschalten lassen sollte, was jedoch bei keinem der in der Tabelle 1 angegebenen Kandidaten möglich ist. Beim Entwicklungskit von Cypress ist die Programmierschaltung steckbar, so dass sie für die Messungen zur Stromaufnahme einfach abgenommen werden kann, was sich als sinnvoll gezeigt hat.

Ein separater Programmer (Debugger) ist für den RL78/G1D von Renesas notwendig, der nicht wie die anderen auf einem ARM-Cortex, sondern auf einer eigenen 16-bit-CPU basiert. Die umständliche und langwierige Installation der Software stellt eine echte Geduldsprobe dar, zumal die dazugehörige Dokumentation mit vielen Fehlern durchsetzt ist.

Für das Entwicklungskit von Toshiba mit dem BLE2 Baseboard und dem TC35678FSG, welches auf einem Modul von Panasonic (mit PAN 1760A) aufgebracht ist, wird ebenfalls ein separater Programmer benötigt. Das Entwicklungskit ist mittlerweile durch eine USB-Stick-Version mit einem integrierten Programmer ersetzt worden, die deshalb auch später für den IoTMark BLE zum Einsatz kommen wird.

Anpassen der Software für den EEMBC-Test

Die ULPMark-PP-Software besteht im Wesentlichen aus drei Teilen: Dem Benchmark (Benchmarks), einem Scheduler (TES) und den plattformspezifischen Funktionen (Platforms). Sowohl die Benchmark- als auch die Scheduler-Software bleiben stets unverändert.

Der zweite Schritt ist die Anpassung des von EEMBC gelieferten Codes, d.h., es sind einige Einstellungen und Konfigurationen sowie Controller-spezifische Routinen für PWM, ADC, RTC und SPI zu programmieren, die im Verzeichnis Platforms untergebracht werden. Das Verzeichnis Template, mit den dort vorhandenen Dateien, dient als Vorlage für das eigene Projekt, wird entsprechend kopiert, umbenannt und mit den eigenen Einträgen bzw. Daten versehen. Das heißt, dass bei dieser Portierung die noch leeren Funktionskörper mit den für die jeweilige Funktion notwendigen plattformspezifischen Instruktionen gefüllt werden. In Bild 3 ist zur Übersicht die Verzeichnisstruktur von ULPMark-PP mit den dazugehörigen Dateien angegeben.

Die zu kompilierende Software setzt sich aus den in Bild 3 angegebenen Komponenten zusammen und weist eine Größe von ca. 4 KByte auf, liegt damit also weit unter der kritischen Codegröße von 32 KByte, wie sie bei den kostenlosen Versionen der Entwicklungsumgebungen von ARM/Keil und IAR gilt. Die freie GNU Compiler Collection (GCC) kennt derartige Restriktionen nicht und lässt sich ebenfalls für die Compilierung und den Link-Vorgang einsetzen.

Portierungsvorgang:

1. Neues Projekt erstellen.
2. Benchmark importieren.
3. Include-Pfade für den Compiler hinzufügen.
4. Portierung ausführen:
a. board.h: Definitionen für die Taktfrequenz und den ADU.
b. hardware_setup.c: Takt-Einstellungen, Definition der Pin- Belegung und Deaktivierung ungenutzter Peripherie.
c. Platform.c: Schlaf-Funktion für Low-Power-Modus.
d. Platform_ADC.c
e. Platform_PWM.c
f. Platform_RTC.c
g. Platform_SPI.c
5. Build and Start (Kompilieren, Linken, Starten).
6. Controller-Reset.
7. Benchmark wird ausgeführt.

Einige Hersteller, z.B. STMicroelectronics unterstützen ULPMark-PP nicht nur durch Dokumentationen, sondern liefern auch die angepasste Software (Platforms), was einen erfolgreichen Build-Vorgang des Compilers maßgeblich erleichtert. Als Compiler wird üb-licherweise der vom Halbleiterhersteller mitgelieferte bzw. der jeweils empfohlene eingesetzt.

Die selbst erstellen Routinen werden vom Scheduler der ULPMark-PP-Software aufgerufen und haben einen direkten Einfluss auf das Benchmark-Ergebnis. Das heißt, eine möglicherweise unpassende oder nicht optimale Programmierung an diesen Stellen kann zu einem vergleichsweise schlechten Ergebnis des getesteten Mikrocontrollers führen.

Deshalb ist eine genaue Kenntnis des Mikrocontrollers und seiner Programmierung nötig. Ohne Unterstützung durch Experten der Halbleiterhersteller, die sich mit dem Mikrocontrollermodul und der Programmierung – idealerweise auch mit der EEMBC-Software – auskennen, werden die Benchmark-Ergebnisse sehr leicht durch fehlendes Know-how verfälscht.

Im praktischen Umgang mit den Benchmark-Routinen hat sich gezeigt, dass möglicherweise spezielle, nicht dokumentierte Programmiertricks oder auch kleine Änderungen an der Hardware notwendig sind, damit der Test optimal absolviert werden kann.

Ablauf der Firmware für ULPMark-PP:

1. Hardware Boot.
2. Initialisierung und Setup.
3. Start des Schedulers.
4. Ablauf von neun Schleifen zum Aufwärmen (Warm Up Loop) ohne Funktion.
5. Ersten Slot starten.
6. In Schlafmodus schalten.
7. In einer Sekunde aufwachen.
8. Zurück zu Schritt 5, bis alle 10 Slots durchlaufen wurden.

Für den Benchmark ist das zu testende Mikrocontrollermodul (DUT – Device Under Test) an UB und Masse vom Energy-Monitor-Board anzuschließen, wie es in Bild 4 gezeigt ist.

Des Weiteren ist für den SPI-Test eine SPI-Schleife – MISO- an MOSI-Pin – herzustellen und eine Referenzspannung (U_B/2 ±10 %) für den A/D-Umsetzer des DUT von einer (Referenz-) Spannungsquelle anzulegen. Alternativ kann die Referenzspannung über einen Spannungsteiler vom U_B-Anschluss des Energiemonitors abgenommen werden. Alles, was an U_B angeschlossen ist, wird nicht mit in die Strommessung einbezogen.

Der aktuelle Status des Tests (Slot-Start) wird von einem Zeitstempel-Ausgang an den Energiemonitor geführt. Hierfür kann im Prinzip jeder E/A-Anschluss des zu testenden Mikrocontrollermoduls (DUT) verwendet werden, der als Open-Drain ausgelegt ist. Welcher Pin dies genau sein soll und auch welcher Pin dem Eingang für den ADU entspricht, wird in den entsprechenden (eigenen) Routinen für den Benchmark festgelegt (Bild 5).