Mikrocontroller-Systemschnittstellen

Divergierende Anforderungen

13. September 2006, 12:11 Uhr | Heiko Rießland

Fortsetzung des Artikels von Teil 1

CAN eignet sich zum Programmieren

Aktuell zu beobachten sind Bemühungen, USB oder Ethernet als Debug- und Diagnose-Schnittstelle zu nutzen. So hat Infineon für die »Emulation-Devices« (ED) der 32-Bit-TriCore-Bausteine TC1796 und TC1766 eine Lösung vorgestellt, die einen Systemzugang über USB 1.1 ermöglicht. Problematisch sind jedoch die notwendige enge Verknüpfung mit der Nutzerapplikation und die relativ geringe Transfergeschwindigkeit. Als Hostschnittstelle sind USB und Ethernet natürlich an jedem modernen PC verfügbar.

Die Programmierung der On-Chip-Debug-Einheiten unterscheidet sich ebenfalls zwischen den Halbleiterherstellern. Während bei Infineon die Konfiguration über in den Speicher »gemappte« Register erfolgt, werden PowerPCController von Freescale und ARM-Controller über JTAG-Kommandos programmiert. Damit ist die Nutzung der On-Chip-Debug-Einheiten fest an die JTAG-Schnittstelle gekoppelt. Bei Infineons Lösung ist die Nutzung auch durch eine Monitorsoftware möglich. Dadurch lassen sich Hardware-unterstützte Breakpoints im Flash und Watchpoints auch mit Monitorsoftware realisieren, die beispielsweise CAN als Kommunikationskanal benutzt. Die Implementierung der On-Chip-Debug-Einheit von Infineon gestattet den Zugriff auf den gesamten Speicherbereich zur Laufzeit mit minimaler Echtzeitbeeinflussung. Auch bei PowerPC kann auf On-Chip-Speicher in dieser Weise zugegriffen werden. Das ermöglicht effektives Debugging und Kalibrierung über JTAG. Bei den aktuellen ARMImplementierungen allerdings ist ein Zugriff auf den Target-Speicher über JTAG nur in einem speziellen Debug-Modus mit angehaltener Applikation möglich.


  1. Divergierende Anforderungen
  2. CAN eignet sich zum Programmieren
  3. Flash hat sich Durchgesetzt