Den Schritt zu 32-Bit wagen

von

Simon Duggleby, Semiconductor Category Marketing Manager, RS Components

 

Der Übergang zu einer High-End-MCU wird einfacher, wenn die Roadmap und die Leistungskurve eines bewährten Herstellers befolgt werden.

Jahrelang setzten zahlreiche Hersteller auf 8-Bit-Mikrocontroller (sogenannte MCUs) und trieben dabei stets die Preis- und Funktionsfrage voran, da Hersteller integrierter Geräte (Integrade Device Manufacturers, IDMs) stets bestrebt waren, mehr für weniger anzubieten. Da die Komplexität von Endanwendungen jedoch fortlaufend zunimmt, haben viele IDMs ihren Fokus inzwischen von der vergleichsweise simplen 8-Bit-Architektur auf leistungsstärkere und komplexere 32-Bit-MCUs verlagert, um somit der Nachfrage nach immer mehr Funktionalität Rechnung zu tragen.

Der Übergang zu einer 32-Bit-Architektur bietet zahlreiche Vorteile, nicht zuletzt aufgrund des deutlich größeren Adressbereichs. Dies führt zu einem größeren adressierbaren Speicher (und eröffnet somit die Möglichkeit für komplexere Algorithmen und Steuersoftware) sowie zu breiten Datenpfaden (für bessere Ansprechzeiten) und umfangreicheren Peripherie-Aufbauten. Mit dieser Kombination aus Flexibilität und Leistungsfähigkeit werden 32-Bit-Geräte besonders attraktiv für zahlreiche OEMs – doch was sind die Risiken und Gefahren der Abwanderung von 8-Bit?

Zunächst besteht eine mögliche Gefahr in dem Verlust der technischen Wissensgrundlage, die ein Hersteller über einen langen Zeitraum hinweg für einen bestimmten Anweisungssatz oder eine bestimmte Architektur aufgebaut haben mag. Dabei lässt sich nur schwer bestreiten, dass ein 8-Bit-Gerät im Assemblercode nicht gerade einfacher ist als dieselbe Aufgabe mit einer höherwertigen Sprache wie C oder C++ zu bewältigen, doch viele IDMs betreiben einen enormen Aufwand, um diesen Übergang so schmerzfrei wie nur möglich zu gestalten. Während es unter Umständen nicht möglich sein wird, die Software-Kompatibilität beizubehalten, verfügen viele IDMs dennoch über hochentwickelte integrierte Entwicklungsumgebungen (Integrated Development Environments, IDEs) und Software-Sammlungen, die deutlich umfassender sind als der übliche Software-Support für 8-Bit-Geräte.

Eine weitere Software-bezogene Herausforderung besteht darin, dass ein 32-Bit-Gerät einen Scheduler, Kernel oder ein Echtzeit-Betriebssystem (Real-Time Operating System, RTOS) benötigt. Fakt ist, dass einer der bedeutendsten Produktionsschübe eines 32-Bit-MCUs auf der Möglichkeit basiert, eine Standardsoftware zur Vereinfachung der Anwendungsentwicklung zu integrieren: Dies umfasst in der Regel ein bestimmtes Betriebssystem, während die Komplexität (und die Lernkurve) mit den Anforderungen der Anwendung variiert, letztendlich aber die Mühe wert sein wird.

 

Kernfunktionen

Jeder Entwickler, der in irgendeiner Form mit integrierten Designs in Kontakt gerät, wird das Standing von ARM mit seinen Cortex-M Cores sehr zu schätzen wissen. Diese Cores wurden von zahlreichen Halbleiterherstellern angenommen und werden folglich von einer soliden Plattform getragen. Gleiches gilt nahezu für die 8051-Architektur; und so wäre es leichtes Spiel anzunehmen, dass der Cortex-M die ideale Lösung für den Übergang zu 32-Bit-MCUs wäre. Manche Hersteller bieten jedoch noch Alternativen; dieser Punkt kann ausgesprochen wichtig werden, wenn es darum geht, die Leistungskurve weiter nach oben zu klettern. Atmels AVR-Portfolio umfasst alles von 8-Bit bis 32-Bit, während Microchip für die Entwicklung seiner 32-Bit-Familie auf den MIPS Core setzt. Die Gründe für diese Wahl sind ein wichtiger Teil ihrer Migrationsstrategie und spielen ebenso eine wichtige Rolle um herauszufinden, wie mühelos sie Entwickler bei diesem Übergang unterstützen können.

 

Softwarelösungen

Der Übergang von Assembly zu C mag beängstigend erscheinen, doch viele IDMS – darunter auch Atmel – wissen das zu schätzen. In Tabelle 1 erhalten Sie einen vereinfachten Überblick über die Vorteile beider Sprachen. Dabei arbeitete Atmel zusammen mit IAR, um Ratschläge und Ideen zur Konfiguration von IARs C Compiler für Atmels 8-Bit AVR MCU in Projekten mit C und Assemblercode zu erhalten. Dieser Punkt eignet sich hervorragend, um zu Atmels 32-Bit AVR UC3-Reihe überzugehen, deren Programmierung hauptsächlich in AVR32Studio mit Support für C/C++ und Assembly erfolgte.

