ITP3-Protokoll und ITP3-Schnittstelle

Das ITP3-Protokoll ist das 3. komplett neu entwickelte Interface-Transmission-Protokoll. Mit einem Datenbus von 4 Datenleitungen, sowie für jeden Client 1 Steuerleitungen sowie einer (durch alle Clients gemeinsam genutzten Rücklmeldeleitung) werden nur 6 PINs benötigt um Daten zu senden und zu empfangen. Die Besonderheit ist die asynchrone Übertragung von Daten, dass heisst, kein Client muss innerhalb einer (vom Server definierten) Zeit die angelegten Daten übernehmen. Das gibt meht Spielraum für Datenübertragung, wenn auf dem Client gerade zeitkritische Interrupts laufen.

1. grundlegende Anforderungen

In den vergangenen Jahren wurden bereits das ITP-Protokoll und das ITP2-Protokoll entwickelt. Jedes dieser Protokolle hatten andere Anforderungen.

Für das ITP3-Protokoll wurden folgende Anforderungen formuliert:

keine zeitkritischen Protokollabschnitte (wenn es nötig ist, muss die Gegenstelle warten)
Für die Datenleitungen wird ein Datenbus genutzt. Damit möglichst wenig Ports der genutzten Microcontroller belegt werden, werden 4 Datenleitungen im Datenbus genutzt (ein Byte wird somit durch 2 HalbBytes übertragen)
Jeder Client wird einzeln über die "Device Select x" Steuerleitung angesprochen (Low-aktiv). Mit dieser Leitung aktiviert der Server den Client und überträgt die Steuersignale. Es wird zur gleichen zeit immer nur mit einem Client kommuniziert. Der Datenbus wird in dieser Zeit nur zwischen dem Server und dem angesprochenen Client genutzt.
Für die Rückmeldung aller Clients soll nur eine Leitung "Device Receive" genutzt werden (Low-aktive Ein-Bus-Leitung mit Pull-Up-Widerstand).

Somit werden für das ITP3-Protokoll 5 Leitungen (4xDatenbus, 1x Device Receive) plus jeweils eine Leitung für jeden Client (Device Select 0..x) benötigt.

Kurze Bemerkung zur "Anforderung Nummer 1":

Arbeitet ein Microcontroller ohne Interrupt, ist die Programmierung und die zeitliche Abfolge der Befehle einfach und übersichtlich.

Wird eine Interruptart (z.B. Timerinterrupt) benutzt, so kann die Interruptroutine jeder Zeit exakt abgearbeitet werden. Die Hauptroutine wird aber bereits durch den Interrupt unterbrochen. Hier können nun keine zeitkritischen (zeitdeterministischen) Aufgaben mehr abgearbeitet werden, denn die Hauptroutine wird regelmäßig oder unregelmäßig unterbrochen.

Mit Beginn der Nutzung von mehr als einer Interruptart (Timerinterrupt, I2C-Interrupt, SPI-Interrupt, andere Ereignisinterrupts) wird es bei zeitkritischen Aufgaben kompliziert. Was ist, wenn 2 oder noch mehr Interrupts gleichzeitig ausgelöst werden? Es muss dann immer eine Priorisierung festgelegt werden (Interrupt 2 unterbricht Interrupt 1 oder Interrupt 2 wartet bis Interrupt 1 fertig ist).

Ein gutes Beispiel ist das Programm für die VGA-Grafikkarte. Der Mikrocontroller liefert in einer taktgenauen Assemblerroutine die Daten und die Steuersignale für das VGA-Signal. Alle Signale sind sehr zeitkritisch und dürfen nicht unterbrochen oder verzögert werden (Verzögerungen bewirken ein Flackern des Monitors).

Wie kann auf diesem Mikrocontroller ein Protokoll bedient werden, dass streng nach den Vorgaben eines anderen Servertaktes arbeiten muss?

Die logische Konsequenz war, dass bei der Übertragung von Zeichen an die VGA-Grafikkarte über das SPI oder I2C-Protokoll einfach ab und zu Zeichen "verschluckt" wurden.

