Peripheriegeräte sind für die Migration von Systemen unerlässlich.
Viele Designs beginnen mit der Spezifizierung der Systemfunktionen und der Zugriffsmethoden der Benutzer.
Dies bestimmt die notwendige Schaltung und die Peripheriegeräte, die in den Mikrocontroller integriert werden müssen, um diese zu steuern. Möchte der Entwickler beispielsweise eine industrielle Mensch-Maschine-Schnittstelle (HMI) integrieren, muss der Mikrocontroller ein LCD-Display und Tasten oder einen Touchscreen, eine Schnittstelle zur Maschinenkommunikation, LEDs sowie einen akustischen Alarm oder eine andere Audiokomponente unterstützen. Daher benötigt der Mikrocontroller einen CAN-Controller für die Kommunikation, einen A/D-Wandler für den Touchscreen und einen PWM-Timer für den akustischen Alarm. Je größer der Funktionsumfang der Peripheriegeräte, desto weniger externe Schaltungen werden benötigt, was den Programmieraufwand reduziert. Bei einem akustischen Alarm lässt sich beispielsweise der gleiche Effekt durch die Anpassung eines PWM-Signals erzielen.
Typischerweise interessieren sich Entwickler für zwei grundlegende Informationen über den Kernel: Ist er schnell genug, um alle für die Funktionen des Endprodukts notwendigen Softwareaufgaben auszuführen? Und führt er diese Aufgaben effizient aus? Lautet die Antwort auf beide Fragen „Ja“, brauchen sich die meisten Entwickler keine großen Gedanken über den verwendeten Kerneltyp zu machen.
Entscheidender ist jedoch, wie viel vorhandene Software und Firmware von einem Kernel auf einen anderen migriert werden kann, um Peripheriegeräte zu unterstützen. Da der Großteil des 32-Bit-Mikrocontroller-Codes in C geschrieben ist, lässt er sich größtenteils für jeden Kernel neu kompilieren. Allerdings verwendet jeder Mikrocontroller-Hersteller – unabhängig vom Kernel – exklusive Peripheriefunktionen und Programmiermodelle für seine eigenen Produkte. Genau das macht die Codeportabilität zu einer Herausforderung.
Firmware-Portabilität:
Jeder Mikrocontroller-Hersteller stellt eine Firmware-Bibliothek bereit, die den Code zur Konfiguration und zum Betrieb der in seinen Mikrocontroller integrierten Peripheriegeräte enthält. Allerdings implementiert jeder Hersteller diese Peripheriegeräte unterschiedlich, und jedes Peripheriegerät kann unterschiedliche Funktionen haben. Daher ist die Portierung einer Anwendung von einem Mikrocontroller auf einen anderen keine einfache Aufgabe.
ARM hat dieses Problem durch die Definition einer standardisierten Firmware-Abstraktionsschicht namens Cortex™ Microcontroller Software Interface Standard (CMSIS) gelöst. Dieser Standard wird von allen Mikrocontroller-Herstellern mit Cortex-M-Kernen verwendet und kommt in deren Firmware-Bibliotheken zum Einsatz. Allerdings berücksichtigt er weder die Herausforderungen der Peripheriegeräte-Portabilität noch legt er eine einheitliche Namenskonvention für Variablen oder Funktionen fest. Daher trägt er kaum dazu bei, den Aufwand für die Portierung einer Anwendung zwischen verschiedenen ARM-Mikrocontroller-Herstellern zu reduzieren.
Portabilitätsprojekte:
Obwohl Mikrocontroller-Hersteller denselben ARM-Kern verwenden, haben sie keinen Anreiz, die Portabilität auf Mikrocontroller anderer Hersteller zu vereinfachen. Die Herausforderung, ein Design portabel zu gestalten, liegt daher beim Entwicklungsingenieur. Um die Portabilität zu vereinfachen, könnte der Entwickler eine Abstraktionsschicht implementieren, die eine standardisierte Programmierschnittstelle zwischen Mikrocontroller, Peripheriegeräten und Anwendungscode schafft. Dafür gibt es mindestens zwei Möglichkeiten:
- Für die Übersetzung zwischen der Peripheriebibliothek des Mikrocontroller-Herstellers und dem Anwendungscode kann eine Kompensations- oder Abdeckungsschicht entwickelt werden. Dies ist zwar wahrscheinlich die zeiteffizienteste Lösung, führt aber zu zusätzlichem Code in den Befehls- und Datenpfaden.
- Alternativ kann eine Standardmethode zur Benennung von Funktionen und Variablen definiert und auf jede Peripheriebibliothek angewendet werden. Dies vermeidet zwar zusätzlichen Code, kann aber insbesondere bei komplexen Peripheriegeräten zeitaufwändig sein.
Portabilität muss von Anfang an in den Entwicklungsprozess integriert werden. Neben Firmware/Software ist die Pin-Kompatibilität ein wichtiger Faktor, der beim Wechsel des Mikrocontroller-Herstellers in der Regel ein Neubestücken der Leiterplatte erfordert. Auch externe Bauteile wie Kondensatoren und Spannungsregler müssen gegebenenfalls ausgetauscht werden.
Praxistauglichkeit:
Die einfache Portierbarkeit zwischen 32-Bit-Mikrocontrollern verschiedener Hersteller bleibt ein Wunschtraum der Branche, solange die Probleme mit der Portabilität von Peripheriegeräten und Firmware-Bibliotheken nicht gelöst sind. Bis dahin müssen Entwickler die Portabilität ihrer Designs selbst gewährleisten. Eine Möglichkeit, dem entgegenzuwirken, ist die Wahl eines Mikrocontrollers, der die Migration zu anderen Mikrocontrollern innerhalb der Produktlinie desselben Herstellers erleichtert.
Microchip hat beispielsweise kürzlich sein Portfolio an C-Compilern mit dem MPLAB® XC-Paket vereinfacht. Dieses bietet einen Compiler für jede seiner 8-, 16- und 32-Bit-Architekturen und unterstützt alle PIC®-Mikrocontroller und dsPIC®-Digital-Signal-Controller (DSC). Dank der architekturübergreifenden Kompatibilität zur Reduzierung des Entwicklungsaufwands und der Pin-Kompatibilität verschiedener Gehäuse zur Vereinfachung des Leiterplattenlayouts für den direkten Austausch ist es ideal für diesen Zweck geeignet.
Während die Entwickler also noch auf die Fertigstellung eines Standardkerns mit standardisierten Peripheriegeräten und Firmware warten, können sie zumindest zukunftssichere Designs erstellen, indem sie zu Beginn jedes Projekts das Kosten-Nutzen-Verhältnis einer Migration auf den Katalog eines einzigen Herstellers bewerten.