Tabelle 1

Tool-Support gewinnt zunehmend an Bedeutung, da die Komplexität des MCU und der Anwendungssoftware stets zunimmt. Dabei kann der Support des Übergangs von 8- auf 32-Bit weiter vereinfacht werden, wenn die Werkzeugpalette weiterhin vertraut ist und, sofern möglich, durchweg einheitlich bleibt. Genau diesen Ansatz verfolgte Microchip vor Kurzem für die Einführung der neuesten allumfassenden IDE, MPLAB X. Im Gegensatz zu manch anderen IDEs kann MPLAB X als Entwicklungssoftware für jede beliebige Microchip MCU verwendet werden — einschließlich der 8-Bit PIC MCUs, der dsPIC digitalen Signalcontroller und der MIPS-basierten 32-Bit PIC32 Hochleistungsreihe. Microchip wählte NetBeans IDE von Oracle als Plattform für MPLAB X, sodass eine ganze Reihe an professionellen Funktionen enthalten ist, die nicht immer von einem integrierten IDE Design abgedeckt wird.

 

Hardware und Abhängigkeiten

Abgesehen von Software liegen die wirklichen Vorteile des Übergangs zu einer 32-Bit-Architektur jedoch vor allen Dingen in der Performance und der erweiterten Funktionalität. All den umfassenden und dauerhaften Bestrebungen von IDMs zum Trotz, MCUs mit einem 8-Bit-Kern zu übernehmen, sind diese in ihrer Leistungsfähigkeit doch sehr beschränkt, sodass der Übergang zu einer 32-Bit-Alternativ nahezu unausweichlich wird. Diesen Übergang so reibungslos wie möglich zu gestalten ist daher von größter Bedeutung.

Eine langfristige Strategie kann sich in dieser Hinsicht als sehr wertvoll erweisen. STMicroelectronics, beispielsweise, ist dieses Problem mit dem Übergang zwischen der 8-Bit STM8 Reihe (auf einer firmeneigenen Architektur) und STM32 (basierend auf dem ARM Cortex-M3 Kern) angegangen und hat die Peripherie-IP so entwickelt, dass sie in beiden Bereichen verwendet werden kann. Dies wird dadurch erreicht, dass die Peripherie-Geräte mit Hilfe einer Brücke an den Kern der STM32-Reihe angeschlossen werden, sodass beide Reihen dieselbe Peripherie-IP verwenden und die interne Bus-Spezifikation ändern. Somit besteht der einzige Unterschied in der größtmöglichen Taktfrequenz. Sie teilen sogar ein ähnliches Taktsystem und zahlreiche Speicherkonfigurationen.

 

 

Abbildung 1 zeigt eine Gegenüberstellung der Reihen STM8 und STM32

Bei dem Software-Standpunkt hebt ST hervor, dass die Leistungsfähigkeit für Peripherie-Geräte das „Plattform-Design“ fördert, welches das Umschalten zwischen den beiden Produktreihen vereinfacht. Hinzu kommt, dass umfassende Software-Verzeichnisse mit einer Hardware Abstraction Layer für MCU Ressourcen übereinstimmen; dabei gibt es nicht eine einzige Steuerung bzw. einen einzigen Status, die bzw. der nicht von einer C-Funktion oder einer API abgedeckt ist.

 

Risiken minimieren

Der Übergang von einem 8-Bit-Gerät zu einer 32-Bit-Alternative wird nicht im Handumdrehen erfolgen, doch unter Voraussetzung, dass sie innerhalb einer einzelnen Reihe von dem jeweils selben Hersteller bleiben, können Entwickler sicher sein, dass ihr bevorzugter Zulieferer alles nur erdenkliche unternommen hat um diesen Übergang so reibungslos wie nur möglich zu gestalten — von der Entwicklung einer portablen IP bis hin zur Investition in erweiterte Werkzeugketten. Zu guter Letzt sind MCUs stets auf relativ bestimmte Anforderungen ausgelegt, und während nicht jeder Hersteller bereit bzw. in der Lage ist, ein komplettes Portfolio von Low-End bis zur High-Performance anzubieten, ist es dennoch wichtig, den Punkt im Auge zu behalten, dass MCUs ausgesprochen flexibel sind und somit stets ein Konfigurationselement benötigen. Mit 32-Bit-Lösungen wie beispielsweise STs STM32, Atmels AVR32 und Microchips PIC32 liegen die jeweiligen Hinterlassenschaften klar und deutlich offen: Dabei bieten sie weniger eine One-Way-Lösung sondern vielmehr eine gleichmäßige Leistungskurve und unterstützten Geräte für jede beliebige Anwendung und Konfiguration.