Daher die "Anforderung Nummer 1" - "keine zeitkritischen Protokollabschnitte" beim ITP3-Protokoll.

Zum Beispiel der VGA-Grafikkarte läuft das ITP3-Protokoll des Clients (wie auch bei allen anderen Anwendungen des ITP3-Protokolls) in der Hauptschleife des Microcontrollers und bedient dort die Anforderungen des Servers (sozusagen im Polling Verfahren). Wird die Routine des ITP3-Protokolls durch einen Interrupt unterbrochen, so wartet der ITP3-Server so lange, bis die Antwort des Clients fort gesetzt wird.

Dieses "Warten" suggeriert, dass das ITP3-Protokoll langsamer abläuft als (vom Server) Protokolle, die zeitlich vorgegebene Taktzyklen benutzen und erfordern. Die Praxis zeigt aber, dass das ITP3-Protokoll doch recht schnell und dabei sehr einfach ist (auch bezüglich möglich auftretender kritischer Abschnitte bei Interrupts).

Die Maxime ist, jeder ITP3-Client versucht die Anforderungen des ITP3-Servers möglichst schnell zu beantworten.

2. ITP3-Schichtenmodell

Bild 1: ITP3-Schichtenmodell

3. Byte-Übertragungs-Ebene

Bild 2: Grundprinzip des Interface Transmission Protokolls 3 (ITP3)

Im Bild 2 ist das Grundprinzip des ITP3-Protokolls mit 1 Server und 2 Clients dargestellt.

Die 4 Datenleitungen bilden einen bidirektionalen 4-Bit-Datenbus.

Jeder Client has seine eigene Device-Select-Leitung.

Die Device-Receive-Leitung wird vom jeweils angesprochenen Client als Bestätigungsleitung zum Server genutzt (die nicht angesprochenen Clients schalten diesen Ausgang ab (in der Praxis wird dieser Anschluß für die Zeit als Eingang programmiert)).

3.1. Taktdiagramm (Server sendet Daten an Client)

Das Taktdiagramm zeigt den zeitlichen Ablauf der Ereignisse, wobei keine genauen Zeitintervalle eingehalten werden müssen.

Beispielhaft soll ein Halbbyte vom Server an einen Client übertragen werden.

Bild 3: ITP3 Taktdiagramm (Server sendet Daten an Client)

Abschnitt	Aktionen am Server	Aktionen am Client
A	Der Server schaltet die Datenleitungen auf Ausgang. Es wird das zu sendende HalbByte auf den Datenbus gegeben.	Der Client wartet auf Aktivierung der DS Leitung.
B	Der Server aktiviert die DS (Device Select) Leitung für den Client. Der Client kann die Daten übernehmen.	Der Client wartet auf Aktivierung der DS Leitung.
C	Der Server wartet auf Aktivierung der DR Leitung.	Der Client übernimmt die Daten vom Datenbus.
D	Der Server wartet auf Aktivierung der DR Leitung.	Der Client bestätigt die Datenübernahme durch Aktivierung der DR Leitung.
E	Der Server deaktiviert die Datenleitung.	Der Client wartet auf Deaktivierung der DS Leitung.
F	Der Server deaktiviert die DS Leitung für diesen Client.	Der Client wartet auf Deaktivierung der DS Leitung.
G	Der Server wartet auf Deaktivierung der DR Leitung.	Der Client gibt die DR Leitung frei (auf Eingang stellen). Da die DR Busleitung mit einem Widerstand gegen die Versorgungsspannung geschaltet ist, wird damit die DR Leitung sofort automatisch deaktiviert.

4. Initialisierungsablauf für den Client

Die Implementierung des ITP3-Protokolls auf einem beliebigen Client ist (im Vergleich zu anderen Protokollen wie z.B. dem USB-Protokoll) schnell umsetzbar, da das ITP3-Protokoll einfach gehalten wurde.

Bild 4: Ablauf der Initialisierung für den Client

Es gibt aber einige

Startseite

Impressum