Ohne Kompromisse

Echtzeitregelung- und Kommunikationsfunktionen mit einem Dual-Subsystem-Mikrocontroller

10. Juli 2012, 14:34 Uhr | Von Sangmin Chon

Anwendungen mit Regelungs- und Kommunikations-Funktionen in einem setzten immer Kompromisse voraus: Die Echtzeitregelung verlangt nach einer MCU, deren interne Architektur ein deterministisches Ansprechverhalten sicherstellt; die Kommunikationsabläufe lassen sich auf entscheidungsbasierten Architekturen besser implementieren. Mit dem Dual-Subsystem-Mikrocontroller C2000 können beide Funktionen optimal implementiert werden.

Entwickler von Applikationen, in denen sowohl Regelungs- als auch Kommunikations-Funktionen benötigt werden, waren bei ihren Designs bisher zu Kompromissen gezwungen. Die Echtzeitregelung verlangt nach einem Mikrocontroller mit komplexen mathematischen Fähigkeiten, einer auf die präzise Verarbeitung von Regelschleifen ausgerichteten Pipeline und einer internen Architektur, die ein deterministisches Ansprechverhalten der Regelungsfunktionen und der Peripherie sicherstellt. Effiziente Kommunikationsabläufe dagegen lassen sich besser mit der entscheidungsbasierten Architektur implementieren, die man bei universeller ausgerichteten Prozessoren vorfindet.

Um ihre Designs möglichst kosteneffektiv zu machen, versuchen die Entwickler häufig, die Regelungs- und Kommunikationsfunktionen in einem einzigen Baustein zu implementieren. Je nach dem gewählten Prozessor lässt sich hierbei jedoch immer nur ein Teil des Systems optimieren. Fällt die Wahl auf einen für Echtzeitregelungen konzipierten Mikrocontroller, lassen sich diese Funktionen mit einem Optimum an Leistung und Effizienz umsetzen. Der Kommunikationsverbindung wird es dagegen an Bandbreite oder Reaktionsgeschwindigkeit mangeln, da sie gegenüber den Regelungsfunktionen nachrangig behandelt wird.

Verdeutlichen lässt sich dies am Beispiel einer programmierbaren Verknüpfungssteuerung. Sie dient als zentrale intelligente Instanz in einer industriellen Automatisierungslösung, die über eine Ethernet-Verbindung mehrere Motoren regelt. Die Latenz dieser Kommunikationsschnittstelle hat hier deshalb entscheidende Bedeutung für die Genauigkeit der Ansteuerung. Sollte der Mikrocontroller zusätzlich nicht die nötige Verarbeitungsleistung mitbringen, um die gewählte Kommunikationslösung auch unter Worst-Case-Bedingungen im notwendigen Maß zu unterstützen, bleibt den Entwicklern unter Umständen nichts anderes übrig, als auf eine andere, weniger ideale Schnittstelle umzusatteln.

Geht man den anderen Weg und verwendet einen Kommunikations-Mikrocontroller als zentrales Element des Systems, wird die Kommunikationsverbindung ein hohes Maß an Zuverlässigkeit und Durchsatz bieten. Dies wird allerdings zu Lasten der Zuverlässigkeit, Genauigkeit und Effizienz der Regelungsfunktionen gehen, da ein Applikationsprozessor nicht mit der robusten Interrupt-Infrastruktur eines für Echtzeitregelungen vorgesehenen Mikrocontrollers aufwarten kann. Auch weitere integrierte Funktionen wie die Leistungsfaktor-Korrektur wird man hier vergeblich suchen.

Abgesehen von den gerade umrissenen Aspekten macht das Implementieren von Echtzeitregelungs- und Kommunikations-Funktionen auf ein und demselben Baustein die Software sehr komplex - gleich ob ein Mikrocontroller oder ein Applikationsprozessor verwendet wird. Kommunikations-, Diagnose- und Routinefunktionen müssen sich die verfügbaren Prozessorzyklen mit der Regelschleife teilen, und so wird es extrem schwierig, die Echtzeiteigenschaften sowohl der Regelungs- als auch der Kommunikationsfunktionen zu garantieren. Hinzu kommt, dass die Entwickler den Zugriff auf gemeinsam genutzte Ressourcen wie den Speicher und die Peripherie koordinieren müssen und die verwendeten Mechanismen zur Behebung bzw. Vermeidung von Konflikten die Komplexität und die Latenz des Systems erhöhen.

