USB (Universal Serial Bus), IEEE1394 (Firewire), IrDA (Infrared Data Association) und Bluetooth für embedded Systeme Rudi Latuske ARS Software GmbH Email: rlatuske@ars2000.com Bedingt durch die Weiterentwicklung bei Personal Computern und mobilen Geräten (z.b. PDA, Mobiltelefone) wurden neue Technologien für den Anschluß von Peripherie an den PC bzw. für die Verbindung von verschiedenen Geräten untereinander eingeführt. Zu diesen Technologien gehören u.a. USB, IEEE-1394 (bekannt als Firewire), IrDA und in Zukunft Bluetooth (Übertragung über eine Funkschnittstelle). Bisher wird für den Anschluß von embedded Systemen an den PC u.a. der V.24 Port eingesetzt. Der Bedarf an höheren Geschwindigkeiten läßt sich damit nur bedingt erfüllen. Da die Zukunft des klassischen COM - Port ungewiß ist, bzw. das Aufsetzen von eigenen Treibern auf COM - Ports in Zukunft nur eingeschränkt oder gar nicht mehr möglich ist, TCP/IP nicht immer geeignet ist, bieten sich für solche Aufgaben die neuen Schnittstellen an. Bei Einsatz dieser Schnittstellen in embedded Systemen besteht auch der Wunsch nach identischer Funktionalität und Komfort wie bei einem PC. Die neuen Schnittstellen sind z.t. auch sehr komplex und basieren auf einem Layer-Modell mit Protokoll. Im folgenden soll ein Überblick über die technischen Merkmale inkl. Stand der Normung und die Implementierung von IrDA, Bluetooth, USB und IEEE1394 in embedded Systemen gegeben werden.. Dabei werden auch die notwendigen Anforderungen der jeweiligen Vernetzungsverfahren an die Ressourcen (CPU, Speicher) und Anwendungsprofile von IrDA und Bluetooth besprochen. IrDA (Infrared Data Association) Entwicklung von IrDA Die Entwicklung von IrDA basiert im wesentlichen auf Vorarbeiten und Entwicklungen der Firma Hewlett-Packard. HP hatte bereits 1979 eine Infrarot (IR) - Schnittstelle in Taschenrechner für die Verbindung zu einem Drucker und 1990 in Desktop - PC integriert. Diese Entwicklungen liefen bei HP unter dem Namen Serial - Infrared (SIR). Bedingt durch die immer stärkere Verbreitung von Infrarot(IR) - Schnittstellen und dem Wunsch nach Zusammenarbeit zwischen den verschiedenen Geräten, ergab sich die Notwendigkeit einer Abstimmung auf ein einheitliches Protokoll. Im August 1993 wurde von ca. 30 Firmen die Infrared Data Association (IrDA) gegründet. Ein Jahr später wurde die Spezifikation 1.0 verabschiedet. Diese basierte zum großen Teil auf den Vorarbeiten von HP. Deswegen wurde diese IrDA Version auch SIR (Serial Infrared) genannt. Im Oktober 1995 folgte die Version 1.1. Damit wurde u.a. die Geschwindigkeit von 115 KBits/s auf 4 Mbit/s erhöht. Der Standard IrDA wurde auch für temporäre Anwendungen entwickelt. Viele Handheld - Geräte brauchen keine permanente Verbindung über IR. Die Verbindung selbst kann unbeabsichtigt, z.b. durch in die Verbindungslinie gebrachte Gegenstände, unterbrochen werden. Die Verbindung über IR muß bei erstmaliger und wiederholter Verbindungsaufnahme schnell etabliert werden. Die Ad-hoc Natur dieser Verbindungen wird von IrDA unterstützt.
Die Version 1.0 von IrDA unterstützt Geschwindigkeiten von 2400 Bits/s bis zu 115 Kbit/s. Die Implementierung kann mit einem Standard UART und einem Transceiver sehr einfach aufgebaut werden. Die zweite IrDA Version (1.1) beinhaltet einen erweiterten Physical Layer mit drei neuen Geschwindigkeiten: 576 Kbit/s, 1.152 Mbit/s und 4 Mbit/s (Fast Infrared, FIR). Eine weitere wesentliche Erweiterung des IrDA Protokolls war die Einführung von IrCOMM (V.24 Emulation). Die Version 1.2 bzw. 1.3 (Very Fast Infrared, VFIR) unterstützt 16 Mbit/s. Die Entfernung zwischen 2 IrDA Geräten ist 1 Meter. Bestandteile von IrDA Um den Eingangs genannten Anforderungen nach einer sicheren Zusammenarbeit mit unterschiedlichen Geräteklassen gerecht zu werden, besteht IrDA aus einer Reihe von Protokollschichten. Bild 1 zeigt eine Implementierung mit den Schnittstellen zur Hardware, zu einem Betriebssystem und mit Anwendungen (OBEX, IrCOMM und IrTran-P). IrDA Anwendungen OBEX IrTran-P IrLPT IrCOMM IAS IAS Stack API Tiny TP IrLMP IrLAP Betriebs -system API OS API Framer Timer Physical Layer Contr./Transceiver Bild 1 Architektur eines IrDA Protokoll-Stack für embedded Systeme
Physical Layer IrDA ist für Entfernungen von bis zu 1 Meter ausgelegt (3 Meter sind möglich). Der Winkel in dem gesendet und empfangen wird beträgt +/- 15% bis ca. +/- 30%. Die Eigenschaften des IR Senders und Empfängers sind stark von den verwendeten Bauteilen abhängig. Die Bit Error Rate beträgt 1 zu 10-8. IrDA arbeitet im IR - Bereich von zwischen 850 und 900nm. Für den Physical Layer gibt es 3 Varianten, die alle in Halb - Duplex realisiert werden. Die Verbindung selbst basiert auf einem Master ( Primary ) / Slave (Secundary) Konzept. Bei der IrdA Spezifikation 1.0 wurde ein asynchrones UART Interface mit 8 Datenbits, keine Parität, 1 Start Bit und 1 Stop Bit verwendet. Dieses Interface wurde mit IR Encoder/Decoder und IR Transceiver versehen. Damit lassen sich sehr preiswerte Interfaces aufbauen. Das Encoding basiert auf RZI (Return to Zero Inverted). Für die Unterstützung höherer Datenraten wurde bei IrDA 1.1 die synchrone Datenübertragung mit 0.576 Mbit/s und 1.152 Mbit/s definiert Da Anwendungen im Multimediabereich nach noch höheren Datenübertragungsraten für z.b. den Transfer von Graphiken und Bildern verlangen, wurde von der IrDA auch Fast Infrared (FIR) mit 4 Mbit/s und VFIR (16 Mbit/s) definiert. IrDA Link Access Protocol (IrLAP) Der Daten Link Layer bei IrDA wird durch IrLAP realisiert. Dieses Protokoll stellt einen zuverlässigen Datentransfer unter Verwendung von Retransmission, Flußkontrolle und Fehlerkorrektur zur Verfügung. Der Benutzer von IrDA kann auf Übertragungsprobleme hingewiesen werden, ohne das die Verbindung unterbrochen wird oder Daten verloren gehen. Die Primary Station ist verantwortlich für den Aufbau der Verbindung, den Datentransfer, Flußkontrolle und die Behandlung von Data Link Fehlern. Typische Primary Geräte sind PCs, PDAs, Kameras und Geräte, die Daten zum Drucker senden. Die Secundary Station sendet und antwortet nur wenn sie selbst angesprochen wird. Typische Secundary Geräte sind Drucker und Geräte mit geringen Systemressourcen. Secundary Implementierungen sind weniger komplex. Keine Station kann mehr als 500ms senden. Danach muß die andere Seite antworten. Dieses Zeitlimit gilt auch, wenn die andere Seite nichts zu senden hat. Abhängig davon ob eine Verbindung besteht oder nicht, basiert IrLAP auf den Normal Disconnect Mode (NDM) und dem Normal Response Mode (NRM). Der NDM ist der default Mode für Geräte, die nicht verbunden sind. Die Geräte in diesem Mode müssen im Link und Physical Layer eine Reihe von Bedingungen einhalten. Ein Gerät muß z.b. prüfen ob z.zt. andere Übertragungen stattfinden. Wenn IrLAP keine Aktivität für 500ms feststellt, wird eine freie Verfügbarkeit des Kanals angenommen. Vor der eigentlichen Datenübertragung werden zwischen den beteiligten Stationen die Parameter für die höchste Übertragungsrate zwecks Abstimmung ausgetauscht. Im NRM Zustand befinden sich alle Geräte die eine Verbindung haben. IrLAP wird durch eine von Funktionen realisiert. Mit REQUEST wird von einem höheren Layer ein Service gestartet. Mit INDICATION wird ein IrLAP Status oder ein Event dem höheren Layer des z.b. Empfängers mitgeteilt. Mit RESPONSE wird von einem höheren Layer ein Acknowledgement ausgelöst. Mit CONFIRM wird dem ursprünglichem Sender die Bestätigung seines REQUEST gesendet. Die Verbindungen können verbindungslos oder verbindungsorientiert aufgebaut werden. Bild 2 zeigt den Ablauf des Verbindungsaufbaus und die Kommunikation.
Gerät Gerät A A Anwendung Anwendung Gerät Gerät B B Anwendung Anwendung REQUEST CONFIRM RESPONSE INDICATION IrLAP IrLAP IrLAP Physical Physical Layer Layer Physical Physical Layer Layer IR Frames IrLAP definiert auch Services für die Link - Kontrolle. DEVICE DISCOVERY wird für die Suche nach anderen IR Gerätes benötigt. Dabei werden die physikalischen Adressen aller Geräte innerhalb des Empfangsbereiches ermittelt. Alle Geräte erzeugen eine Zufallsadresse und antworten mit einem RESPONSE Frame. Die so ermittelten Daten (Adresse, Kommunikationsparameter usw.) werden an die höheren Layer weitergegeben. Die DISCOVERY Funktion wird bei 9600 Baud durchgeführt. Mit dem Service CONNECT wird ein Kommunikationspartner ausgewählt. Dabei sendet der Initiator einen Frame mit den von ihm unterstützten Kommunikationsparametern. Der Empfänger sendet entweder einen Frame mit den akzeptierten Parametern oder einen DISCONNECT Frame um die Verbindung abzulehnen. Die ausgehandelten Parameter, hier ist besonders die Turnaround Time von Bedeutung, haben eine signifikante Auswirkung auf die Effizienz und den Durchsatz der Datenübertragung. Diese Effekte sind besonders bei FIR/VFIR wichtig. Die Turnaround (Umschaltung zwischen Sende- und Empfangsmode) Zeit ist u.a. auch von den Verzögerungen im IrDA Transceiver abhängig. Eine Turnaround Zeit von 1 ms entspricht bei einer Übertragung mit 115 Kbit/s nur 14 Bytes, bei 4 Mbit/s aber 500 Byte Daten die nicht gesendet werden können. Direkt damit in Zusammenhang steht die Window Size. Eine Window Size von 1 (7) bedingt nach einem (sieben) Datenpaket/en (Frame/s) eine Quittierung. Mit einer Window Size von 7 und einer geringen Turnaround Time (hardwareabhängig) sind bei FIR maximale Datentransferraten erzielbar. Der STATUS SERVICE wird für das Mitteilen der Qualität der Verbindung verwendet. RESET SERVICES für das Zurücksetzen beider, an der Verbindung beteiligter Geräte, DATA mit den Varianten Reliable, Sequenced und Unreliable für die Übertragung der Nutzdaten. Dabei können Daten auf mehrere Frames aufgeteilt oder nur in einem Frame versendet werden Die Services EXPEDITED und DISCONNECT werden für den Abbau der logischen Verbindung und den Übergang in den NDM Status verwendet. IrDA Link Management Protocol (IrLMP) IrLMP benötigt die von IrLAP ausgehandelte zuverlässige Verbindung. IrLMP übernimmt Multiplexing (mehrere IrLMP Clients benutzen einen IrLAP Link), Beseitigung von Adressenkonflikten (wenn Geräte die gleiche Adresse benutzen, erfolgt Aufforderung an beide jeweils eine neue Adresse zu generieren) und Information Access Service (IAS), eine Art Yellow Service.
Um mehrere IrLMP Verbindungen auf einem IrDA Kanal unterstützen zu können, muß bei IrLMP ein Modell für die Adressierung der höheren Schichten vorhanden sein. Bei IrLMP gibt es dafür den Logical Service Access Point (LSAP) und die LSAP - Selektoren. Mit dem LSAP wird ein Service oder eine Anwendung innerhalb des IrLMP (z.b. ein Druckservice) angesprochen. Der LSAP-SEL ist ein Pointer mit einem Byte (verweist auf LSAP). DEVICE DISCOVERY wird für die Ermittlung zusätzlicher Informationen über die anderen IrDA Geräte verwendet. Mit CONNECT werden Verbindungen von Servicediensten auf IrLMP Level durchgeführt. Mit DISCONNECT wird eine bestimmte IrLMP Verbindung aufgetrennt. Dabei können andere IrLMP und IrLAP Verbindungen weiterhin bestehen bleiben. IAS - Yellow Pages für Dienste und Anwendungen Alle vorhandenen Dienste und Anwendungen (OBEX, IrCOMM) müssen im IAS eingetragen werden. Diese Einträge werden dann für die Service Adresse (LSAP-SEL) verwendet. Eine vollständige IAS Implementierung besteht aus Client und Server. Der IAS Server kennt die notwendigen Antworten auf die Anforderungen eines Client. Der Server verwendet lokale Informationen ähnlich denen einer MIB bei SNMP. Diese Informationen können in einem embedded System fest abgelegt oder nachträglich angesprochen werden. Die IAS Information Base (IAS-IB) ist eine Sammlung von Objekten, welche die verfügbaren Services für eingehende Anforderungen beschreiben. Die Information Base besteht aus einem Class Name (max. 60 Bytes) und einem oder mehrere Attributen. (typisch sind 64 Bytes). In den IAS können auch Geräte-/Herstellernamen und die Version eines Gerätes eingetragen werden. Die IAS erleichtern das Erkennen von in einem Gerät integrierten Anwendungen und deren Leistungsmerkmalen. Tiny TP (Transport Protocol) Flußkontrolle ist die wichtigste Aufgabe von TTP. Flußkontrolle wird für jede LMP Verbindung getrennt vorgenommen. Wenn der Multiplexed Mode von IrLMP verwendet wird, sind auch mehrere IrLAP Verbindungen aktiv. Dabei können Daten verloren gehen oder Deadlock - Situationen entstehen. Diese werden durch auf Kredit basierende Flußkontrolle vermieden. Dabei wird jeder Seite vor Verbindungsaufbau vom jeweils anderen Teilnehmer Kredit erteilt. Die Anzahl der zugeteilten Kredits ist vom verfügbaren Pufferspeicher der Empfängerseite abhängig. Ein Kredit entspricht einer Erlaubnis ein LMP Paket zu senden. Die maximale Anzahl der zugeteilten Kredits beträgt 127. Auch wenn nur ein Kredit gesendet wird, muß der Empfang von Daten mit der maximalen Paketgröße möglich sein. Wenn Daten gesendet werden, wird der Kredit jeweils um einen Wert reduziert. Der Empfänger erteilt periodisch mehr Kredit. Die Regeln dafür sind unter alleiniger Kontrolle des Empfängers. Diese Regeln sind ein bestimmter Faktor für die Performance der IrDA Verbindung. Wenn der Sender permanent keinen Kredit zur Verfügung hat, und er immer auf die Zuteilung dafür warten muß, geht das sehr stark zu Lasten des Durchsatzes. Ein Kredit Paket unterliegt nicht der Flußkontrolle d.h., es kann immer, auch bei fehlendem Kredit gesendet werden. Da bei einer IrDA Verbindung beide Seiten als Sender und Empfänger arbeiten können, erteilen beide Seiten Kredit. Die Kredit Pakete werden am Anfang des ersten IrLMP Daten Paketes geschickt. Danach werden die Kreditpakete immer als Delta zum ersten Wert versandt. Die Service Dienste für Flußkontrolle sind CONNECT (Aushandeln der maximalen SDU Größe), DISCONNECT, DATA, LOCAL FLOW CONTROL (stoppt das Senden von Daten) und UDATE (Datentransfer im Transparent Mode, nicht zuverlässig).
Emulation von Schnittstellen mit IrCOMM Bei IrDA müssen alle Signale über einen IR Strahl gesendet und alle Informationen in das IrLMP verpackt werden. Bei IrCOMM werden 4 verschiedene Schnittstellen emuliert. 3 Draht Raw Data (IrLPT), Emulation paralleler und serieller Schnittstellen für das Senden von Daten, keine Kontrollinformationen, kein Multiplexing, arbeitet direkt auf dem IrLMP 3 Draht, Emulation paralleler und serieller Schnittstellen, emuliert eine einfache V.24 Schnittstelle, minimale Verwendung von Kontrollinformationen, arbeitet mit Tiny TP 9 Draht, nur für die Emulation serieller Schnittstellen, emuliert eine vollständige V.24, verwendet Informationen für den Status der V.24 Steuersignale, arbeitet mit Tiny TP Centronics, wertet die Status der Centronics Signale aus, verwendet Tiny TP Bei IrCOMM werden auch Handshake Signale (z.b. DTR, DSR usw.) emuliert. IrOBEX - ein Object Exchange Protocol IrOBEX ist eine Anwendung für den Austausch von Daten in unterschiedlichen Formaten zwischen IrDA Geräten. Dabei werden die zu übertragenden Daten wie Bilder, Visitenkarten, Daten von Handheld Geräten usw. als Objekte behandelt. Die Funktionen und die Arbeitsweise von IrOBEX ist ähnlich der von HTTP. Ziele von IrOBEX sind die drastische Vereinfachung des Transfers verschiedener Daten, ohne das der Anwender sich um unterschiedliche Formate usw. kümmern muß. Der Entwickler hat die Möglichkeit der Erweiterung des Funktionsumfangs von IrOBEX über die Definition neuer Session - Operationen und neuer Objekttypen. OBEX umfaßt das Session Modell für den Austausch der Daten, PUT und GET Operationen und das Objekt Modell für die Beschreibung der Objekte. Für IrOBEX existiert auch ein speziell für Telekom- Anwendungen entwickelte Option (IrMC), welche u.a. für Voice over IrDA (Real Time Voice and Call Control, RTCON) verwendet wird. Der OBEX Standard wird auch bei Bluetooth verwendet. IrTRAN-P - ein Transferprogramm für digitale Kameras Für digitale Kameras, Fotodrucker u.ä. wird heute IrTRAN-P verwendet. Dieses Protokoll wurde u.a. von CASIO, SHARP, SONY vorgeschlagen. Für zukünftige Entwicklungen wird dafür OBEX eingesetzt. IrLAN für die Netzwerkanbindung IrLAN ist eine von IBM, HP und Microsoft entwickelte IrDA Erweiterung und wurde 1997 als IrDA Standard verabschiedet. Primäre Anwendung von IrLAN ist die Anbindung mobiler PC an Büronetzwerke. Damit läßt sich besonders der temporäre Anschluß von mobilen Geräten an Firmennetze leicht realisieren. IrDA in embedded Systemen Das IrDA Protokoll ist einfach in embedded Systeme zu integrieren. Ein Betriebssystem ist nicht zwingend notwendig. IrDA ist auch für 8 Bit Prozessoren und Controller geeignet. Für einige Echtzeitbetriebssysteme (u.a. OS-9, Tornado, psos ) sind IrDA Anpassungen lieferbar. Die Codegröße für das IrDA Protokoll für FIR ist ca. 14-20 KByte. Primary Implementierungen sind ca. 3-5 KByte größer als Secundary Varianten. Eine Secundary Implementierung benötigt nur 5-6 KByte ROM und 150 Bytes RAM auf einem 8051 Prozessor. Auf einem 8 Bit Prozessor sind 115 Kbit/s ohne Probleme möglich. Für FIR Geschwindigkeiten sollte eine 16 Bit CPU eingesetzt werden. Es ist zu berücksichtigen, daß wenn keine IR Datenübertragung läuft, das IrDA Protokoll keine CPU Rechenzeit benötigt.
Bluetooth Entwicklung Bluetooth geht auf Vorentwicklungen bei Firma Ericsson zurück. Anfang 1998 wurde die Buetooth Special Interest Group von Ericsson, IBM, Intel, Nokia und Toshiba gegründet. Ende 1999 hatte die Bluetooth Organisation über 1000 Mitglieder. Die Spezifikation 1.0 wurde im Sommer 1999 veröffentlicht. Bluetooth ist eine Technologie für eine Funkverbindung von mobilen Geräten (mobile Telefone, PDA usw.) untereinander mit dem PC und die Anbindung von Peripherie an den PC. Systemarchitektur Bluetooth arbeitet im IMS (Industrial, Scientific und Medical) Band bei 2,4GHz. Zwischen den Teilnehmern wird eine Funkverbindung aufgebaut. Es sind Punkt-zu-Punkt und Punkt-zu-Multipunkt Verbindungen möglich. Bis zu 8 Bluetooth Geräte bilden ein Piconet. Alle Geräte bis auf den Master sind in einem Piconet gleichberechtigt. Die Teilnehmer von bis zu 10 Piconets können untereinander in Kontakt treten. Mehrere Piconets nennt man auch ein Scatternet. S. Bild 3 3 1 2 Piconet 1 Piconet 2 Piconet 3 2 1 3 1 2 Der Initiator der ersten Verbindung übernimmt dabei eine Masterfunktion für die Kommunikation, d.h. er verwaltet die Adressen (48 Bit) und versendet Signale für die Synchronisierung. Die anderen Geräte arbeiten dann als Slave. Jedes Bluetooth Gerät besteht aus dem HF Teil mit Sender/Empfänger und einem Prozessor mit der Rechnerschnittstelle. Bluetooth unterstützt einen asynchronen Kanal, bis zu 3 synchrone Kanäle für Sprache oder einen Kanal mit asynchronen und synchronen Daten bzw. Sprache. Die Datenübertragung verwendet Time Division Duplex (TDD) für den Full-Duplex Betrieb und Links(Übertragungskanäle). Es gibt Asynchrone Connection-less (ACL) und Synchrone Connection-oriented (SCO) Links. Jeder Link kann bis zu 16 Pakettypen unterstützen Asynchron Übertragung: Dabei stehen max. 7 Kanäle/Piconet zur Verfügung. Die Daten werden mit 432,6 Kbit/s in beide Richtungen übertragen. Die Übertragung ist symmetrisch und asymmetrisch. Synchron Übertragung: Hier stehen 3 Kanäle pro Piconet zur Verfügung. Sprachübertragung ist mit kodierten Continously Variable Slop Delta (CVSD) Signalen (64 Kbit/s) möglich. Dabei wird die Bandbreite über die Synchronous Connection Oriented (SCO) angefordert und verwaltet. Die Übertragung ist symmetrisch und erfolgt mit 721 Kbit/s, für den Rückkanal 57,6 Kbit/s.
Die Kommunikation läuft wie folgt ab: 1. Wenn die Geräte eingeschaltet sind, befinden diese sich im Standby Mode. Hier wird alle 1,28 Sekunden überprüft, ob Nachrichten anliegen. Dabei werden 32 Frequenzsprünge auf Daten für diese Station überprüft. Stationen in diesem State sind nicht im Piconet verbunden. 2. Die Station, welche als erste eine Verbindung aufbaut, ist der Master. Die andere/n Station/en ist/ sind Slave/s. Der Verbindungsaufbau erfolgt durch das Senden einer Page (MAC Adresse ist bekannt) Nachricht auf 16 bzw. 32 Frequenzsprüngen oder einer Inquiry (MAC Adresse ist nicht bekannt und wird erst ermittelt) Nachricht an alle Stationen. Die maximale Verzögerung bevor der Master einen Slave erreicht, beträgt 2,56 Sekunden. 3. Danach befindet sich die Station im State Connected. 4. Nach Empfang der Nachricht wird Detach gesendet und der Empfänger geht in Standby Mode. Bild 4 zeigt die Übergänge zwischen den einzelnen States. Standby Page Connected Inquiry Park Sniff Hold Um Strom zu sparen, können Stationen, die nicht Senden oder Empfangen, in verschiedene Zustände wechseln. Diese Zustände sind in der Reihenfolge ihres Energieverbrauchs (abfallend): Sniff: hier wird in periodischen Abständen die Schnittstelle auf Übertragungen überprüft. Hold: Slaves wechseln - vom Master oder sich selbst veranlaßt in diesen Zustand. MAC Adresse bleibt erhalten. Park: Stationen nehmen nicht an der Kommunikation teil. Die MAC Adresse wird zurückgegeben. Der Verkehr des Master wird aber für Synchronisationszwecke aufgenommen. Broadcast Nachrichten werden erkannt und verarbeitet. Physical Layer und Hardware Der Bluetooth Sender arbeitet bei 2,402 bis 2,48 GHz mit einem Frequenzsprungverfahren (Frequence Hopping) und verwendet maximal 1600 Frequenzsprünge (Hops) in der Sekunde. Dabei wird zwischen 79 Frequenzstufen im 1 MHz Abstand gesprungen. Als Modulation wird GFSK (Gauss Frequency Shift Keying) mit einem Index von 0,28 bis 0,35 verwendet. Mit diesem Verfahren werden Interferenzen und Störungen (Mikrowellengeräte arbeiten bei ca. 2,45 GHz) vermieden. Bei jedem Sprung wird ein Datenpaket mit 1 Mbit/s (Daten und Steuersignale) übertragen. Die Bluetooth Geräte werden durch eine 3 Bit MAC Adresse eindeutig unterschieden. Für den Empfang von Daten muß der Empfänger mit dem Sender synchronisiert sein, d.h. er muß die gleiche Sprungfolge verwenden. Bild 5 zeigt das Frequenzsprungverfahren von Bluetooth.
Frequenzsprünge 79. 3 2 1 Zeitslot Zeit Hinweis: für Japan, Frankreich und Spanien gilt wegen anderen Vorschriften eine andere Bandbreite! Ein Datenpaket ist mindestens ein Slot, maximal 5 Slots lang. Die Fehlerkorrektor bei der Übertragung erfolgt durch 1/3 oder 2/3 Forward Error Correction (FEC) und Automatic Repeat Request (ARQ) für die direkte Empfangsquittierung im nächsten Slot. Die Entfernung zwischen Sender und Empfänger darf bei 1mWatt zwischen 10 cm und 10 bzw. 100 Meter liegen. Bluetooth - Geräte sind je nach Sendeleistung in 3 Sendeklassen eingeteilt. Tabelle 1 zeigt die wesentlichen Merkmale des Physical Layer bei Bluetooth. Sendeleistung 0dBm (1mWatt) oder 20dBm (100mW) Offset des Sendeträgers 75 khz Empfängerempfindlichkeit -70dBm Reichweite 10 Meter (1mW), bis 100 Meter (100mW) Kanalumschaltzeit 220µs Sender/Empfänger Turnaround Zeit 220µs Bluetooth beinhaltet mehrere Protokoll - Layer. S. Bild 6 Anwendungen OBEX WAP A u d i o RFCOMM TCP/IP Logical Link Control (L2CAP) Link Manager Basisband Protokoll HF Hardware
Das Basisband Protokoll ist für das Timing, die Struktur der Pakete und Frames sowie die Steuerung der einzelnen Links zuständig. Es unterstützt Circuit und Packet-Switching. Der Verbindungsaufbau wird vom Link Manager übernommen. Dieser erkennt und kommuniziert mit anderen Geräten im Empfangsbereich über das Link Layer Protokoll und verwaltet die einzelnen States. Der Link Manager löst auch Konflikte zwischen den Slaves auf und verwaltet die Power Management States. In diesem Layer werden auch Adreßanfragen bzw. Konflikte, die Art der Datenübertragung (Daten, Audio usw.) ermittelt bzw. festgelegt und die Datenübertragung durchgeführt. Die Verwaltung der einzelnen Devices ist über einen 16 Charakter Identifier möglich. Der Logical Link Control Layer (LLC) ist für das Device Discovery (Erkennung der im Empfangsbereich vorhandenen Geräte) und das Paket Reassembly bei zerlegtem Paket zuständig. RFCOMM emuliert wie IrCOMM von IrDA eine V.24 Schnittstelle gemäß ETSI GSM 7.10. Damit können Daten zwischen drahtlosen Modems, Telefonen usw. übertragen werden, als würde eine serielle Kabelverbindung vorhanden sein. Der TCP/IP Layer ist für die Übertragung von IP Pakete über Bluetooth zuständig. Object Exchange (OBEX) ist die Filetransferanwendung für Bluetooth. OBEX für Bluetooth ist identisch zu OBEX für IrDA. Audio Daten bei Bluetooth können auch direkt an das Basisband Protokoll übergeben werden. Bei Bluetooth sind Profile genormt. Diese definieren für bestimmte Anwendungen (z.b. Filetransfer, Synchronisation, Telefon, Headset usw.) das Verhalten zur Anwendung bzw. den einzusetzenden Protokollumfang. Vorgegebene Schnittstellen bzw. ein definiertes Verhalten erleichtern eine schnelle Verbindungsaufnahme zwischen Geräten mit gleichem Profile. Die Geräte erkennen bereits bei der Aufname der Verbindung welchen Dienst die Gegenstation erwartet bzw. anbieten kann. Für Security-Funktionen werden 2 Klassen von Devices unterstützt: - persönliche Geräte (Trusted) und andere Geräte (Untrusted) Dabei sind verschiedene Security Level (Authorisation, Authentication und Encryption) definiert. Die Stufen (One-Way, Two-Way oder keine) der Authentication sind einstellbar. Authentication unterstützt auch das Anlegen einer trusted Domain für die Kommunikation zwischen bekannten Geräten, z.b. zwischen dem eigenen Telefon und dem eigenen PC. Die Encryption arbeitet mit den Schlüssellängen 0 (keinen Encryption) bis 128 Bit. Für jeden Link wird ein anderer Schlüssel verwendet. Aus heutiger Sicht kann die Übertragung bei Bluetooth als sicher gelten. Bluetooth und embedded Systeme Fertige Funkmodule mit integriertem Host-Controller lassen sich leicht an bereits vorhandene Systeme anschließen. Das Protokoll wird auf der Host-CPU implementiert. Empfohlen werden 32 Bit bzw. leistungsfähige 16 Bit CPU s. Ein kompletter Protokollstack benötigt ca. 40 Kbyte Code. In jedem Fall sollte RFCOMM integriert werden. Bluetooth versus IrDA Häufig wird die Frage gestellt ob Bluetooth die IrDA Schnittstelle ablöst. Davon ist nicht auszugehen. Das IrDA Verfahren bedingt, daß beide Teilnehmer von der Datenübertragung Kenntnis haben. Diese Art der Anwendung und der Verzicht auf einen HF-Sender bietet für viele Anwendungen Vorteile. Ein großer Unterschied zwischen beiden Systemen ist die Übertragungsrate. Bei Bluetooth sind es 1 Mbit/s, bei IrDA bis zu 16Mbit/s. IrDA und Bluetooth werden sich als Kommunikationsmethoden für den Nahbereich ergänzen. Viele Anwendungsprofile werden die eine oder andere Variante der Übertragung bevorzugen. Anfangs dürfte auch der Preis von Bluetooth für viele Anwendungen zu teuer sein.
Universal Serial Bus (USB) Entwicklung USB geht auf Vorschläge und Entwicklungen von Compaq, IBM, Intel, Microsoft, NEC und Northern Telecom (NT) zurück. Besonders NT hat Entwicklungen für den Anschluß eines Telefons an ein PC durchgeführt. Ziel von USB ist insbesondere der leichte und unproblematische Anschluß von Peripherie an den PC (Plug and Play). Leistungsfähigere Peripherie verlangte auch nach einem schnelleren Interface zum PC. Bei USB und insbesondere bei dem Einsatz eines embedded Systems als USB Host, sollte man berücksichtigen, daß die Entwicklung bei USB auf den PC und nur auf den PC ausgerichtet ist. Alle Standards werden nur im Hinblick auf den PC ausgelegt. Der PC und nur der PC definiert die Merkmale und das Verhalten des USB und von USB Host und Device. Aktuell ist die Version 1.0. In Vorbereitung ist 2.0 mit höheren Geschwindigkeiten (120 bis 240 Mbit/s), erweiterten Power-Management und einer Zertifizierung für USB 2.0 Geräte. Architektur. Ein USB System besteht immer aus einem Host (in der Regel dem PC) und bis zu 127 Devices (Geräten die am USB angeschlossen werden können). Laut USB Spezifikation ist der USB ein Bus für den Anschluß von Peripherie an den PC. Auf andere Systeme wird mit keinem Wort eingegangen! Somit stellt sich die Frage was embedded Systeme mit dem USB gemeinsam haben. Für Devices ist die Frage leicht zu beantworten. USB Peripherie (Modems, Drucker, Scanner, Kameras usw.) können als embedded Systeme mit z.t. sehr leistungsfähigen Prozessoren (CPU, DSP) betrachtet werden. Ein USB Host an einem embedded System ist ein Sonderfall! Im Unterschied zu PCI u.ä. benötigt der USB im Host keinen I/O Adreßraum und auch keine IRQ. Die Devices sind am Host sternförmig, u.u. über einen Hub angeschlossen. Hubs dienen zur Erweiterung der Anzahl der verfügbaren Ports und für das Power Management. Die maximale Entfernung zwischen Host und Device bzw. zwischen Hub und Device darf nicht mehr als 5 Meter betragen. Dabei dürfen maximal 5 Hubs zwischen Host und einem Device liegen. USB ist sehr Host zentrisch, d.h. nur der Host veranlaßt eine Datenübertragung (niemals ein Device oder ein Hub).Der USB unterstützt Hot-Swap, d.h. im Betrieb können Device am Bus angeschlossen oder vom Bus entfernt werden. Die Devices werden dabei automatisch erkannt. Zusammen mit den Daten wird auch der Clock übertragen. Die Datenübertragung erfolgt mit Bit-Stuffing. Devices können auch über den USB mit Spannung (5 Volt, max. 500mA) versorgt werden. USB besitzt dabei umfangreiche Power Management Funktionen. Devices können dabei auch in einen Suspend Mode versetzt werden. In diesem Mode nehmen die beteiligten Geräte noch Spannung auf (5V, max. 500µA), nehmen aber an der Kommunikation nicht teil. Für die Stromversorgung der Devices, Spannungsabfälle und die erlaubten Kabel gelten die (umfangreichen) Vorschriften des USB. Trotzdem sind im Handel Kabel erhältlich, die lt. USB Spezifikation nicht zulässig sind. Fehlerkorrektur wird durch eine robuste Übertragung auf dem Physical Layer (Kabel mit einem Schutzschirm, NRZI kodierte Differenzsignale D+/D- mit einem Pegel zwischen 0,3 und 3,3 Volt), CRC für Daten und Kontrollsignale und die Erkennung von fehlenden oder verloren gegangenen Paketen gewährleistet. Die Bit-Error-Rate (BER) ist kleiner 10-10. USB unterstützt 2 Geschwindigkeiten; Low-Speed mit 1,5 Mbit/s und Full-Speed mit 12 Mbit/s. Dabei wird die Bandbreite für bestimmte Anwendungen vergeben. Bild 7 zeigt die USB Architektur
Host (PC oder embedded System) Root Hub Hub Device Device Compound Device Device Hub Device Kommunikation auf dem USB Host und Device kommunizieren über Pipes (logischer Kanal) miteinander. Für jede Pipe sind Endpoints im Host bzw. Devices vorhanden. Endpoints haben eine FIFO Struktur und sind mit der Anwendung im Host bzw. Device verbunden. Low-Speed Devices haben maximal 4 Endpoints, High-Speed Devices max. 15 für jede Richtung (IN/OUT). Alle Devices müssen den Endpoint 0 unterstützen. Pipes werden in Message-Pipes (für eine durch USB definierte Datenstruktur wie Kontrollinformationen) und Stream-Pipes (keinen durch USB definierte Struktur wie Daten) unterteilt. Die Übertragung der Daten erfolgt asynchron oder isochron (konstante Bandbreite) mit verschiedenen Transfers. Diese sind unterteilt in: - Control-Transfers für die Konfiguration von Devices. Paketgröße ist 8, 16, 32 oder 64 Byte. Bidirektionale Transfervariante. - Interrupt-Transfers für kleine Datenpakete mit geringer Häufigkeit (Beispiel: Maus). Unidirektionale Transfervariante. Im Fehlerfall werden die Daten noch einmal gesendet. Paketgröße ist maximal 8 Bytes für Low-Speed und 64 Byte für Full-Speed Devices. - Bulk-Transfers für große Datenmengen und nicht-periodische Übertragung. Dieser Transfer wird für Anwendungen verwendet die keine bestimmte Bandbreite benötigen und deren Daten auch verzögert gesendet werden können (Beispiel: Drucker). Paketgröße ist 8,16,32 oder 64 Byte. - Isochrone-Transfers für periodische und kontinuierliche Übertragung von zeitkritischen Daten wie Audio und Video. Uni-direktionale Transfervariante mit geringer Verzögerung. Paketgröße ist maximal 1023 Bytes. Bei den einzelnen Transfers werden die zu übertragenden Daten in verschiedene Pakete (Token, Daten, Handshake und Special) verpackt und versendet. Alle Pakete werden in Frames übertragen. Devices Die Funktionalität von Devices ist in der USB Spezifikation sehr genau definiert. Devices werden u.a. durch die Geschwindigkeit (Low-Speed bzw. High-Speed), die Art der durch Endpoints und Pipes definierten Transfers und durch die Spezifikation von Klassen definiert. Devices werden in Klassen eingeteilt. definierte Klassen sind u.a. Human Interface Devices (HID), Audio, Communication, Mass-Storage, Monitor, Printer und USB/IrDA. Devices können eine eigene Stromversorgung (Self-Powered) besitzen oder aber vom USB versorgt (Bus-Powered) werden. Die Arbeitsweise und die Device-States sind aber für alle Devices praktisch identisch. Neue am USB angeschlossene Devices werden durch den Vorgang der Enumeration erkannt.
Dabei werden vom Device nacheinander die States Powered und Reset durchlaufen. Das Device ergibt sich dann mit der Default-Adresse 0 zu erkennen. Das Device wird dann konfiguriert. Mit der Konfiguration (für Device, USB-Konfiguration und Function/Class) werden u.a. die Klasse, Anzahl der Endpoints, die Device-Adresse, Datenaufkommen, Frames, Art der Stromversorgung usw. festgelegt. Danach kann das Device auf Requests (Anforderung für Senden oder Empfangen) vom Host reagieren. Devices können mehrere Konfigurationen, aber nie mehr als eine zur gleichen Zeit, besitzen. Die Kommunikation zwischen Device und Host läuft auf den jeweiligen Ebenen ab. Dabei kommunizieren die einzelnen Schichten (z.b. Firmware für Klassen mit WDM Treiber) direkt miteinander. Dabei ist zu beachten: die Vorteile von Plug-and-Play und die Verwendung der Windows USB Device-Treiber werden nur bei völlig korrekter Konfiguration und vollständiger Klassenspezifikation erreicht. Der USB definiert auch die Anforderungen an das Timing innerhalb des Devices (z.b. Reaktionszeiten auf einen Request). Die Software im Device wird häufig unterschätzt. Nach erfolgter Implementierung der Device-Firmware inkl. Klassendefinition muß das Device konfiguriert werden und die FIFO müssen gefüllt bzw. ausgelesen werden. Viele USB Controller sind 8 Bit Devices die neben der Bearbeitung des USB auch für die Anwendung eingesetzt werden können. Für Devices mit umfangreichen Funktionen wird ein 16 Bit Controller/CPU empfohlen. Komplexere Devices verwenden auch eine 32 Bit RISC CPU, die den USB Controller steuert (Data-Pump Modell). Bild 8 zeigt die USB Host/Device-Architektur Anwendungen WDM USB Device Treiber USBD/USBHUB OHCI/UHCI Class Spezifikation Device Device Firmware USB Interface Firmware USB Host Controller USB Kabel USB Device C. Host Vollständige USB Host-Implementierungen mit den genannten Vorteilen von Plug-and- Play und universellen Device-Treibern sind z.zt. nur für Windows98 (Apple und Linux mit einigen Einschränkungen) erhältlich. Anm. Die USB Host-Funktionalität ist in der Spezifikation mit ca. 18 Seiten definiert! Der Host ist in einem USB System der zentrale Koordinator. Jeder Datentransfer wird immer vom Host veranlaßt oder geht zum oder über den Host. Der Host agiert auch als zentrale Timer auf dem USB. Er sendet jede Millisekunde ein Start-of-Frame (SOF) Token auf dem USB.
Der USBD Treiber stellt die I/O Request Pakete (IRP) mit Angabe der Pipe für die Datenübertragung auf dem USB bereit. Die Anwendung verwendet den USBD zum Versenden oder Empfangen von Daten. Der Host übernimmt im einzelnen folgende Aufgaben: - Erkennung von Anschluß/Entfernung von Devices inkl. Remote Wakeup - Verwaltung der Kontrollinformationen von Devices - Steuerung der elektrischen Interfaces zwischen Host und Device bzw. Hub - Fehlerbearbeitung (Timeouts, CRC-Fehler, Protokollfehler) - Root Hub-Funktion Der Host prüft z.b. auch ob der USB die entsprechende Bandbreite unterstützen kann. Dafür muß er entsprechende Berechnungen anstellen. Die Parameter dafür sind abhängig von der jeweiligen Bus-Topologie. Parameter für die Signalverzögerung (Anzahl der Hubs, Kabel usw.) gehen in diese Rechnung mit ein. Die Host-Implementierung bestimmt die Grundlast des Systems und die erreichbaren Verzögerungszeiten bzw. den Datendurchsatz. USB Host in einem embedded System Der Einsatz einer Host-Funktionalität in einem embedded System ist eine besondere Herausforderung. Die Hostfunktionalität läßt sich im Prinzip nur aus der Spezifikation von USB, von Devices und Hubs bzw. dem Verhalten des PC ableiten. Besonders PC-Peripherie verfügt über Funktionen, die bei einem Anschluß an einen PC/USB-Host kaum mit vertretbaren Aufwand zu realisieren sind. Wenn man das berücksichtigt, lassen sich trotzdem sinnvoll USB Hosts in einem embedded System ohne Windows/PC-Architektur realisieren. Gute Beispiele für embedded Systeme mit USB Host-Funktionalität sind Anwendungen für die Datenaufnahme, aber auch HID-Devices, Kameras und Drucker. Besonders bei letzteren wird in einer typischen embedded Anwendung sicher kein identischer Benutzerkomfort wie in einer Büroumgebung mit Windows und Office-Anwendungen gefordert. Wesentlich ist hier die Nutzung preisgünstiger und leistungsfähiger Peripherie (Drucker, Modems, Massenspeicher u.a.) für embedded Systeme. Der PowerPC MPC823 von Motorola bietet eine gute Hardware-Plattform für USB Host- Implementierung. Von einer Codegröße von ca. 300 KByte sollte man bei einer Minimalimplementierung für einen USB Host ausgehen. Hub Die Funktion eines Hub ist besonders für Systeme mit mehr als 2 USB Devices am Host von Bedeutung. Der Hub stellt mehr Ports (typisch sind 4) zur Verfügung. Hubs können auch hintereinander geschaltet werden. Hubs mit einer Device-Funktion (z.b. mit einem Keyboard) nennt man Compound-Devices. Der Port in Richtung Hub ist der Upstream-Port, in Richtung der Devices der Downstream-Ports. Hubs führen einen eigenen Timer und synchronisieren diesen mit der SOF Periode (1 Millisekunde) die vom Host gesendet wird. Die Performance eines USB Systems mit Hubs ist u.a. auch von der Host-Implementierung abhängig. Hubs erkennen auch die Geschwindigkeit der angeschlossenen Devices und ob Kollisionen im Datentransfer vorliegen. Suspend und Resume von Devices wird auch von Hubs unterstützt. Die Konfiguration des Hub (Deskriptoren) wird vom Host übernommen. Zertifizierung Um eine Verträglichkeit mit den Devices anderer Hersteller garantieren zu können, wird die Teilnahme an den Plug-Fest empfohlen. Dabei wird das Zusammenspiel verschiedener Geräte in unterschiedlichen Systemen/Topologien überprüft. Die Erfahrung mit bereits am Markt erhältlichen Geräten hat die Notwendigkeit solcher Tests gezeigt. USB 2.0 wird in dieser Hinsicht neue Anforderungen stellen.
IEEE1394 (Firewire) Entwicklung und Standard Erste Entwicklungen begannen bereits 1988 bei Apple. Ziel war die Entwicklung eines seriellen Hochgeschwindigkeitsbusses als Ersatz für SCSI. Das IEEE stellte im Jahre 1995 den IEEE 1394-1995 vor. Dieser Standard basierte auf den Entwicklungen von Apple. In letzter Zeit wurde der IEEE1394 auch unter dem Markennamen ilink von SONY bekannt. Ergebnis dieser Entwicklungen war ein serieller Low-Cost Hochgeschwindigkeitsbus mit skalierbarer Performance und Echtzeitübertragung. Weitere Merkmale sind: - Plug and Play (Hot Plug-In, dynamisch konfigurierbar) - Unterstützung isochroner Anwendungen - großer Adressierungsbereich - Multi-Master Support - unabhängig vom Betriebssystem - für neue Anwendungen im Videobereich - Bridge-Funktionen (z.b. 1394/PCI) - serielle und Backplane Varianten Der IEEE1394 wurde auf der Anwendungsebene weiterentwickelt und bietet eine neue Art der High-Speed Verbindung von verschiedenen Geräten der Konsumerelektronik aber auch der Industrieautomatisierung, Bild/Videotechnik und Medizintechnik. Der IEEE1394 basiert auch auf anderen Spezifikationen. Grundlage von IEEE1394 ist auch ISO/IEC 13213 (ANSI/IEEE 1212) Microprocessor Systems - Control and Status Register (CSR) Architektur für die Definierung der Control-Register. Zusätzliche Spezifikation sind IEEE 1394-1995, IEEE 1394a (Ergänzung und Update), IEEE 1394b (Erweiterung und andere physical Layer), IEEE 1394.1 (Bridge), IEEE 1394.2 (bis 4,8 Gbit/s), die Anwendungsprotokolle: DPP, SBP2, AV/C, IP über 1394, HAVI, mlan & Instrumentation (Ersatz für IEEE488) und die OHCI Spezifikation. Die VESA Organisation standardisierte IEEE1394b auch für Anwendung im privaten Bereich (Home-Network) mit Kabel bzw. Fiberoptik als Medium. Architektur Bestandteile eines IEEE 1394 Systems sind Module (z.b. eine Videokamera, PC) und Nodes (IEEE1394 Anschluß). Module bestehen aus einem oder mehreren Nodes. Alle Nodes bei IEEE1394 sind praktisch gleichberechtigt. Sie können untereinander kommunizieren. Ein Node kann einen oder mehrere Ports besitzen. Ein Node mit mehreren Ports erlaubt eine Verlängerung bzw. Erweiterung der Topologie. Die Verbindung ist immer Point-to-Point, d.h. ein Port empfängt ein Paket, synchronisiert es und sendet es über die anderen Ports des Nodes wieder auf den Bus. Er arbeitet damit als Repeater. Zwischen 2 Nodes dürfen sich maximal 16 Hops (andere Nodes) befinden. Ein IEEE Bus hat maximal 64 Nodes. Die maximale Entfernung zwischen 2 Nodes beträgt 4,5 Meter. Die maximale Länge der Verbindung zwischen 2 Nodes beträgt damit 72 Meter. Die Übertragungsgeschwindigkeiten sind 100/200 und 400 Mbit/s. In Vorbereitung sind 800 Mbit/s/, 1.6/3.2 Gbit/s (andere Codierung auf dem Physical Layer ist notwendig!). Die Daten können asynchron (garantierte Lieferung, Zuverlässigkeit des Transfers, Wiederholungen sind möglich) oder isochron (garantiertes Zeitverhalten, keine Wiederholungen möglich) gesendet werden. Die Adressierung der Nodes erfolgt mit 64 Bit Adressen. Der Adreßraum ist auf 64k Nodes aufgeteilt. 64 Nodes sind zu einem Bus zusammengefaßt. Insgesamt sind in einer IEEE1394 Umgebung 1024 Busse möglich. Jeder Node hat einen 256 TByte Adreßraum. Teile des Adreßbereichs werden für Systemstrukturen des IEEE1394 reserviert. Während der Initialisierung identifiziert der Bus seine jeweilige Topologie (Tree-Identifikation).
Bild 9 Architektur eines IEEE1394 Nodes Signale, Signalisierung, Kabel und Power-Management Die Daten werden gemäß NRZ (Non Return To Zero) mit einem Strobe-Signal und Data- Tx/Data_Rx übertragen. Wenn 2 NRZ Datenbits identisch sind, wird das Strobe-Signal gewechselt. Die Signalwandlung wird komplett in Hardware (PHY-Layer Chips) durchgeführt. Durch die Datenleitungen erfolgt die Signalisierung wenn ein Device mit dem bzw. vom Bus verbunden oder entfernt wurde, ein Reset ausgelöst wurde, die Arbitrierung, die Konfiguration, die Anzeige der Geschwindigkeit und Suspend/Resume Operationen. Dafür werden Gleichspannungssignale verwendet. Anm.: Die maximale Geschwindigkeit zwischen 2 Nodes ist gleich der niedrigsten in der Übertragungsstrecke zwischen diesen. Es gibt 2 Arten von Kabel/Stecker. Eine 6-polige Variante und eine 4-polige Variante (wird nicht für Computerperipherie verwendet). Die Kabel müssen über eine gute Schirmung verfügen. Bei den Nodes wird unterschieden zwischen Nodes, die den Bus mit Spannung versorgen (Power Provider und Alternate Power Provider), solchen die Spannung vom Bus erhalten (Power Consumer) und Nodes die eine eigene (Self-Powered) Spannungsversorgung haben. Power Provider liefern max. 1.5A, bei 20V (8V) bis maximal 33V. Alternate Power Provider liefern weniger Spannung, sie können auch Power vom Bus nehmen (PHY bleibt aktiv). Nodes die mit Spannung versorgt werden müssen (Power Consumer), haben Kabel/Stecker mit 6 Kontakten (nur Single-Port Module sind zulässig). Wenn bei Self-Power Nodes die Spannung ausfällt, wird der PHY diese Nodes vom Bus mit Spannung versorgt. Node-Informationen Jeder IEEE1394 Node wird durch ein Control and Status Register (CSR) konfiguriert. Pro Node müssen dabei 14 CSR (mindestens 5) gesetzt werden. Mit den CSR wird die Behandlung von Power-Fail, Error-Logging, automatische Konfiguration und die Beseitigung von Übertragungsfehlern auf dem Bus und das Configuration ROM definiert. Für die Initialisierung des Busses werden die Einträge des Konfiguration ROM verwendet. Die ROM Datenstrukturen werden von Devicetreibern und dem Bus-Management verwendet. Es muß mindestens die 24 Bit Hersteller-ID definiert sein. Zusätzliche Parameter sind: Bus Information Block und Root Directory Informationen.
Datenübertragung Die Übertragung von Daten auf dem IEEE1394 wird als Transaction bezeichnet. Dabei wird mit Request und Response (asynchrone Transactions) bzw. nur mit Request (isochrone Transactions) gearbeitet. Der Empfang von asynchronen Paketen wird bestätigt. Der Requester Node überträgt die Adresse, Kommandos und Daten (Write & Lock) zum Responder. Der Responder gibt Informationen über den Status oder sendet Daten (Read & Lock) an den Requester. Locked Transactions werden für Read-Modify-Write Operationen verwendet. Dafür wird kein Bus- Lock Signal verwendet. Bei Synchrone Transaction werden die Daten in konstanter Rate in einem 125µsec Intervall über den Bus geliefert. Es wird keine Bestätigung (Response) über den Empfang der Daten gesendet (Beispiel: Audio). Synchrone Transactions arbeiten daher nur mit Request. Requester ist isochroner Talker, Responder ist isochroner Listener. Auf dem Bus werden die Daten in Paketen übertragen. Bei asynchronen Paketen folgt auf ein Request-Paket immer ein Acknowledge-Paket. Die Daten können zum Target-Node gesendet werden (asynchrones Schreiben) oder von dort gelesen werden (asynchrones Lesen). Asynchrone Pakete enthalten u.a. Destination-Adresse, Source-ID, die Daten, Transaction- Type, Transaction-Label, Response-Code, CRC und den Acknowlege-Code als Empfangsbestätigung.Transactions bei mit isochronen Paketen sind unidrektional. Die Daten werden nur vom Requester gesendet. Es wird kein Acknowledge-Paket und kein Response- Paket vom Target-Node übertragen. Isochrone Pakete enthalten u.a. Channel-Number, Transaction-Type, die Daten und eine CRC. Die Bandbreite des IEEE1394 wird durch Arbitrierung vergeben. Dabei werden für isochrone Kanäle eine Bandbreite (max. 80%) garantiert, für asynchrone Kanäle wird diese durch ein Fairness-Intervall sichergestellt. Bus Management Layer Für die Verwaltung des Busses existiert ein eigener Layer. Die Implementierung des Bus Managements ist abhängig vom Node. Alle Nodes müssen die automatische Buskonfiguration unterstützen. Einige Nodes können auch globales Bus Management anbieten. Dabei wird die Arbeit einer Gruppe von Nodes aufeinander abgestimmt. Funktionen des globalen Bus Managements (GBM) sind die Vergabe der Bandbreite und Kanalnummer, Kontrolle des Intervalls zwischen isochronen Transactions, Kontrolle der Power, Meldung über unterstützte Geschwindigkeiten an andere Nodes und Cycle-Master. IEEE 1394 definiert auch einen Satz von Servicefunktionen für die Übergabe von Parameter zwischen den Layern. Mit diesen Services (SVC) wird die Transaction in einem IEEE 1394 System gestartet und abgewickelt. Anwendungen auf dem IEEE1394 Ein effektiver Einsatz des IEEE1394 ist eigentlich nur mit den Anwendungsprotokollen möglich. Direct Print Protocol (DPP) ist für die direkte Ausgabe eines Auftrages zum Drucken von z.b. einer Kamera an den Drucker. Ein PC ist dazu nicht notwendig. Es besteht eine Punkt-zu- Punkt Verbindung. Serial Bus Protocol (SBP-2) Protokoll ist für die Übertragung von Kommandos, Statusinformationen und Daten. Arbeitet mit Target und Initiator Mode. Agents auf dem Target übernehmen die Ausführung von Kommandos und Requests. SBP-2 unterstützt DMA und besitzt eine geringe Interrupt-Last. Durchsatz: 40 MByte (kontinuierlich!). Einsatz bei Scannern, Druckern und Massenspeichern.
IP over 1394 ist ein relativ neues Protokoll. Die Normung dafür wurde im Dezember 1999 abgeschlossen. Damit ist die Übertragung von IP-Paketen für FTP, Telnet, Browser u.ä. über 1394 möglich. Temporäre Netzwerkadressen können vergeben werden (DHCP). IP over 1394 unterstützt IP-Unicast, IP-Broadcast und IP-Multicast, 1394 Link Encapsulation und Fragmentierung. Das Instrument and Industrial Control Protocol (IIP) wird als Ersatz von GPIB (IEEE488) in Meßgeräten vorgesehen. Ein sehr wichtiges Protokoll ist Audio/Video Control (AV/C). Dieses Protokoll definiert den Austausch zwischen Audio/Video Geräten wie Fernsehgeräte, Videorecorder, digitale Kameras, DVB-Geräte, STB u.ä. In Zukunft wird auch das Home Audio Video Inteface (HAVI), ein verteiltes Objektsystem für die Konsumerelektronik, an Bedeutung gewinnen. IEEE1394 und embedded Systeme Für die Konsumerelektronik und Anwendungen in der Bild- bzw. Videobearbeitung ist der IEEE1394 in Zukunft unverzichtbar. Da der PHY- und Link-Layer in Hardware realisiert wird, sind die Anforderungen an die eingesetzten CPUs nicht sehr hoch. Eine 16 Bit CPU sollte jedoch das Minimum sein. Einfache Datenübertragung kann mit asynchronen Transactions durchgeführt werden. Diese Funktion benötigt ca. 15-20 Kbyte Code. Isochrone Funktionen sind aufwendiger. Diese Funktionen lassen sich nur in sehr umfangreichen State- Maschinen realisieren. Der Aufwand ist erheblich. Anwendungen wie AV/C bzw. IP over 1394 sind sehr umfangreich. Eine IP over 1394 Implementierung benötigt ca. 30-35 Kbyte Code. Dafür sollten nur 32 Bit CPU s eingesetzt werden. Tabelle 2 vergleicht die besprochenen Interfaces. Dabei wird auch HomeRF mit einbezogen. HomeRF wird u.a. von Intel und Microsoft unterstützt. Referenzen - USB Design by Example von J.Hyede, Intel University Press - USB Hardware & Software von J. Garney u.a., Annabooks - USB System Architecture von D. Anderson, Mindshare - Firewire System Architecture von D. Anderson, Mindshare WWW Adressen: - www.irda.org - www.usb.org - www.1394ta.com - www.bluetooth.com - www.homerf.org ARS Software GmbH Starnberger Str. 22 82131 GAUTING/München Telefon: 089-893 41 30 Telefax: 089 893 41 310 Email: rlatuske@ars2000.com http://www.ars2000.com
Datenrate Architektur Kommunik. USB IEEE1394 IrDA Bluetooth HomeRF 1,5&12 Mbit/s bei USB 1.0 120-240 Mbit/s bei USB 2.0 Host (Master) zu Devices 100,200,400, 800 Mbit/s, in Zukunft 1,6/3,2 Gbit/s Node zu Node SIR: bis 115,2 Kbit/s MIR: 0,576 & 1,152 Mbit/s FIR:4 Mbit/s VFIR:16Mbit/s Station zu Station Asynchron: 432,6 Kbit/s (beide Richt.), 721 Kbit/s eine Richtung) Synchron: 64kbit/s Node zu Node (SWAP) ~ 1 Mbit/s in Jahr 2001: 5 Mbit/s Host (Master) zu Device Struktur Master Sternnetz Master (Host) Node Bus Nodes haben gleiche Rechte Teilnehmer Bis 127 64 pro Bus 1024 Busse sind möglich Medium Kabel mit 4 Adern, Power über Kabel Reichweite Daten Anwendung 5 Meter pro Segment, maximal 30m zwischen Host und Device Daten, Audio, Video PC Peripherie (inkl. Kameras, Modems usw.) Datenaufnahme Kabel mit 4 oder 6 Adern, Power über Kabel 4,5 Meter pro Segment, maximal 72m zwischen 2 Nodes Daten, Audio, Video TV, STB, DVB, VCR, digitale Kameras, High-Speed Video, High-Speed Datenübertrag. (asynchron) Punkt-zu-Punkt Primary & Secondary (nur Drucker u.ä.) Punkt-zu-Punkt Punkt-zu-Multi Punkt Sternnetz Master (Host) Node Nodes haben gleiche Rechte 2 (gleichzeitig) 7 gleichzeitig Bis 127 Infrarotstrahl Strahlwinkel bis +/- 15 und 30 Grad 1-2 Meter Strahlwinkel, Sichtverbind. Ist notwendig Daten Sprache mit RTCON Mobiltelefone, PDA, Kameras, Multimedia, Medizintechnik und mobile Datenerfassung Funk 2,4 GHz 1600 Hops/sec Standard bis 10 Meter, Option: bis 100 Meter Daten, Audio, Video i.z. (?) Mobiltelefone, PDA, Multimedia, und mobile Datenerfassung Schwerpunkt auf kommerzielle Nutzung Funk, 2,4 GHz 50 Hops/sec 50 Meter Daten, Audio 6 Audiokanäle gleichzeitig Steuerung von Geräten im Haus, Anbindung von Peripherie an den PC, mobiler Internetzugang Schwerpunkt auf privaten Einsatz Tabelle 2 Vergleich aktueller Technologien für die Vernetzung im Nahbereich