Verfahren zum Datenaustausch zwischen
Netzwerkcontroller und CPU
Controller Interfaces
passend für jedes Netzwerk

Die Qualität von Netzwerk Controllern wird oft daran gemessen, wie gut sie die speziellen Funktionen des Kommunikationssystems realisieren. Weniger Beachtung findet dabei die Schnittstelle zur übergeordneten CPU, die insbesondere bei performanten Real-Time-Ethernet-Systemen zu einem „bottle neck“ in der Übertragung führen kann. Gegenüber etablierten Feldbussen sind deren Zykluszeiten und Telegrammlängen bis um den Faktor zehn kritischer. Hinzu kommen Anforderungen an Synchronisation und Jitter mit Werten kleiner 100 Nanosekunden. Nachfolgender Artikel beschreibt Alternativen, die in der Familie der netX Controller für verschiedene Kommunikationssysteme zum Einsatz kommen.

Automatisierungsgeräte tauschen ihre Daten häufig über intelligente Kommunikationseinheiten aus, die auf das jeweilige Übertragungssystem ausgelegt sind. Diese bestehen aus dem physikalischen Interface zum Anpassen der Signalpegel, dem eigentlichen Netzwerk Controller, der für die seriell/parallel Wandlung, Codierung, Sicherung sowie das Daten-Timing verantwortlich ist, und einer CPU, die auf Telegrammebene die Verbindung zum Kommunikationspartner aufbaut und den Protokollablauf steuert. Je nach Integrationsumfang sind CPU und Netzwerk Controller, bei Ethernet Systeme oft auch das physikalische Interface, in einem Chip zusammengefasst. Ein Beispiel dafür sind die netX Controller. Die Schnittstelle zwischen Netzwerk Controller und CPU muss folgende Funktionen zur Verfügung stellen:
–
Konsistenter und deterministischer Aus-

tausch der zyklischen Daten
–
Weitergabe von azyklischen Dateneinheiten in unterschiedlicher Länge und Anzahl, sowie zu

undefinierten Zeitpunkten
–
Statusinformationen zur aktuellen Da-

tenübertragung und eventuell aufge-

tretenen Fehlern
–
Synchronisation der Datenübertragung
Der netX unterstützt verschiedene Kommunikationssysteme. Demzufolge muss die Schnittstelle zwischen dem internen Netzwerk Controller xPEC und der ARM CPU alle aufgeführten Schnittstellenfunktionen in entsprechenden Umfang zur Verfügung stellen. Realisiert sind diese in einzelnen, konfigurierbaren Hardwareeinheiten, die je nach Netzwerk mitein-ander interagieren. Daraus ergibt sich eine flexible zukunftssichere Kommunikationsschnittstelle.

Datenaustausch zwischen xPEC und ARM

Für den konsistenten Austausch von Daten zwischen xPEC und ARM eignet sich der Buffer Manager. Kennzeichnend für diese Technologie ist der zum Aktualisierungszyklus der Schreibseite unsynchronisierte Anforderungszyklus der Leseseite von in sich konsistenten Daten. Hier muss zwischen der Übertragung von zyklischen Prozessdaten z.B. die Ein-Ausgabedaten eines Slaves und azyklischen Parametrier- und Diagnosedaten unterschieden werden. Bei letzterem ist es für die Leseseite entscheidend alle Daten der Schreibseite „mitzubekommen“. Dies setzt voraus, dass die Schreibseite erst neue Daten der Leseseite übergeben darf, wenn diese die zuletzt geschriebenen Daten gelesen hat. Um beiden Anforderungen gerecht zu werden besitzt der Buffer Manager zwei Modi, den Einfachpuffer-Modus (Single-buffered) und den Dreifachpuffer-Modus (Triple-buffered). Beim „Single-buffered“ Modus gibt es neben dem Datenpuffer einen Pufferstatus. Die Schreibseite kann nur schreiben wenn der Puffer nicht gefüllt ist (Pufferstatus = leer). Nach dem Schreiben wird der Pufferstatus auf voll gesetzt (Pufferstatus=voll) und jedes weitere Schreiben wird solange blockiert bis die Leseseite diesen ausgelesen und den Pufferstatus auf leer zurückgesetzt hat.

