Es wird immer mehr Speicher benötigt und Speicher ist teuer, auch wenn er in preisgünstigen Mikrocontrollern integriert ist. Aus diesem Grund ist die erzeugte Code-Größe ein wichtiger Faktor bei der Auswahl von Mikrocontrollern. Der Thumb2-Befehlssatz ist nicht nur auf Performance, sondern auch auf Erzeugung kleinen Codes optimiert. Wie bei Performance-Benchmarks hängt der Grad der Optimierung immer von der Applikation ab, deshalb auch hier nur der Verweis auf die Aussage von ARM, die eine Reduktion um ca. 20 % gegenüber ARM7-Code berichtet (Bild 2). In Verbindung mit den inzwischen erhältlichen internen Flash-Größen bis zu 512 Kbyte bei den neueren STM32-Derivaten bedeutet dies einen geschenkten Zugewinn von ca. 100 Kbyte Speicher – darin kann man einiges an zusätzlicher Software unterbringen. Auch bei der Nutzung des Arbeitsspeichers wurden Optimierungen eingebaut, die helfen, Speicher zu sparen. Beim ARM7 sind Byte-, Half-word- (16 bit) und Word-Zugriffe (32 bit) möglich, sowohl „signed“ als auch „unsigned“. Dies erlaubt einen schnellen Zugriff auf Integers, ohne Bibliotheken nutzen zu müssen, wie es bei 8- oder 16-bit-Controllern nötig ist. Allerdings war bei den ARM7-CPUs ein Zugriff auf ein Word oder Halfword nur „aligned“ möglich, d.h., ein Word musste auf einer Adresse, die durch 4 teilbar ist, und ein Half-word auf einer Adresse, die durch 2 teilbar ist, abgelegt werden. Insbesondere bei Strukturen kann dies zu Lücken führen, die nicht genutzt werden.
Je nach Mischung der Datentypen kann dies zu 25 % ungenutztem Speicherplatz führen. Der Cortex-M3 kann jetzt „misaligned“ Zugriffe durchführen. Auch bei ungünstig angeordneten Strukturen werden keine Lücken im Speicher benötigt – der Speicher wird vollständig genutzt. Auch die Bit-Banding- Methode hilft Speicher zu sparen, da die tatsächlichen Bits effektiv adressiert werden. Demgegenüber bedeutet die Programmierweise, Flags vom Typ boolean zu definieren, grundsätzlich mindestens ein ganzes Byte pro Flag, was an dieser Stelle einer Speichernutzung von nur 13 % entspricht, wenn tatsächlich für jedes Bit ein Flag gesetzt wird.
Demonstration der Performance und Code-Größe mit dem STM32-PerformanceStick
Der STM32-PerformanceStick ist nicht nur eine preisgünstige komplette Entwicklungsumgebung für den STM32, sondern zeigt auch die Fähigkeiten des Cortex-M3 gegenüber einem ARM7. Mit der mitgelieferten Dashboard- Software kann die Performance der beiden Kerne direkt verglichen werden. Zur Auswahl stehen drei Applikationen, ein Dhrystone-Benchmark-Beispiel, ein Beispiel, das die zusätzlichen Cortex-M3-DSP-Befehle nutzt, und ein Bit-Manipulationsbeispiel (Sieb des Eratosthenes), das die Cortex- M3-Bit-Banding-Bereiche nutzt. Das gleiche Beispiel läuft einmal auf dem ARM7 (ARM-Modus) und einmal auf dem Cortex-M3 (Thumb2- Modus).
Beide CPUs werden mit der gleichen CPU-Frequenz getaktet. Diese Beispiele werden wiederholt durchgeführt und die Zeit jedes Durchlaufes gemessen und in der Dashboard-Software angezeigt. In allen drei Beispielen ist die Ausführungszeit des Cortex-M3 deutlich kürzer (Bild 3). In den Fällen, in denen der Cortex nicht nur die höhere MIPS-Zahl hat, sondern auch noch die besseren Befehle (Bit-Manipulation und Digitalfilter), ist die Differenz, wie zu erwarten, größer. Bei beiden Controllern kann auch die Interrupt-Last erhöht werden. Ein Timer unterbricht die Ausführung der Applikation, wobei die Abstände der Interrupts durch den Schieberegler in der Dashboard-Software verändert werden können.
Gerechterweise wurde darauf geachtet, dass die Häufigkeit der Timer-Interrupts und der Nutz- Code, der in der ISR ausgeführt wird (also ohne den Software-Overhead, der für eine ISR nötig ist), bei beiden Controllern gleich sind. Unterschiedlich sind natürlich die Interrupt-Latenz und der Overhead, die durch mehrfache Interrupts auftreten. Dies ist beim ARM7 deutlich stärker zu sehen als beim Cortex-M3, was zeigt, dass die o.g. theoretischen Ausführungen auch hier einfach praktisch und deutlich erkennbar sind.