Probleme mit der Leistung und den Echtzeiteigenschaften ließen sich auch beheben, wenn sich die Entwickler für einen leistungsfähigeren Baustein entschieden, was allerdings unweigerlich die Systemkosten in die Höhe treibt. Viele der aufgezeigten Kompromisse könnten außerdem vermieden werden, wenn separate Prozessoren für die Regelungsfunktionen und die Kommunikations- und Routinefunktionen verwendet würden. In der Tat ließen sich die Leistungs- und Zuverlässigkeitsvorgaben hiermit einhalten, doch der erhöhte Bauteileaufwand und die größere Leiterplattenfläche hätten Auswirkungen auf die Systemkosten. Die Komplexität der Hardware würde zunehmen und auch die Kommunikations-Latenz zwischen den Prozessoren würde größer werden. Ideal für die Entwickler wäre stattdessen eine Architektur, die zu keinem der soeben skizzierten Kompromisse zwingt.

Zwei in einem

Die Concerto-Mikrocontroller von TI basieren auf einer Architektur, die aus einem TI-C28x-Kern und einem ARM Cortex-M3 besteht und in zwei Subsysteme unterteilt ist (Bild). Für die ARM-Cortex-M3-Architektur, die in der Industrie für die Host-Kommunikation eingesetzt wird, gibt es einen großen Bestand an Werkzeugen und Software; außerdem hat sich diese Architektur als Plattform für die Entwicklung von MMIs (Mensch-Maschine-Schnittstellen) und GUIs (grafischen Benutzeroberflächen) etabliert.

Der C28x-Kern wird als Plattform für Regelungsanwendungen jeglicher Art verwendet. Die Architektur wurde für die effiziente und zuverlässige Verarbeitung komplexer Regelungsalgorithmen optimiert und enthält zu diesem Zweck einen integrierten Gleitkomma-Prozessor und eine rationalisierte Speicherarchitektur. Außerdem integriert sie Regelungs-Peripherie.

Dass die Funktionen hierbei klar zwischen den Kernen aufgeteilt ist, vereinfacht das Design und erhöht die Systemzuverlässigkeit, indem Konflikte, die beim Zugriff von Echtzeitregelungs-Tasks und Kommunikations-Treibern auf gemeinsam genutzte Ressourcen entstehen könnten, unterbunden werden.

Die Concerto-Plattform bietet umfangreiche Optionen: Die Einstiegsversion der MCUs arbeitet bei den Regelungsfunktionen (C28x) und den Kommunikationsfunktionen (Cortex-M3) mit 60 MHz Taktfrequenz; bei MCUs der Mittelklasse beträgt die Taktfrequenz für beide Abschnitte 75 MHz; für besonders anspruchsvolle Applikationen gibt es schließlich Concerto-Bausteine der High-End-Klasse mit Taktfrequenzen von 150 MHz für die Regelung und 75 MHz für die Kommunikation bzw. mit 100 MHz für beide Bereiche.

Hinsichtlich der Speicherbestückung besitzen die Dual-Subsystem-Mikrocontroller eine flexible RAM-Konfiguration. Jeder Kern verfügt über ein Basis-RAM (C28x: 36 KB; Cortex-M3: 32 KB) und je nach Bedarf können den beiden Cores in 8-KB-Blöcken weiteres RAM bis zu 64 KB zugewiesen werden. Außerdem stehen 512 KB Flash-Speicher je Kern zur Verfügung.

Mit 4 KB Messaging-RAM können Nachrichten zwischen den beiden Kernen übertragen werden. Falls nötig, wird zu Synchronisationszwecken ein Time-Stamping-Mechanismus bereitgestellt. Jeder Kern schreibt die zu übertragenden Nachrichten in sein Messaging-RAM und informiert den jeweils anderen, dass Daten zum Lesen vorliegen; auf diese Weise können die beiden Kerne zuverlässig und mit minimaler Latenz kommunizieren. Für die Interprozessor-Kommunikation gibt es eine Software-Bibliothek, deren Protokolle eine weitere Optimierung der Nachrichtenübertragung gewährleisten.