| Mikrocontroller-Projekte |
| Ronald Daleske |
|
|
|
|
|
|
|
|
Das ITP3-Protokoll ist das 3. komplett neu entwickelte Interface-Transmission-Protokoll. Mit einem Datenbus von 4 Datenleitungen, sowie für jeden Client 2 Steuerleitungen werden nur 6 PINs benötigt um Daten zu senden und zu empfangen. Die Besonderheit ist die asynchrone Übertragung von Daten, dass heißt, kein Client muss innerhalb einer kurzen Zeit die angelegten Daten übernehmen. Das gibt meht Spielraum für Datenübertragung, wenn auf dem Client gerade zeitkritische Interrupts laufen. |
 |
In den vergangenen Jahren wurden bereits das ITP-Protokoll und das ITP2-Protokoll entwickelt. Alle Protokolle hatten andere Anforderungen.
Für das ITP3-Protokoll wurden folgende Anforderungen formuliert:
"Anforderung Nummer1": kein Interrupt für ITP3 notwendig und keine zeitkritischen Protokollabschnitte (wenn es nötig ist, muss die Gegenstelle kurz warten)
möglichst viele Leitungen als Busstruktur verwenden um bei vielen Clients trotzdem wenige Ports am Server zu blockieren
nur 4 Datenleitungen (ein Byte wird somit durch 2 HalbBytes übertragen)
Kurze Bemerkung zur "Anforderung Nummer1":
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 immer exakt abgearbeitet werden. Die Hauptroutine wird aber schon durch den Interrupt unterbrochen. Hier können daher nun keine zeitkritischen (zeitdeterministischen) Aufgaben mehr abgearbeitet werden, denn die Hauptroutine wird ja regelmäßig oder unregelmäßig unterbrochen.
Mit Beginn der Nutzung von mehr als einer Interruptart (Timerinterrupt, I2C-Interrupt, SPI-Interrupt, andere Ereignisinterrupts) wird es mit zeitkritischen Aufgaben richtig kompliziert. Was ist, wenn 2 oder noch mehr Interrupts gleichzeitig ausgelöst werden? Es muss dann immer eine Priorisierung festgelegt werden (Interrupt 2 unterbricht Interrupt1 oder Interrupt 2 wartet bis Interrupt 1 fertig ist).
Ein gutes Beispiel ist das Programm für die VGA-Grafikkarte. Der Mikrocontroller liefert 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 soll nun auf diesem Mikrocontroller ein Protokoll bedient werden, dass streng nach den Vorgaben des Servertaktes arbeiten muß?
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 Nummer1" - "keine zeitkritischen Protokollabschnitte" beim ITP3-Protokoll.
Im Bild 1 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)).
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.
| 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. |
keine Mängelgewähr
DIESE SOFTWARE WIRD VOM URHEBERRECHTSINHABER "OHNE MÄNGELGEWÄHR" BEREITGESTELLT. ALLE AUSDRÜCKLICHEN ODER STILLSCHWEIGENDEN GEWÄHRLEISTUNGEN, EINSCHLIESSLICH DER STILLSCHWEIGENDEN GEWÄHRLEISTUNG DER MARKTGÄNGIGKEIT UND EIGNUNG FÜR EINEN BESTIMMTEN ZWECK (JEDOCH NICHT DARAUF BESCHRÄNKT), WERDEN AUSGESCHLOSSEN. DER URHEBERRECHTSINHABER IST IN KEINEM FALL UND NACH KEINER HAFTUNGSTHEORIE (SEI ES AUF VERTRAGSBASIS, AUF DER BASIS STRENGER HAFTUNG ODER UNERLAUBTER HANDLUNGEN, EINSCHLIESSLICH FAHRLÄSSIGKEIT) FÜR BELIEBIGE VERURSACHTE DIREKTE, INDIREKTE, ZUFÄLLIGE, BESONDERE, EXEMPLARISCHE SCHÄDEN ODER FOLGESCHÄDEN (EINSCHLIESSLICH, JEDOCH NICHT BESCHRÄNKT AUF BESCHAFFUNG VON ERSATZPRODUKTEN ODER -LEISTUNGEN, NUTZUNGSAUSFALL, DATEN- UND GEWINNVERLUST ODER GESCHÄFTSAUSFALL) HAFTBAR, DIE AUFGRUND DER VERWENDUNG DIESER SOFTWARE ENTSTEHEN KÖNNEN. DIES GILT AUCH, WENN AUF DIE MÖGLICHKEIT SOLCHER SCHÄDEN HINGEWIESEN WURDE.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.