Mikrocontroller-Systemschnittstellen Divergierende Anforderungen

Mikrocontroller in Kfz-Steuergeräten verlangen einen Zugang über die gesamte Lebensdauer der Applikation. Dabei divergieren die Anforderungen an die Schnittstelle für den Systemzugang je nachdem, in welchem Abschnitt in seinem Lebenszyklus sich das Produkt befindet. Dieser Beitrag gibt einen Überblick über die verschiedenen Mikrocontroller-Systemschnittstellen.

Mikrocontroller-Systemschnittstellen

Mikrocontroller in Kfz-Steuergeräten verlangen einen Zugang über die gesamte Lebensdauer der Applikation. Dabei divergieren die Anforderungen an die Schnittstelle für den Systemzugang je nachdem, in welchem Abschnitt in seinem Lebenszyklus sich das Produkt befindet. Dieser Beitrag gibt einen Überblick über die verschiedenen Mikrocontroller-Systemschnittstellen.

Der Lebenszyklus eines Kfz-Steuergeräts unterteilt sich im Wesentlichen in drei Abschnitte: Estens die Phase der Softwareentwicklung und Systemintegration, zweitens die Produktion und schließlich Wartung und Service über die gesamte Lebensdauer. Grundlegende Voraussetzungen, um die teilweise divergierenden Anforderungen in diesen einzelnen Abschnitten des Lebenszyklus erfüllen zu können, sind geeignete Hardwarekomponenten im System, der Zugang zu diesen Komponenten sowie Werkzeuge zur Visualisierung und Auswertung der ermittelten Daten.

Eine wichtige Rolle spielt die Auswahl der Schnittstelle für den Systemzugang. Diese wird durch die Anforderungen in der jeweiligen Phase des System-Lebenszyklus bestimmt. Während der Softwareentwicklung und Systemintegration ist eine schnellstmögliche Kommunikation mit dem Target nötig, um auch bei wachsender Programmgröße effektive Turn-around-Zeiten für den Entwickler zu gewährleisten. Wünschenswert ist auch die Möglichkeit, das laufende System mit möglichst geringer Echtzeitbeeinflussung beobachten zu können.

Weiterhin sollte das Entwicklungswerkzeug vorhandene On-Chip-Debug-Ressourcen in vollem Umfang nutzen können. Eine weitere Anforderung ist, dass die gewählte Debug-Schnittstelle auch für Flash-Programmierung, automatisierte Tests, Profiling, Kalibrierung usw. geeignet ist.

Im Idealfall erfolgt der Zugang für alle Aktivitäten in diesem Lebensabschnitt nur über eine Schnittstelle. In der Phase der Produktion wird der Systemzugang haupt-sächlich für Flash-Programmierung und Test benötigt. Hier liegen die Anforderungen ebenfalls bei schnellstmöglicher Kommunikation mit dem Target, verbunden mit schnellen Flash-Programmieralgorithmen, um kurze Produktionszeiten zu erreichen. Gleichzeitig muss eine hohe Sicherheit durch verschiedene Stufen der Verifikation gewährleistet werden. Das gewählte Softwarewerkzeug muss sich flexibel in typische Produktions- und Testumgebungen einbinden lassen. Oft kommen hier auch andere Interfaces als die dedizierten Debug-Schnittstellen zum Einsatz, da diese in Seriengeräten oft nicht mehr zur Verfügung stehen. Dies ist auch im Bereich Wartung und Service der Fall. Hier kommen als Softwarewerkzeuge meist applikationsspezifische Lösungen mit optimierter Bedienoberfläche zum Einsatz.

Nicht mehr nur JTAG

Bei den Systemschnittstellen bei Mikrocontrollern kann  man zwischen dedizierten Debug-Schnittstellen und Standard-Peripherie unterscheiden. Dedizierte Debug-Schnittstellen sind vom Halbleiterhersteller explizit für den Systemzugang konzipiert und häufig funktional eng mit anderen On-Chip-Debug-Einheiten verbunden. Als Basis hat sich hier JTAG in verschiedenen Implementierungen durchgesetzt. Die Unterschiede liegen vor allem im Protokoll. Die unterste Kommunikationsschicht beruht immer auf dem Standard IEEE 1149.1. Abhängig von der Controller-Architektur und damit dem verwendeten Protokoll über die JTAG-Schnittstelle sind Brutto-Transferraten zum Target von maximal 1 MByte/s bis 3,5 MByte/s möglich. Um diese Leistungsfähigkeit voll ausschöpfen zu können, ist eine spezielle Kommunikationshardware nötig. Um die maximale Transferrate mit dem Target nicht durch den notwendigen Datenaustausch mit dem Host zu beeinträchtigen, sind moderne leistungsfähige PCSchnittstellen wie USB 2.0 mit 480 MBit/s, FireWire mit 400 MBit/s beziehungsweise Ethernet mit 100 MBit/s notwendig (Bild 1).

Neben den dedizierten Debug-Schnittstellen können andere auf den Mikrocontrollern implementierte Peripherie-Schnittstellen für Debugging, Test, Flash-Programmierung und Kalibrierung verwendet werden. Dazu gehört die klassische asynchrone serielle Schnittstelle, die in fast jedem Mikrocontroller implementiert ist. Ihr Vorteil war bis vor kurzem die einfache Verfügbarkeit einer entsprechenden Gegenstelle am Host-Rechner. Bei modernen PCs ist sie nur noch über einen externen USB/Seriell-Konverter realisierbar. Zahlreiche Mikrocontroller bieten über diese Schnittstelle einen Bootstrap-Loader-Mechanismus zur Verbindung mit dem System, ohne dass eine bestimmte Software im Programmspeicher vorausgesetzt wird. Der entsprechende Programmcode ist in einem On-Chip-Boot-ROM abgelegt. Der spezielle Startmodus wird zum Beispiel über eine Reset-Beschaltung (Infineon) oder eine Checksummenprüfung im On-Chip-Flash (Philips LPC2xxx, ARM-basierend) erreicht. Nachteil der asynchronen seriellen Schnittstelle ist die geringe mögliche Übertragungsgeschwindigkeit von nur 115 KBit/s, die bei Größen von On-Chip-Flash-Speicher im Megabytebereich schnell zum Flaschenhals wird. Daher können auch andere serielle (synchrone) Schnittstellen verwendet werden. Mit ihnen sind Übertragungsraten bis in den Bereich einiger Megabit pro Sekunde möglich. Allerdings unterscheidet sich die Implementierung stark zwischen einzelnen Controllerfamilien, und am Host-PC ist ein entsprechendes Kommunikationsgerät erforderlich.

Eine weitere interessante Systemschnittstelle ist der CANBus. Ein entsprechendes Peripheriemodul mit standardisiertem Verhalten findet sich auf vielen Automotive-Mikrocontrollern. Die maximale Transferrate liegt bei 1 MBit/s (High-Speed-CAN). CAN ist bei Kfz-Steuergeräten oft die einzige im Seriengerät noch verfügbare Schnittstelle. Die Busstruktur erlaubt auch die gezielte Adressierung einzelner Knoten. Auch für den CAN-Bus gibt es Bootstrap-Loader-Implementierungen von verschiedenen Herstellern, zum Beispiel Infineon und STMicroelectronics. Da CAN keine Standardschnittstelle am PC ist, wird auch hier ein entsprechendes Kommunikationsgerät benötigt. Das Debuggen und Kalibrieren über CAN-Bus ist eine etablierte Arbeitsweise. Tabelle 1 zeigt einen Vergleich wichtiger Systemschnittstellen.