Austausch zyklischer Daten

Zum Datenaustausch von Prozessdaten und anderen zyklischen Daten kommt die Dreifachpuffertechnik zum Einsatz. Hierbei werden drei gleichgroße Speicherbereiche (Puffer 0,1 und 2) zur Zwischenlagerung der Daten verwendet. Der Buffer Manager verwaltet lediglich Puffernummern. Mit einem einfachen „Register lesen“ fordert die Schreibseite einen „leeren“ Puffer an und bekommt direkt dessen Puffernummer zurück. In diesen Puffer werden die Daten geschrieben, um anschließend die Puffernummer dem Buffer-Manager zu übergeben. Dieser merkt sich die Nummer als „aktuellsten“ Puffer. Völlig unabhängig davon fordert die Leseseite bei Bedarf den „aktuellsten“ Puffer an und bekommt die Puffernummer des zuletzt komplett beschriebenen Puffers zurück. Da Schreibseite und Leseseite völlig unsynchronisiert zueinander arbeiten, kann es vorkommen das beide Seiten gleichzeitig eine Pufferanforderung stellen. Dieser Fall wird vom Buffer Manager unter Einhaltung der Datenkonsistenz aufgelöst. Wenn der Datenanforderungszyklus der Leseseite kürzer als der Aktualisierungszyklus der Schreibseite ist, bekommt die Leseseite entsprechend die gleiche Puffernummer mehrmals hintereinander. Im umgekehrten Fall (Lesezyklus größer als Schreibzyklus) „sieht“ die Leseseite nicht alle geschriebenen Daten; es ist aber sichergestellt dass sie bei Lesepufferanforderung immer den aktuellsten Puffer bekommt. Der Buffer Manager im netX bietet 16 Kanäle und kann somit bis zu 16 Puffer-Systeme verwalten. Für jeden einzelnen Kanal kann der Modus (Einfach- oder Dreifachpufferung) sowie die Schreib- und Leseseite (ARM und xPEC) individuell eingestellt werden. Erst der Buffer-Manager entlastet die ARM CPU soweit, dass Buszykluszeiten bis zu 30 Mikrosekunden erreicht werden. Er kommt u.a. bei der Realisierung des Datalink-Layers des EtherCat-Slaves zum Einsatz, wo jedem EtherCat Sync Manager ein Kanal des Buffer Manager zugeordnet ist.

Datenaustausch via FIFO

Als weitere Hardware-Unterstützung zum Datenaustausch zwischen xPEC und ARM wurde die Pointer-FIFO entwickelt. Dieses Modul besteht aus 16 FIFOs, wobei die Tiefe jeder einzelnen FIFO beliebig einstellbar ist. Einzige Einschränkung ist, dass alle 16 FIFOs zusammen maximal 1024 Einträge aufnehmen können. Ein Eintrag hat mit 32Bit die Breite eines Doppelwortes und wird meist als Adresszeiger auf einer Dateneinheit im internen Speicher benutzt. Alle xPECs und die ARM können auf jede der 16 FIFOs schreibend und lesend zugreifen. Ein vorgelagerter Arbiter löst Zugriffskonflikte innerhalb von 50ns auf. Zusätzlich stehen Statusinformationen über Füllstand und aufgetretenen Über- oder Unterlauf der FIFOs zur Verfügung. Die Pointer FIFO dient zum Ausgleich von unterschiedlichen Bearbeitungszeiten der Dateneinheiten im xPEC und der ARM. Dabei bestimmt die Tiefe der FIFO die Toleranz gegenüber Staus in der Verarbeitung der Dateneinheit auf der Leseseite, z.B. durch Unterbrechungen zur Bearbeitung von höher prioren Aufgaben. Beim Ethernet MAC werden über die Pointer FIFO Adresspointer auf die im internen Speicher liegenden Ethernet-Frames ausgetauscht ohne das aufwendige Software basierte Verwaltungsstrukturen erforderlich sind. Die Nutzdaten werden per DMA-Controller übertragen. Beim CAN sind die Dateneinheiten (CAN Frames) nur 8Byte lang. Diese werden direkt über Pointer FIFOs ausgetauscht und erlauben darüber eine einfache Priorisierung der CAN Frames.

Austausch von großen Dateneinheiten mit DMA-Controller

Größere Datenmengen zwischen xPEC und ARM werden klassisch per DMA-Controller zwischen xPEC-Speicher und netX internem RAM, unter vollständiger Entlastung des ARM-Prozessors, übertragen. Die Übertragungsleistung beträgt maximal 400MByte pro Sekunde. Der DMA-Controller stellt verschiedene Modi zur Verfügung, die mit Pointer FIFO und Interrupt Register zusammen arbeiten. Beim Ethernet MAC wird der DMA verwendet, um die Ethernet Dateneinheit in das interne SRAM zu übertragen. Ein Ethernet MAC muss maximal 25MByte pro Sekunde (12,5MByte pro Richtung im 100MBit Full-Duplex-Mode) verarbeiten können. Bei einem Ethernet Switch verdoppelt sich das Mengengerüst an Transferdaten entsprechend der Portanzahl.

Daten und Statis im direkten Zugriff

Der xPEC arbeitet auf einem 8KByte großen Speicher. Dieser Speicher beinhaltet entsprechend dem Übertragungsprotokoll direkt das I/O-Abbild und/oder Statusinformationen. Der Speicher ist als Dual-Port-Memory zwischen xPEC und ARM angelegt. Der Zugriff erfolgt von xPEC und ARM-Seite aus 8, 16 oder 32Bit granular. Beim EtherCat Slave beinhaltet das Dual-Port-Memory die Prozess- und Mailboxdaten der lokalen Applikation; beim Ethernet MAC oder CAN Controller sind hier Fehlerzähler und Konfigurationsparameter hinterlegt.

Kommandoaustausch mit Interrupt-Register

Zum Austausch von Bit-weisen Kommandos und Statis zwischen xPEC und ARM gibt es das Interrupt-Register. Dies ist in zwei Bereiche aufgeteilt. Die unteren 16Bits stehen dem xPEC zur Generierung von zwei Sammel-Interrupten für Kommunikation und Synchronisation an die Protokollschicht (ARM) zur Verfügung. Diese Trennung ermöglicht es der Protokollschicht Synchronisationsfunktionen gegenüber Kommunikationsaufgaben mit hoher Priorität zu bearbeiten und dadurch Determinismus sicherzustellen. Die oberen 16Bits des Interrupt-Registers dienen der Protokollschicht (ARM) zur Signalisierung von einzelnen Events an den xPEC. Dies kann z.B. einen Pufferaustausch anfordern oder einen Zustandswechsel des xPECs auszulösen.

Stabile Kommunikation unter allen Bedingungen

DMA-Controller, Dual-Port-Me­mo­ry und Interrupt-Register sind bekannte Hardware Strukturen zur Übergabe und Synchronisation von Daten. Dagegen sind Funktionen wie sie der Buffer Manager oder die Pointer FIFO zur Verfügung stellt, bislang meist in Software realisiert worden. Jedoch zeigen die Erfahrungen, dass die hohen Performance Anforderungen von Real-Time-Ethernet Systeme die im Embedded Bereich eingesetzten Prozessoren leicht an die Grenze ihrer Leistungsfähigkeit bringen. Erst die Realisierung als eigene Hardware Unit schafft hier Abhilfe, vereinfacht die Software Architektur und gewährleistet eine stabile Kommunikation unter allen Bedingungen.

Autor: Hans-Jürgen Hilscher, Geschäftsführer der Hilscher Gesellschaft für Systemautomation mbH