DE60106929T2

DE60106929T2 - Methode und vorrichtung zur ankopplung von single master geräten an eine multimaster wired-and busumgebung

Info

Publication number: DE60106929T2
Application number: DE60106929T
Authority: DE
Inventors: J. Joseph ERVIN; E. Jorge LACH
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 2000-08-01
Filing date: 2001-07-26
Publication date: 2005-11-10
Anticipated expiration: 2021-07-27
Also published as: US6591322B1; AU2001280768A1; ATE281667T1; DE60106929D1; WO2002010933A1; EP1305718A1; EP1305718B1

Description

BEREICH DER ERFINDUNG
Diese Erfindung bezieht sich auf Busse, die ein verdrahtetes-UND-Protokoll verwenden, und genauer gesagt auf Verfahren und Vorrichtungen zum Verbinden von Einrichtungen bzw. Geräte in einem Bussystem mit mehreren Bus-Mastern.
HINTERGRUND DER ERFINDUNG
Das I²C-Bussystem ist ein elektronischer Bus zum Übertragen von Befehlen und Daten zwischen kompatiblen, mit dem Bus verbundenen Geräten. Dieses System wurde von der Philips Semiconductor Corporation entwickelt und auf den Markt gebracht und ist im Detail in der I²C-Spezifikafion, Revision 2.0, Philips Semiconductor Corporation 1995 beschrieben.
In dem I²C-Bussystem leiten zwei Drähte, eine serielle Datenleitung (serial data, SDA) und eine serielle Taktleitung (serial clock, SCL) genannt, Informationen zwischen den mit dem Bus verbundenen Einrichtungen. Sowohl die SDA- als auch die SCL-Leitungen sind bidirektionale Leitungen, verbunden mit einer positiven Versorgungsspannung über Hochziehwiderstände wie in 1 gezeigt, um eine „verdrahtete-Und"- Konfiguration zu bilden. Zum Beispiel sind in der in 1 abgebildeten Buskonfiguration 100 die SDA-Leitung 108 und die SDL-Leitung 110 mit der V_DD-Versorgungsleitung 102 durch die Hochziehwiderstände 104 bzw. 106 verbunden. Andere Busse, die ein ähnliches Protokoll benutzen, schließen den SMBus und den Access.bus ein. Gemeinsam wird diese Art von Bussystemen als ein „verdrahtetes-UND"-Bussystem bezeichnet. Die nachfolgende Diskussion wird sich auf das I²C-Bussystem konzentrieren, wobei dies so zu verstehen ist, daß diese Diskussion auch für jene anderen Bussysteme gilt.
Während der Bus 101 frei ist, sind sowohl die SDA-Leitung 108 als auch die SDL-Leitung 110 durch die Wiederstände 104 und 106 auf einen „Hoch"-Zustand gezogen. Die Ausgabestufen mit dem Bus verbundener Einrichtungen müssen eine offene Drain oder einen offenen Kollektor haben, um die verdrahtete-UND-Konfiguration zu bilden. In 1 werden die beiden Einrichtungen 112 und 114 schematisch dargestellt. Einrichtung 112 hat eine Taktausgabestufe, die Ausgabetransistor 116 einschließt, der über die SCL-Leitung 110 und Masse 118 verbunden ist. Wenn ein Signal auf dem Gate 117 von Transistor 116 den Transistor anschaltet, zieht es die SCL-Leitung 110 auf „Niedrig". Taktsignale auf der SCL-Leitung 110 können mittels Puffer 120 erkannt werden, dessen Ausgabe die „Takt-Eingang"-Leitung 122 bildet.
In ähnlicher Art und Weise hat das Gerät 112 eine Datenausgabestufe, die Ausgabetransistor 124 einschließt, der über die SDA-Leitung 108 und Masse 126 verbunden ist. Wenn ein Signal auf dem Gate 123 von Transistor 124 den Transistor anschaltet, zieht es die SDA-Leitung 108 auf „NIEDRIG". Datensignale auf der SDA-Leitung 108 können mittels Puffer 128 erkannt werden, dessen Ausgabe die „Daten-Eingangs"-Leitung 130 bildet. Einrichtung 114 hat auch einen Taktausgabetransistor 132 und einen Takteingabepuffer 134 und einen Datenausgabetransistor 136 und einen Dateneingabepuffer 138 zur Kommunikation mit den SDA- und SCL-Leitungen 108 und 110.
Einrichtungen auf dem Bus kommunizieren durch periodisches Herunterziehen der SDA- und SCL-Leitungen auf ein NIEDRIG, was Daten und Taktimpulse auf den Leitungen 108 und 110 erzeugt. Gemäß dem I²C-Protokoll müssen die Daten auf der SDA-Leitung 108 stabil sein, wenn die Taktleitung SCL 110 HOCH ist. Daher kann sich der Zustand HOCH oder NIEDRIG der Datenleitung 108 nur dann ändern, wenn die Taktleitung 110 NIEDRIG ist. Es treten zwei besondere Situationen auf, diese Situationen sind als START- und STOP-Bedingungen definiert. Insbesondere wird der Übergang von HOCH zu NIEDRIG auf der SDA-Leitung 108 bei HOCH der SCL-Leitung 110 als eine START-Bedingung definiert. Ein Übergang von NIEDRIG zu HOCH auf der SDA-Leitung 108 bei HOCH der SCL-Leitung 110 wird als eine STOP-Bedingung definiert.
Jede Einrichtung bzw. jedes Gerät 112, 114 auf dem Bus 101 hat eine eindeutige Adresse und kann abhängig von der Funktion des Geräts entweder als Datenübermittler oder als Datenempfänger agieren. Ein LCD-Treiber ist zum Beispiel immer ein Datenempfänger, während ein Speicher Daten sowohl empfangen als auch übertragen kann. Zusätzlich dazu, daß sie Sender und Empfänger sein können, können Geräte beim Übertragen von Daten auch Busmaster oder Abhängige sein. Ein Busmaster ist die Einrichtung, die eine Datenübertragung auf dem Bus einleitet, die für den Transfer benötigten Taktsignale erzeugt und die Datenübertragung beendet. Während dieser Übertragung wird jedwede andere Einrichtung, an die Daten gesendet werden oder von der Daten empfangen werden, als abhängig betrachtet. Der Busmaster kann Daten zu einem Abhängigen übertragen oder von einem Abhängigen Daten empfangen. In beiden Fällen werden die Taktsignale von dem Busmaster erzeugt. Die Beziehungen zwischen Busmaster und Abhängigem sind nicht permanent und hängen davon ab, welche Einrichtung die Datenübertragung zu einem bestimmten Zeitpunkt eingeleitet hat.
Mehr als eine Busmastereinrichtung kann mit Bus 101 verbunden sein. Busimplementierungen mit genau einer Einrichtung, die als Busmaster agieren kann, werden Ein-Master-Busse genannt, während die mit zwei oder mehr Einrichtungen, die als Busmaster agieren können, Mehrfach-Master-Busse genannt werden. In einem Ein-Master-Bussystem ist das I²C-Protokoll sehr einfach ausgelegt, wobei jede Transaktion aus einer START-Bedingung gefolgt von einer oder mehr Adreß- und Datenphasen, gefolgt von einer STOP-Bedingung, besteht. Daher sind die START- und STOP-Bedingungen der Rahmen für alle Aktivitäten auf dem Bus und definieren dadurch die Dauer, während der der Bus belegt ist.
In einem Ein-Master-I²C-Bus tritt das einzig interessante Fehlerszenario, das überhaupt auftreten kann, dann auf, wenn eine abhängige Einrichtung auf eine Adreß- oder Datenphase mit einer Negativ-Bestätigungsantwort (negative-acknowledgement response, NAK) antwortet. Eine NAK-Antwort wird als ein HOCH-Signalniveau auf der SDA-Leitung 108 während der Bit-Bestätigungszeit dargestellt, welche als der neunte Taktimpuls jeder Adreß- oder Datenphase definiert ist. Da der I²C-Bus eine verdrahtete-UND-Konfiguration ist, entspricht eine NAK-Antwort keiner Antwort von einer abhängigen Einrichtung. Im Fall eines NAK auf eine Adreßphase kann dies anzeigen, daß die abhängige Einrichtung beschäftigt ist und nicht in der Lage ist, I²C-Transaktionen zu diesem Zeitpunkt anzunehmen, daß sie nicht funktioniert oder einfach nicht vorhanden ist.
Ein weiteres mögliches Problem mit Ein-Master-I²C-Bussystemen tritt auf, wenn abhängige Einrichtungen mit unterschiedlicher Geschwindigkeit mit dem Bus verbunden sind. In diesem Fall ist die Geschwindigkeit des Busses auf die langsamste Einrichtung begrenzt. Diesem Problem wurde begegnet, indem Einrichtungen mit unterschiedlicher Geschwindigkeit auf separaten Bussegmenten plaziert wurden, die durch verschiedene Busmaster oder durch Verbinden der separaten Bussegmente zu einem Ein-Bus-Master durch einen bidirektionalen Multiplexer mit einer Steuereinrichtung verbunden sind. Der letztgenannte Ansatz wird in U.S. Patent Nr. 5.892.933 dargestellt.
Da NAK-Bedingungen nur an genau definierten Punkten in der Transaktion auftreten und weil die Interpretation einer NAK ganz einfach bzw. naheliegend ist, ist die Antwort nicht mehrdeutig. Meistens kann die Busmaster-Software einfach entscheiden, eine Transaktion, die ein NAK empfängt, zu wiederholen. Die wichtige Beobachtung ist, daß NAK-Fehler den korrekten Betrieb des I²C-Busses selbst nicht bedrohen; sie betreffen nur Protokolle höherer Ebenen, die typischerweise in Software implementiert sind.
Mehrfachmaster-I²C-Busimplementierungen sind von drastisch höherer Komplexität. Das I²C-Protokoll ist im wesentlichen ein Schema der Trägersignalerfassung eines Mehrfachzugriffs mit Kollisionsaufdeckung (CSMA/CD), das wie ein Ethernet-System funktioniert. Anders als dem Ethernet-System fehlen dem I²C-Protokoll die höheren Schichten von Kommunikationsprotokollen, die das Ethernet-System in einen zuverlässigen Kanal verwandeln. Somit ist dies eine große Belastung für eine Mehrfachmaster-I²C-Einrichtung. An jedem Punkt einer I²C-Übertragung muß ein Busmaster in der Lage sein Zusammenstöße mit anderen Busmastern zu erkennen und elegant zu beheben.
Einige dieser Kollisionsszenarien sind besonders lästig. Zum Beispiel ist das „Vermittlungsverfahren", wie in der zuvor erwähnten I²C-Spezifikation beschrieben, der Mechanismus, mit dem Mehrfach-Busmastereinrichtungen den I²C-Bus simultan treiben können, ohne Datenverfälschung zu verursachen. Der grundlegende Mechanismus der Vermittlung beruht auf der Eigenschaft des offenen Kollektors des Busses; wenn zwei oder mehr Master ein Adreß- oder Datenbit auf die SDA-Leitung 108 einführten, wird ein NIEDRIG Wert, der von ein oder mehr Busmastern getrieben wird, immer über einen von anderen Busmastern produzierten HOCH Wert gewinnen. Daher wird jeder Busmaster, der versucht, während einer Bitzeit einen HOCH Wert zu treiben (dabei aber die SDA-Leitung 108 nicht NIEDRIG einleitet und dem Hochzieh-Widerstand 104 ermöglicht, die Leitung HOCH zu hatten), aber einen NIEDRIG Wert während derselben Bitzeit abtastet, erkennen, daß eine Kollision mit einem anderen Busmaster erfolgte, der einen NIEDRIG Wert einleitet, und den Bus freigeben. Wenn jedoch mehrere Busmaster dieselben Bitsequenzen einleiten, dann wird keine Kollision erkannt, bis die Bitsequenzen differieren. Daher ist es möglich, daß ein Busmaster einen Zusammenstoß zwischen sich selbst und einem anderen Master zu einem beliebig späten Punkt in der Transaktion erkennen wird, oder auch gar nicht.
Ein Verlieren der Vermittlung ist aus der Sicht des Protokolls der am einfachsten zu behandelnde Fehlertyp, da er den Busmaster, der verloren hat, automatisch aus dem Bus zwingt, wie in der zuvor erwähnten I²C-Spezifikation definiert. Im allgemeinen wird der Busmaster, der die numerisch kleinste Nachricht einleitet (Adresse oder Daten) den Bus erhalten, während diejenigen, die numerisch höhere Bitsequenzen einleiten, d.h. mit mehr Einsen, bei der Vermittlung verlieren und gezwungen werden, ihre Transaktionen nach dem Abschluß des aktuellen Vorgangs erneut zu versuchen.
Der Mechanismus des Schiedsentscheides wird in der I²C-Spezifikation nur für Busmaster definiert, die während des Übertragens von Adreß- oder Datenbits kollidieren. Da die Busmaster alle vor dem Aufdecken der Kollision synchron sind, erfolgt die korrekte Behandlung der Situation direkt und der Zustand des Busses (besetzt oder Leerlauf) (busy or idle) ist gut verstanden. Besonders ist der Bus dann besetzt, wenn der/die Master, der/die gewinnt/gewinnen, die Transaktion fortsetzen. Ein Zusammenstoß zwischen zwei Mastern, von denen einer ein Datenbit und der andere eine START- oder STOP-Bedingung treibt, ist im Gegensatz dazu jedoch von der I²C-Spezifikation dahingehend, wie dies behandelt werden sollte, nicht gut definiert.
Der letztere Typ von Buskollision ist komplexer als das einfache Verlieren bei der Vermittlung. Bei dieser Art des Zusammenstoßes überträgt oder empfängt ein Busmaster ein „1" Bit, das auf der SDA-Leitung 108 als HOCH Wert dargestellt wird, während ein anderer Busmaster die SDA-Leitung 108 in der Mitte des Bits auf NIEDRIG treibt. Diese START- oder STOP-Bedingung ist aus Sicht des das Datenbit treibenden Busmasters „asynchron", da START- und STOP-Bedingungen per Definition nur zwischen Adreß- und Datenbytes, aber nicht für beliebige Bitabgrenzungen erlaubt sind. Die I²C-Spezifikation ist unklar darin, ob der Busmaster, der diese START-/STOP-Bedingung erkannt hat, automatisch aufhören sollte, den Bus zu treiben und ein Verlieren bei der Vermittlung aufzeichnen sollte. Diese Art von Fehler wird typischerweise in Hardware erkannt und an Software gemeldet, da es sich von einem normalen Verlieren beim Schiedsentscheid unterschiedet. Zusätzlich veranlaßt dieser Fehlertyp typischerweise keinen Master dazu, das Treiben des Busses anzuhalten, wenn er von einem Master erkannt wird, während er Bits empfängt. Daher treiben mehrere Master immer noch den Bus, wenn der Fehler auftritt, aber die START- oder STOP-Bedingung hat die zuvor ablaufende Transaktion abrupt abgeschnitten. Dieser Fehler kann auftreten, wenn zwei oder mehr Busmaster eine gewisse Zeit lang identische Transaktionen treiben, und dann einer der Master ein STOP oder einen wiederholten START ausgibt, während der andere versucht, den Vorgang mit mehr Datenbytes fortzusetzen.
Dieser Fehler kann auch ein wesentlich ernsteres Szenario anzeigen, bei dem wenigstens ein Master nicht mehr mit dem Zustand des Busses synchronisiert ist (belegt oder Leerlauf) und zusätzlich zu einer bereits laufenden Transaktion eine weitere ausgeführt hat. Dieser Fehler kann auftreten, wenn Rauschen auf den Bus gekommen ist, was die SDA-Leitung 108 dazu veranlaßt hat, in der Mitte eines Bits ein Übergangsverhalten/Störspannung zu erleiden. Da das I²C-Bussystem ein offener Kollektorbus mit relativ schwachem Hochziehen ist und da einige Systeme es erlauben, daß I²C-Einrichtungen im laufenden Betrieb an den Bus angeschlossen ("hot-plugged") werden, können solche Übergangssignale/Störspannungen auftreten.
Das Umgehen mit diesem Fehler ist insofern komplex, als ein Busmaster, der diese Situation erkennt, die Eigentümerschaft an diesem Bus aufgeben könnte. In diesem Fall muß der Busmaster die Herrschaft über den Bus aufgeben, indem er gleichzeitig eine STOP-Bedingung treibt oder seine I²C-Schnittstelle irgendwie zurücksetzt oder neu initialisiert. In der Praxis ist unklar, ob irgendein Busmaster übrig bleibt, der eine Transaktion treibt. Wenn die vorige laufende Transaktion von allen Busmastern aufgegeben wurde, dann ist es möglich, daß der Bus sich "AUFHÄNGT", was bedeutet, daß alle Busmaster, die vor kurzem ein START gesehen haben (im Gegensatz zu STOP), darauf warten, daß irgendjemand ein STOP treibt, bevor sie versuchen, sich den Bus neu zu verschaffen. Ein Erholen von diesem Zustand benötigt Zeitüberschreitungs-Zeitgeber und spezifische Software für die Hardware-Implementierungen des I²C-Masters.
Die mit Multimaster-I²C verbundene Komplexität betrifft sowohl die Hardwareimplementierung des Busmasters selbst als auch den Softwaretreiber, der in Verbindung mit der Hardware arbeitet, um gut ausgebildete I²C-Transaktionen durchzuführen. Die hinzugefügte Softwarekomplexität von Multimaster I²C über Ein-Master-I²C nimmt die Form ausgeklügelter Fehlerbehandlungs- und Buswiederherstellungsvorgänge an. Darüber hinaus gibt es keine veröffentlichten Standards ähnlich dem Ethernetsystem, die spezifizieren, wie verschiedene Protokollverletzungen behandelt werden sollten oder wie Protokollschichten höherer Ebenen verwendet werden sollten, um einem unzuverlässigen I²C-Bus zusätzlich größere Zuverlässigkeit zu geben. Als ein Ergebnis davon ist ein Multimaster-I²C-Bussystem eine unsichere bzw. ungewisse Umgebung, bei der die Gesamtzuverlässigkeit des Busses nur so gut ist wie die Qualität des schlechtesten Busmasters im System. Zusätzlich ist das Testen und Verifizieren der Multimaster-Hardwareunterstützung einer Busmaster-Implementierung häufig nicht so gründlich wie nötig, weil das I²C-Bussystem als „einfacher, serieller Zwei-Draht-Bus" gilt, was zu verdeckten Fehlern führt. In vielen Fällen verursachen die Fehler Datenverfälschung (s.o.) und haben keine Softwareabhilfe bzw. -umgehung.
Daher besteht ein Bedarf an einer Vorrichtung, die zur Konstruktion eines zuverlässigen Multimaster-I²C-Bussystems verwendet werden kann.
ZUSAMMENFASSUNG DER ERFINDUNG
Gemäß einem erläuternden Aspekt der Erfindung wird eine „Firewall"-Vorrichtung zwischen eine Ein-Busmaster-Einrichtung und ein Multimaster-I²C-Bussystem gesetzt. Die „Firewall"-Vorrichtung transformiert alle Multimaster-Busfehler in einfache NAK-Fehler. Daher braucht ein Master, der durch die erfindungsgemäße „Firewall"-Vorrichtung von dem Multimasterbus isoliert ist, nur Transaktionen erneut zu versuchen, die unerwartete NAKs empfangen. All die komplexen Multimasterprobleme wie Kollisionsbehandlung, Transaktionsbeendigung und Buswiedergewinnung verbunden mit dem tatsächlichen Fehler, der auf dem Multimasterbus auftrat, werden von der „Firewall"-Vorrichtung behandelt.
Gemäß einer Ausführungsform absorbiert die Firewall-Vorrichtung in dem Fall, daß die Mastereinrichtung auf der Ein-Master-Seite der Firewall versucht, eine Transaktion zu einem Zeitpunkt loszuschicken, wenn der Multimaster- I²C-Bus belegt ist, die von dem Ein-Masterbus eingeführte Adresse und hält dann die Transaktion an, bis die Firewall-Vorrichtung in der Lage ist, die Adresse erfolgreich zu erlangen und auf dem Multimasterbus einzuleiten.
Gemäß einer anderen Ausführungsform bringt die Firewall-Vorrichtung die Ein-Busmaster-Transaktion zum Stillstand indem sie die SCL-Taktleitung steuert und niedrig treibt.
Gemäß einer anderen Ausführungsform wird die Firewall-Vorrichtung automatisch versuchen, den Multimaster-Bus eine vorbestimmte Anzahl von Malen zu erwerben, wodurch die Mastereinrichtung davon befreit wird, auf Kollisionen und Verlieren bei Vermittlungen zu achten, die auf dem Multimasterbus auftreten, wenn die Mastereinrichtung auf der Ein-Master-Seite der Firewall eine Transaktion beginnt.
Gemäß noch einer weiteren Ausführungsform ist die Firewall-Vorrichtung durch einen programmierten Mikroprozessor implementiert, der durch ein Programm eines endlichen Automaten (Zustandsmaschine) implementiert ist. In dieser Ausführungsform wird eine durch den Ein-Busmaster generierte START-Bedingung durch Verbinden der SDA-Leitung mit einem Unterbrechungs- bzw. Interruptanschluß auf dem Mikroprozessor und das Ablaufenlassen einer Unterbrechungsdienstroutine in Reaktion auf eine Unterbrechung zum Erkennen dieser START-Bedingung erkannt.
In noch einer weiteren Ausführungsform ändert die Firewall-Software dynamisch die Betriebsfrequenz der Mikrosteuerung abhängig davon, ob der Mikroprozessor mit dem Ein-Masterbus oder mit dem Multimasterbus kommuniziert, um den Zeitsteuerungsanforderungen gerecht zu werden.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die obigen und weitere Vorteile der Erfindung versteht man besser unter Bezugnahme auf die folgende Beschreibung in Verbindung mit den begleitenden Zeichnungen, von denen:
1 ein schematisches elektrisches Diagramm des herkömmlichen I²C-Bussystems ist, das die Art und Weise, wie Informationen auf dem Bussystem getrieben und Informationen von dem Bussystem empfangen werden, darstellt,
2 ein schematisches Blockdiagramm der erfindungsgemäßen Firewall-Vorrichtung ist, die zwischen eine Ein-Master-I²C-Vorrichtung und eine Multimaster-I²C-Domäne geschaltet ist,
3 ein detaillierteres schematisches Blockdiagramm der erfindungsgemäßen, mit einer Mikrosteuerung implementierten und zwischen eine Ein-Master-I²C-Vorrichtung und eine Multimaster-I²C-Domäne geschalteten Firewall-Vorrichtung ist,
4 ein schematisches Blockdiagramm eines Registersatzes innerhalb der Mikrosteuerung ist, dessen Registersatz durch den Port-A-Master zugänglich ist,
5 ein Zustandsdiagramm zur Darstellung der Verarbeitung anfänglicher Adreßinformation ist,
6A und 6B Zustandsdiagramme zur Illustration der Lese- beziehungsweise Schreib-Verarbeitung von zwischen der Ein-Master-Vorrichtung und der Multimaster-Domäne übertragenen Daten sind,
7 ein Zustandsdiagramm zur Illustration der Verarbeitung einer wiederholten, vom Port-A-Master generierten START-Bedingung ist,
8 ein Zustandsdiagramm zur Illustration der Verarbeitung einer allgemeinen Fehlerbedingung ist,
9 ein Zustandsdiagramm zur Illustration der Unterbrechungsservice-Verarbeitung ist,
10A, 10B und 10C Zustandsdiagramme zur Illustration der anfänglichen Lese- bzw. Schreibverarbeitung von vom Port-A-Master auf die internen Register der Mikrosteuerung übertragenen Daten sind,
11 eine Bildschirmabbildung von Oszilloskopaufzeichnungen ist, die die anfängliche Adreßphase einer vom Port-A-Master eingeführten Transaktion zeigt,
12 eine Bildschirmabbildung von Oszilloskopaufzeichnungen ist, die den Betrieb der Firewall-Vorrichtung während einer wiederholten vom Port-A-Master getriebenen Start-Bedingung zeigt,
13 eine Bildschirmabbildung von Oszilloskopspuren ist, die den Betrieb der Firewall-Vorrichtung zeigt, wenn der Port-A-Master versucht, eine Transaktion zu einem Zeitpunkt zu starten, wenn der Port-B-Multimaster-I²C-Bus belegt ist.
DETAILLIERTE BESCHREIBUNG
Die Erfindung betrifft eine „Firewall"-Vorrichtung und ein Verfahren, das von einem Busmaster generierte I²C-Transaktionen puffert und die Transaktionen auf einem Multimaster Bussegment erneut überträgt. Der Begriff „Firewall" bezieht sich auf die Tatsache, daß die erfindungsgemäße Vorrichtung eine asymmetrische Busbrücke ist. Daher funktioniert sie auf ähnliche Weise wie eine Internet-Firewall, die transparenten Zugriff von einem firmeneigenen Intranet auf das externe Internet erlaubt, während sie für Internetverkehr das Eindringen in das firmeneigenen Intranet verwehrt. In ähnlicher Weise hat die erfindungsgemäße Vorrichtung zwei I²C-Ports, im folgenden „Port-A" (Anschluß A) und „Port-B" (Anschluß B) genannt, und agiert, um I²C-Verkehr transparent von Port-A an Port-B zu übergeben, aber nicht umgekehrt. Der Ausdruck „Port-A Master" wird verwendet, um auf den Mastereinrichtungsanschluß zu Port-A auf dem privaten I²C-Segment zu verweisen.
Der beabsichtigte Einsatz der Firewall-Vorrichtung wird in 2 gezeigt. Die Firewall-Vorrichtung 200 sitzt zwischen einer Nicht-Multimaster-I²C-Steuerung 202 und dem Rest der Multimaster-I²C-Domäne 204. Die Firewall-Vorrichtung 200 hat zwei Portschnittstellen: Port A 208 und Port B 214. Als Firewall ist die Port-A-Schnittstelle 208 nur abhängig (slave only) und dient nur dem Empfang von Transaktionen vom Port-A-Master 202 über die SCL- und SDA-Leitungen 206 und 210. Die Port-B-Schnittstelle 214 ist nur Master (master-only) und ist vollständig multimasterfähig und treibt die MM SCL- und MM SDA-Leitungen 212 und 216. In der bevorzugten Ausführungsform erlaubt die Firewall-Vorrichtung 200 den Mastern in der Multimaster-Domäne 204 nicht, den Port-AMaster 202 als Abhängigen anzusteuern, obwohl in anderen Ausführungsformen diese Fähigkeit leicht hinzugefügt werden kann.
In der Konfiguration von 2 existiert die Firewall-Vorrichtung 200 als einzige abhängige Einrichtung in dem privaten I²C-Segment, das die SCL- und SDA-Leitungen 206 und 210 umfaßt, die zwischen Port-A 208 und der Einrichtung 202 geschaltet sind. Diese Konfiguration ist nötig, weil in der bevorzugten Ausführungsform die Firewall-Vorrichtung 200 keinerlei Adreßfilterung durchführt, wie dies typischerweise, zum Beispiel bei einer Ethernet-Brücke erfolgen würde. Stattdessen wird die Firewall-Vorrichtung jedwede Adresse, die sie bei Port-A 208 empfängt, an den Multimasterbus 212, 216, der mit Port-B 214 verbunden ist, weiterleiten. Da der Port-B-Bus 212, 216 Nur-Master ist, verhindert er, daß irgendeine Aktivität in der Multimaster-Domäne 204 den Port-A-Master 202 erreicht. Solches Adreßfiltern könnten jedoch leicht für Anwendungen implementiert werden, die dies erfordern, und zwar unter Verwendung eines RAM-Arrays innerhalb der Firewall-Steuerung.
An und für sich betrachtet der Port-A-Master 202 das private A-seitige I²C-Segment 206, 210 niemals als „belegt", wenn er eine neue Transaktion einzuleiten versucht. In ähnlicher Weise filtert die erfindungsgemäße Firewall-Vorrichtung jede Protokollverletzung heraus, die auf dem Port-B-Multimasterbus 212, 216, vorkommen kann, wobei es in allen Fällen dem Port-A-Master 202 ein gültiges I²C-Protokoll darstellt. In einer bevorzugten Ausführungsform übersetzt die Firewall-Vorrichtung 200 alle Fehlertypen auf dem Port-B-Multimasterbus 212, 216 in NAKs auf dem Port-A-Bus 206, 210. Gemäß den Prinzipien der Erfindung braucht der Port-A-Master 202 durch Umdrehen aller auf Port-B 214 auftretenden, auf den Multimaster bezogenen I²C-Fehler in auf Port-A 208 erscheinende NAK-Fehler keines der problematischen, zuvor beschriebenen Multimaster-I²C-Fehlerszenarios zu erkennen und zu behandeln. Daher erlaubt die erfindungsgemäße Firewall-Vorrichtung jeder nicht-multimasterfähigen I²C-Steuerung mit einem Multimasterbus verbunden zu sein und korrekt auf dem Multimasterbus zu operieren, ohne Multimaster ausgelegte Hardware oder Software zu benötigen.
Ein übliches Verfahren zur Konstruktion einer I²C-Steuerung ist der Gebrauch eines „Bit-Bang"-Treibers, der zwei Mehrzweck- (General Purpose I/O, GPIO)-I/O-Ports mit offenem Kollektor zur Verwendung als I²C-Steuerung stimuliert. In der PC-Industrie gab es über Jahre Software, die genau dies mittels des standardmäßigen, bidirektionalen Parallelanschlusses tat. Da diese Schnittstelle keine hardwaremäßige I²C-Unterstützung zum Erkennen von START/STOP oder Vermittlungen hat und mit Softwaregeschwindigkeit getrieben wird, wurde allgemein angenommen, daß solch ein Anschluß niemals Multimaster-fähig gemacht werden könnte. Mit der vorliegenden Erfindung ist dies nun möglich. Der Softwaretreiber muß nur die elementarsten Grundlagen einer Ein-MasterI²C-Operation kennen.
Wie zuvor erwähnt, arbeiten die zwei Drähte, die den I²C-Bus ausmachen, die SCL- und SDA-Leitungen 206 und 210, mit offenen Kollektoreinrichtungen. Dies bedeutet, daß Einrichtungen auf dem I²C-Bus nur in der Lage sind, entweder diese Busse aktiv in einen NIEDRIG-Zustand zu treiben oder die Busse freizugeben und den Hochziehwiderständen (1, 104 und 106), die mit diesen Bussen verbunden sind, zu erlauben, sie auf den HOCH-Zustand zu ziehen. Daher wird, wenn irgendeine Einrichtung ein NIEDRIG-Signal auf einen Bus treibt, der Bus dann NIEDRIG sein und umgekehrt wird ein Bus nur HOCH werden, wenn alle Einrichtungen ihn freigegeben haben und den Hochziehwiderständen erlaubten, den Bus HOCH zu ziehen.
Dieses Verhalten kann, wenn es auf die SCL-Leitung 206 angewendet wird, als ein Taktsynchronisierungsmechanismus verwendet werden, was in der zuvor erwähnten I²C-Bus-Spezifikation diskutiert wird als ein Mittel, mit dem Einrichtungen eine gerade ablaufende Transaktion langsamer machen oder sie zeitweise anhalten. Zum Beispiel ist das Folgende ein Auszug aus Abschnitt 8.3 der I²C-Spezifikation:
„Der Taktsynchronisierungsmechanismus kann zusätzlich zur Verwendung während der Vermittlung dazu verwendet werden, Empfänger in die Lage zu versetzen, mit schnellen Datenübertragungen entweder auf Byteebene oder auf Bitebene umzugehen.
Auf der Byteebene kann eine Einrichtung in der Lage sein, Datenbytes mit hoher Rate zu empfangen, braucht aber mehr Zeit, ein empfangenes Byte zu speichern oder ein anderes Byte für die Übertragung vorzubereiten. Nach Empfang und Bestätigung eines Bytes können Abhängige dann die SCL-Leitung NIEDRIG halten, um den Master in einen Wartezustand zu zwingen, bis der Abhängige für die nächste Byteübertragung in einer Art von Handschlag-Vorgang bereit ist.
Auf der Bitebene kann eine Einrichtung wie ein Mikrocontroller mit oder ohne begrenzte Hardware für den I²C-Bus den Bustakt durch Ausdehnen jeder NIEDRIG Taktspanne verlangsamen. Die Geschwindigkeit eines jedem Masters wird dabei an die interne Verarbeitungsrate der Einrichtung angepaßt."
In der erfindungsgemäßen Vorrichtung wird der Taktsynchronisierungsmechanismus für die auf der Firewall-Vorrichtung von Mikrocontroller 201 laufende Software verwendet, um selektiv entweder den Port-A-Bus 206, 210 oder den Port-B-Bus 212, 216 anzuhalten. Auf diese Weise steuert die Software den Fortschritt der Transaktion auf beiden Seiten der Firewall-Vorrichtung 200. Man beachte, daß der Port-A-Master 202 diesen Taktsynchronisierungsmechanismus korrekt implementieren muß, damit er korrekt mit der erfindungsgemäßen Firewall-Vorrichtung 200 arbeitet. Da der Mechanismus sowohl auf Ein-Master- als auch auf Multimaster-I²C-Systemen Anwendung findet, belastet diese Anforderung den Port-A-Master 202 nicht noch zusätzlich zu der einfachen Ein-Master-I²C-Operation.
In einer bevorzugten Ausführungsform ist die Firewall-Vorrichtung in einen programmierbaren Mikrocontroller implementiert, aber es sind andere Implementierungen möglich. Ein Mikrocontroller, der für den Gebrauch in Verbindung mit der Erfindung geeignet ist, ist die Einrichtung 87LPC764, hergestellt und verkauft von der Philips Semiconductor Corporation. Dieser Controller ist mit Firmware programmiert und daher ist die bevorzugte Ausführungsform eine kombinierte Hardware- und Software-Implementierung. Zusätzlich zu anderen Hardwareressourcen hat dieser Mikrocontroller eine Multimaster-I²C-Schnittstelle. Die erfindungsgemäße Vorrichtung braucht jedoch ganz klar zwei I²C-Schnittstellen, um ihre Funktion als Firewall zu erfüllen. Daher wird die eingebaute I²C-Schnittstelle des Mikrocontrollers für den Port-B-Bus 212, 216 benutzt und die nur-abhängige Port-A-Schnittstelle wird mittels zweier GPIO Stifte auf dem Mikrocontroller und einem Software „Bit-Bang" Treiber implementiert.
3 zeigt, wie ein Mikrocontroller 301 zum Verbinden einer nicht-Multimaster-fähigen I²C-Einrichtung 302 mit einer Multimaster-Busdomäne 304 verwendet wird. In 3 wurde Elementen, die Elementen in 2 entsprechen, entsprechende Nummern gegeben. Zum Beispiel entspricht der Mikrocontroller 301 in 3 dem Mikrocontroller 201 in 2. Die Beschreibung der Elemente in 2, die Elementen in 3 entsprechen, kann auf 3 angewendet werden.
Der 87LPC764-Controller 301 beinhaltet 4 KB einmalig programmierbaren (OTP) internen Speicher, der als Programmcoderaum verwendet wird. Daher ist die Firewall-Software in den 87LPC764-Controller 301 eingebettet. Der 87LPC764-Controller 301 läuft mit einem von dem Kristall 322 und den Kondensatoren 324 und 326 zur Verfügung gestellten 20-MHZ-Eingabetakt und hat einen internen Maschinenzyklus von 1/6 des Eingabetaktes oder ungefähr 3,3 MHz. Der Grund, warum dieser Maschinenzyklus für die erfindungsgemäße Firewall von Bedeutung ist, liegt darin, daß die Port-A-Schnittstelle 308 nur per Software und zwei GIO-Stifte, 19 und 20, implementiert ist. Um eine solche abhängige Bit-Bang-I²C-Schnittstelle zuverlässig zu implementieren und ihr zu erlauben, bei der vollen Geschwindigkeit von 100 KBit/sec zu laufen, muß die Software in der Lage sein, die Port-A-SDA/SCL-Anschlußstifte 19 und 20 zwischen 2–3 Mal während der in der I²C-Spezifikation angegebenen, minimal 4,7 Mikrosekunden, in denen SCL HOCH ist, abzufragen (und auf ihnen zu agieren). Die Anforderung eines mehr als zweimaligen Abfragens in diesem Intervall soll sicherstellen, daß die SCL/SDA-Anschlußstifte während der SCL-HOCH-Zeitspanne korrekt gesehen bzw. erkannt werden, auch wenn der Abfrageschleife ein anfänglicher Übergang von SCL=NIEDRIG zu SCL=HOCH entgeht, wobei in diesem Fall die Abfrageschleife zwei Durchläufe absolvieren muß, bevor SCL=HOCH erkannt wird.
Die in der erfindungsgemäßen Firewall-Software zum Überwachen der Port-A-Schnittstelle 308 verwendete Abfrageschleife wird alle 1,5 Mikrosekunden ausgeführt, was mehr als zwei Wiederholungen in der minimalen SCL-HOCH-Zeitspanne von 4,7 Mikrosekunden mit einer kleinen übrigen Spanne ausmacht. Daher hat der 20MHz 87LPC764-Mikrocontroller 301 genügend Leistungsfähigkeit, um einen abhängigen I²C-Bit-Bang-Port bei 100 Kbit/sec zu implementieren.
Der 87LPC764-Mikrocontroller beinhaltet eine Multimaster-fähige I²C-Schnittstelle. In der vorliegenden Anwendung ist dieser Port für die Port-B-Schnittstelle 315 reserviert, da die Schnittstelle mit der Multimaster-Domäne des Systems verbunden ist. Die I²C-Schnittstelle präsentiert der auf dem 87LPC764 laufenden Software einen 1 Bit breiten Datenpfad auf den I²C-Bus, so daß die Software mit der Registerschnittstelle bitweise interagieren muß. Obwohl dies mehr Software zum Treiben der I²C-Schnittstelle erfordert als bei Byte-orientierten I²C-Einrichtungen, wird tatsächlich die Bit-orientierte Schnittstelle bevorzugt, da sie der Software einen viel feineren Grad der Steuerung über den Bus 312, 314 erlaubt. Dies ist besonders während Buswiedererstellungs-Vorgängen nach einem fatalen Protokollfehler nützlich, der dazu führt, daß der Bus hängt.
Ein Attribut der internen I²C-Kontrollogik (nicht gezeigt) des 87LPC764-Mikrocontrollers 301, die unbequem ist, liegt darin, daß die I²C-Baud-Rate durch einen Hardware-Zeitgeber (nicht gezeigt) ganz eng mit dem Mikrocontroller-Maschinenzyklus gekoppelt ist. Dieser Zeitgeber zählt Maschinenzyklen zur Zeitsteuerung der I²C-Operationen auf dem Port-B-Bus 312, 3126. Unglücklicherweise ist der gesamte I²C-Kern in dem 87LPC764-Mikrocontroller 301 identisch mit der aus älteren, langsameren 8051-Derivaten, besonders dem des 87C751. Diese letztere Einrichtung hatte eine viel langsamere maximale Maschinenzyklusfrequenz als der 87LPC764. Daher wird der I²C-Kern in dem 87LPC764-Mikrocontroller 301 eine ungültige I²C-Zeitsteueurng generieren, wenn der Kern schneller betrieben wird als bei ungefähr 8 MHz.
Daher gibt es sich widerstreitende Anforderungen: (1) Die Bit-Bang-Port-A-Schnittstelle 308 erfordert, daß der Mikrocontroller 301 bei 20 MHz läuft, und (2) die 87LPC764-I²C-Logik erfordert, daß der Mikrocontroller bei 8 MHz oder weniger läuft. Glücklicherweise stellt der 87LPC764-Mikrocontroller 301 ein Software-programmierbares Register (nicht gezeigt) zur Verfügung, um die Betriebsfrequenz zu ändern. Mittels dieses Registers ändert die erfindungsgemäße Firewall-Software dynamisch die Betriebsfrequenz, abhängig davon, ob der Port-A-Bus 306, 310 oder der Port-B-Bus 312, 316 stimuliert wird. Besonders der Mikrocontroller 301 läuft bei 20 MHz für Port-A 308 Operationen und wird auf 5 MHz für Port-B 314 Operationen verlangsamt.
Um neue START-Bedingungen auf der Port-A-Schnittstelle 308 während des Abschließens des Endes einer vorausgegangen I²C-Transaktion auf der Port-B-Schnittstelle 314 verläßlich zu erkennen, ist die Port-A-SDA-Leitung 310 mit dem externen Unterbrechungseingang des Mikrocontrollers 301 auf Anschlußstift 8 über die Leitung 311, zusätzlich zu der Verbindung mit dem geeigneten Port-A-GPIO-Anschlußstift 20, verbunden. Diese Unterbrechung ist nur dann möglich, wenn der Port-A-Bus 306, 310 nicht belegt ist, d.h. direkt nach einem Rücksetzen und zwischen STOP- und START-Bedingungen auf dem Port-A-Bus 306, 310. Daher wird die anfängliche START-Bedingung einer jeden Port-A-Transaktion über diesen Unterbrechungsmechanismus erkannt, während sämtliche andere Port-A-Aktivität für die restliche Transaktion mittels Abfragen erkannt wird.
Zusätzlich dazu, daß sie als eine I²C-Firewall agiert, agiert die Firewall-Vorrichtung 310 auch als eine abhängige Einrichtung gegenüber dem Masterbus 302, der mit Port-A 308 verbunden ist. Wie jede abhängige I²C-Einrichtung wird die Firewall-Vorrichtung die SDA-Leitung 310 während Lesetransaktionen zur Datenübertragung an den Port-A Master 302 treiben. Wenn der Port-A-Master 302 hängt, einen Zusammenstoß hat, oder aus irgendwelchen Gründen die Aktivität auf der Port-A-Schnittstelle 308 in der Mitte einer Transaktion einstellt, wird die Firewall-Vorrichtung 310 insoweit im Gegenzug die Aktivität auf dem Port-A-Bus 306, 310 und auf dem Port-B-Multimasterbus 312, 316 einstellen. Um das Hängenbleiben der gesamten Multimasterdomäne 304 wegen eines fehlerhaften Port-A-Masters 302 zu verhindern, nutzt die Firewall-Vorrichtung 301 einen Überwachungs-Zeitgeber (nicht gezeigt) in dem Mikrocontroller 301 zum Erkennen einer hängengebliebenen Port-A-Transaktion. Wenn dies passiert, wird der Mikrocontroller 301 nach einer Inaktivität von einer Sekunde auf der Port-A-Schnittstelle 308 während einer Port-A-Transaktion einem Hardware-Rücksetzen unterzogen. Dieses Rücksetzen löscht alle Zustandsinformationen innerhalb des Mikrocontrollers 301 und gibt sowohl die Port-A- als auch die Port-B-Schnittstellen 308 beziehungsweise 314 frei.
Diese Rücksetz-Operation ist besonders wichtig zum Verhindern eines bzw. einer potentiellen Blockierung auf der Port-A-Schnittstelle 308, denn: wenn der Port-A-Master 302 ausfällt oder aus einem anderen Grund eine Port-A-Lese-Transaktion abbricht, während die Firewall-Vorrichtung 301 die SDA-Leitung 310 NIEDRIG auf den Port-A-Master 302 treibt, dann wird die Firewall-Vorrichtung 301 einfach in dem Zustand bleiben und auf zusätzliche Taktimpulse auf der SCL-Leitung 306 warten. Wenn der Port-A-Master 302 wieder hergestellt ist, kann er versuchen, die Transaktion neu zu starten, aber er wird nicht in der Lage sein, eine START-Bedingung auf der Port-A-Schnittstelle 308 zu starten, aufgrund der Tatsache, daß die Firewall-Vorrichtung 301 die SDA-Leitung 310 NIEDRIG hält, was zu einer Blockierung führt. Unter Benutzung des Überwachungs-Zeitgebers wird die Firewall-Vorrichtung 301 sich selbst nach einer Sekunde zurücksetzen, was dem Port-A-Master 302 erlaubt, die Transaktion normal neu zu starten. Bei normalem Betrieb tritt dies niemals ein, weil der Port-A-Master 302 Transaktionen immer über eine STOP-Bedingung beendet. Der Überwachungs-Zeitgeber wird hier nur dazu benutzt, sich von pathologisch schlechtem Verhalten von Seiten des Port-A-Masters 302 zu erholen.
Zusätzlich zu ihrem normalen, transparenten Betriebsmodus bezieht die Firewall-Vorrichtung auch eine Registerbank ein, auf die von auf dem Port-A-Master 302 laufender Software zugegriffen werden kann. Diese Register werden in 4 dargestellt und liefern Informationen an den Port-A-Master 302 hinsichtlich der Firmware-Revision des Firewall-Vorrichtungschips, ermöglichen es, die von der Firewall-Vorrichtung genutzten I²C-Adressen zu ändern und ermöglichen es, daß die Firewall-Vorrichtung unter Software-Steuerung durch den Port-A-Master 302 zurückgesetzt wird. Die Vorrichtung stellt auch Zugang zu einem 32-Byte RAM-Array 408 zur Verfügung, der nicht von der Firewall-Vorrichtung genutzt wird. aber durch diese Registerschnittstelle zu diagnostischen Zwecken verfügbar gemacht wird. Eine voraussehbare Nutzung dieses 32-Byte RAM-Array 408 wäre die eines Adreßbitmap, das angibt, welche I²C-Adressen auf der Port-A-Schnittstelle sitzen und welche sich auf der Port-B-Schnittstelle befinden, wobei der Firewall-Vorrichtung ermöglicht wird, Adreßfilterung zu implementieren. Dies würde es dem Ein-Master-Bus 306, 310 ermöglichen, andere abhängige Einrichtungen zusätzlich zu der Firewall-Vorrichtung zu haben.
Dieser für den Zugriff auf den internen Registerraum bereitgestellte Mechanismus ist ähnlich dem von anderen I²C-Einrichtungen benutzten. Die Firewall-Vorrichtung 301 stellt ein Indexregister 410 bereit, das zum Lesen und Schreiben des internen Registerarray 400 verwendet wird. Das Indexregister 410 agiert als ein Zeiger, durch den der Inhalt des Registerarray 400 gelesen und geschrieben werden kann. Das Indexregister 410 entscheidet, auf welche Stelle in dem Array zugegriffen werden kann.
Die von der Firewall-Vorrichtung 301 verwendeten I²C-Adressen werden von den Inhalten der BASE-Register 404 bestimmt und haben als Standardeinstellung 0×60 und 0×61, wobei 0×60 die Schreibadresse und 0×61 die Leseadresse ist, wie bei der Standard-I²C-Adressierung. Das Indexregister 410 ist nur-beschreibbar über die Adresse 0×60, während das Registerarray 400 bei Adresse 0×60 (be)schreibbar und bei Adresse 0×61 lesbar ist. Da die Schreiboperationen sowohl auf das Indexregister 410 als auch das Registerarray 400 durch I²C-Adresse 0×60 beeinflußt werden, unterscheidet die Vorrichtung zwischen den beiden auf der Grundlage der folgenden Regel: Für das Indexregister 410 gedachte Daten müssen immer das erste auf die Adreßphase in einer Schreibtransaktion folgende Byte sein. Nachfolgende Bytes in derselben Schreiboperation werden in das Registerarray 400 ausgehend von dem durch das Indexregister 410 angegebenen Abstand gelenkt.
Zur Erleichterung des Lesens und Schreibens mehrerer konsekutiver Bytes innerhalb des Registerarray 400 inkrementiert das Indexregister 410 automatisch um eins, nachdem jedes Byte in oder aus dem Array übertragen wurde. Dies gilt gleichermaßen, ob eine gegebene I²C-Transaktion in einer einzigen Operation mehrere Bytes oder nur ein einzelnes Byte bewegt; das Indexregister 410 inkrementiert in jedem Fall.
Versuche, in das Indexregister 410 ungültige Abstandwerte zu schreiben, werden ignoriert. In ähnlicher Weise wird das Indexregister 410 nicht inkrementieren, wenn während des Lesens oder Schreibens mehrerer Bytes in einer einzigen Transaktion die Auto-Inkrementierungseigenschaft von Indexregister 410 zu einem ungültigen Index führen würde, wodurch nachfolgende Bytes von der letzten Stelle in dem Registerarray 400 gelesen oder in diese geschrieben würden.
Man beachte, daß die aktuelle Stelle des Indexregisters 410 innerhalb der Vorrichtung durch erneutes Schreiben eines neuen Wertes in das BASIS-Register 404 geändert werden kann. In dieses Register 404 muß die gewünschte Adresse von Indexregister 410 geschrieben werden. Die Vorrichtung wird dann die Adressen „BASIS" und „BASIS+1 ", wie oben für den Zugriff auf das Indexregister 410 und das Registerarray 400 beschrieben, einnehmen.
Das REVISION-Register 402 erscheint innerhalb des Array 400 an dem Abstand 0 und enthält eine Kodierung der Softwarerevision des Firewall-Vorrichtungschips. Die Hauptrevision 416 ist in Bits <7:4> gegeben, während die Nebenrevision 418 in Bits <3:0> gegeben ist. Ein hypothetischer Softwarerevisionslevel von „1.7" würde zum Beispiel zu einem Wert 00010111b oder 17 hex in dem REVISION-Register 402 führen.
Das BASIS-Register 404 enthält bei Abstand 1 in dem Registerarray 400 die von der Firewall-Vorrichtung für Zugriffe auf das Registerarray 400 verwendete Basisadresse. Dieses Register 404 nimmt beim Zurücksetzen den Vorgabewert von 0×60 an und kann mittels einer I²C-Transaktion von dem Port-A-Master 302 geändert werden. Man beachte, daß keine Adreßkonflikte zwischen dem Indexregister 410 und tatsächlichen Einrichtungen auf dem Port-B-Bus 312, 316 auftreten, da Registerarrayzugriffe nicht an den Port-B-Multimaster-Bus 312, 316 weitergeleitet werden,. Darüber hinaus werden, wie unten beschrieben, alle I²C-Adreß- und Datenbits an den Port-B-Bus 312, 316 weitergeleitet, wenn die Firewall-Vorrichtung in einen sogenannten „transparenten Modus" übergegangen ist. Daher ist es möglich, auf das Registerarray 400 und die Port-B-Einrichtungen selektiv zuzugreifen, auch wenn sie dieselben I²C-Adressen besetzen. Nichtsdestotrotz ist es konzeptionell weniger verwirrend, wenn die Adressen eindeutig gehalten sind.
Daher ist zur leichteren Softwareentwicklung die von dem Indexregisterpaar 410 verwendete Adresse mittels des BASIS-Registers 404 programmierbar. In dem BASIS-Register 404 ist die Basisadresse in Bits <7:0> programmiert, wobei Bit <0> zwangsweise auf 0 gesetzt wird, um sicherzustellen, daß das Indexregister 410 auf einer geradzahligen Adresse ist.
Das RÜCKSETZ-Register 406 kann bei Abstand 2 von dem Port-A-Master 302 zum Erzwingen eines Hardware-Rücksetzens der Firewall-Vorrichtung verwendet werden. Dies kann entweder als Teil der dem Port-A-Master eigenen I²C-Initialisierungsequenz von Nutzen sein oder vielleicht als Teil eines auf dem Port-A-Master 302 laufenden Diagnose- oder Fehlerbehebungscodes. Das einzige Bit von Interesse in diesem Register ist Bit 7, welches, wenn mit einer „1" beschrieben, ein Hardware-Rücksetzen der Firewall-Vorrichtung nach Beendigung der laufenden Port-A- I²C-Transaktion erzwingt. Die Dauer dieses Zurücksetzens und die darauf folgende neue Initialisierung der Vorrichtung liegt bei etwa 25 Mikrosekunden, so daß der Port-A-Master 302 für zumindest diese Zeitspanne nach Beendigen des Schreibens in das Rücksetz-Register 406 davon absehen muß, irgendeine neue I²C-Tranakation zu starten.
Jedoch führt das Zurücksetzen der Firewall-Vorrichtung mittels dieses Mechanismus' dazu, daß diese Vorrichtung glaubt, der Port-B-Multimaster-Bus 312, 316 sei „idle" bzw. im Leerlauf, auch wenn eine Transaktion eines anderen Masters abläuft. Die Firewall-Vorrichtung wird beim Erkennen der nächsten START- oder STOP-Bedingung wieder zurück zur Synchronisation mit dem aktuellen Zustand des Port-B-Busses 312, 316 finden. Um jedoch die Vorrichtung davor zu bewahren, eine Transaktion zusätzlich zu einer gerade von einem anderen Master ablaufenden zu beginnen, sollte der Port-A-Master 302 nach dem Zurücksetzen der Firewall-Vorrichtung mittels des RÜCKSETZ-Registers 406 für eine Zeitspanne gleich der längsten möglichen I²C-Transaktion warten. Diese Zeit ist offenbar abhängig von der Implementierung der anderen Master in dem System, so daß diese „maximale Transaktionszeit" zwischen allen Mastern in dem System abgestimmt sein muß. Dies ist eine generelle I²C-Anforderung und nicht spezifisch für die erfindungsgemäße Firewall-Vorrichtung. Beispielsweise können 200 msec für diese Wartezeit benutzt werden. Das Rücksetz-Register 406 gibt immer ,00h' zurück, wenn es gelesen wird.
Beginnend bei Abstand 0×20 gibt es ein RAM-Array 408 von 32 Bytes, auf das von dem Port-A-Master 302 zugegriffen werden kann. In der bevorzugten Ausführungsform ist dieses Array 408 als Notizblockspeicher bzw. Zwischenspeicher verfügbar und kann als ein Diagnosebereich zum Testen der Firewall-Vorrichtung verwendet werden. Andere Ausführungsformen können dieses RAM-Array 408 für interne Funktionen verwenden, wie eine von der Firewall verwendete Adreß-Bitmap zum Filtern von Adressen, die von der Port-A-Master-Einrichtung 302 kommen. Diese Verbesserung würde andere abhängige Einrichtungen auf dem Nicht-Multimaster- I²C-Bus 306, 310 erlauben.
Während des normalen Betriebs agiert die Firewall-Vorrichtung transparent, indem sie Adreß- und Datenbits zwischen den Port-A- und den Port-B-I²C-Schnittstellen 308 und 314 hin und her leitet. Mit anderen Worten bemerkt der Port-A-Master 302 die Anwesenheit der Firewall-Vorrichtung 301 sowohl aus der Sicht der Daten als auch des Protokolls nicht. Der Zugriff auf das Registerarray 400 innerhalb der Firewall-Vorrichtung erfolgt andererseits mit einem anderen Betriebsmodell. Zugriffe auf das Registerarray 400 werden auf eine Art behandelt, die nachfolgend als „lokaler Modus"-Betrieb bezeichnet wird. In dem lokalen Modus kann der Port-A-Master 302 den Port-A-I²C-Bus 306, 310 für den Zugriff auf das interne Registerarray 400 verwenden. Die Firewall-Vorrichtung 301 leitet keine der mit dem Zugriff im lokalen Modus verbundenen I²C-Informationen an die Port-B-Schnittstelle 314 weiter. Dies steht im Gegensatz zu dem normalen „transparenten Modus" des Betriebs, in dem Adreß- und Datenbits transparent zwischen den Port-A- und Port-B-I²C-Schnittstellen 308 und 314 weitergereicht werden.
Die Firewall-Vorrichtung 301 wählt zwischen transparentem und lokalem Betriebsmodus, basierend auf der ersten Adresse, die sie nach einer anfänglichen START-Bedingung erhält, wobei eine anfängliche START-Bedingung als eine START-Bedingung definiert ist, die einer „bus-idle" bzw. „Bus-untätig"-Bedingung folgt. Wenn die erste empfangene Adresse in das durch das BASE-Register 404 definierte interne Indexregister 410 geht, dann wird die Firewall-Vorrichtung in den lokalen Betriebsmodus eintreten, in dem sie bleiben wird, bis die aktuelle Transaktion mit einer STOP-Bedingung beendet wird oder bis der Port-A-Master 302 einen erneuten START mit einer anderen Adresse als der von Indexregister 410 ausgibt, was auch immer zuerst geschieht. Normalerweise wird erwartet, daß der Port-A-Master 302 Aktivität im lokalen und transparenten Modus mittels separater I²C-Transaktionen, getrennt durch eine STOP-Bedingung, durchführt.
Die Firewall-Vorrichtung wird niemals mitten in einer I²C-Transaktion vom transparenten Modus zum lokalen Modus umschalten. Mit anderen Worten, wenn der Port-A-Master 302 auf das interne Registerarray 40 zugreifen möchte, muß jede laufende Aktivität im transparenten Modus von dem Port-A-Master 302 mittels einer STOP-Bedingung normal beendet sein, worauf der Zugriff im lokalen Modus mit einer neuen START-Bedingung eingeleitet werden kann.
Da das Verhalten der Firewall-Vorrichtung hauptsächlich von Software bestimmt wird, die der Mikrocontroller 301 programmiert, wird eine Übersicht dieser Software unten diskutiert. Da wie oben erwähnt die Taktgeschwindigkeit mit zwei unterschiedlichen Taktfrequenzen läuft: 5 MHz für Operationen auf den Port-B-Multimaster-Bus 312, 316 oder 20 MHz für Operationen auf den Port-A-Bit-Bang-Bus 306, 310, erlaubt die Firewall-Software im allgemeinen niemals eine Aktivität für beide I²C-Ports 308 und 314, mit einer Ausnahme. Insbesondere das selektive Anhalten der beiden mit der Vorrichtung 301 verbundenen I²C-Segmente 306, 310 und 312, 316 macht sich den oben beschriebenen Taktsynchronisierungsmechanismus zunutze und ermöglicht es der Firewall-Software, sich zu einer gegebenen Zeit immer nur mit einem Port zu beschäftigen.
Die Art und Weise, wie die Ports 308 und 314 angehalten werden, ist so, daß die Firewall-Software auf den Busmaster wartet, der den zugehörigen SCL-Stift bzw. -Anschluß treibt (Stift 19 im Fall von Port A 308 und Stift 10 im Fall von Port B 314), um den SCL-Buss in einen NIEDRIG-Zustand zu führen. Im Fall von Port-A 308 schreibt die Firewall-Software dann eine „0" auf die SCL-Leitung 306, um sie in einem NIEDRIG-Zustand zu blockieren bis zu dem Zeitpunkt, zu dem die Firewall-Software erlauben möchte, daß die Transaktion wieder weitergeht. Im Fall von Port-B 314 hält die interne I²C-Hardware in den Mikrocontroller 301 die Port-B-SCL-Leitung 312 in einem NIEDRIG-Zustand, bis die Hardware mittels der Software aktiviert ist. Somit ist die Firewall-Software in der Lage, Adreß- und/oder Datenbits zwischen den beiden Segmenten 306, 310 und 312, 316 hin und her zu schicken, wobei das eine Segment blockiert wird, während das andere bedient wird, und die Taktgeschwindigkeit verändert wird, um sich dem Port anzupassen, der bedient wird.
Es gibt einen Fall, in dem beide Ports 308 und 314 zur selben Zeit aktiv sein können. Am Ende der Transaktion wird der Port-A-Master 302 eine STOP-Bedingung einleiten. Wenn dies geschieht, muß die Firewall-Vorrichtung die STOP-Bedingung auf den Port-B-Bus 312, 316 übertragen, während sie gleichzeitig in der Lage ist, eine neue START-Bedingung auf dem Port-A-Bus 306, 310 zu handhaben. Aus diesem Grund ist die Port-A-SDA-Leitung 310 mit dem externen Unterbrechungseingang des Mikrocontrollers (Stift 8) mittels der Leitung 311 verbunden. Diese Unterbrechung wird nur möglich, nachdem eine mit der vorhergehenden Transaktion verbundene STOP-Bedingung auf dem Port-A-Bus 306, 310 erkannt wird.
Die Software-Routine, die die Unterbrechung bedient, muß den Abfrage-Mechanismus beim Zustandsübergang auf Port-A 308 nutzen und daher muß die Taktgeschwindigkeit weiterhin bei 20 MHz belassen werden, während die STOP-Bedingung auf den Port-B-Bus 312, 316 übertragen wird. Dies würde normalerweise zu einer ungültigen Bus-Zeitsteuerung auf dem Port-B-Bus 312, 316 führen, wenn die interne I²C-Hardware des Mikrocontrollers zum Generieren der STOP-Bedingung benutzt würde. Stattdessen erzeugt die Firewall-Software per „Bit-Bang" die STOP-Bedingung auf den Port-B-Bus 312, 316, wobei der Takt bei 20 MHz läuft. Wenn während dieses Intervalls ein neuer START auf dem Port-A-Bus 306, 310 auftritt, dehnt die Ausführungszeit der Unterbrechungsdienstroutine die Port-B-Stop-Bedingung leicht aus, aber dies hat keine Auswirkungen. Port-B 314 wird zu allen anderen Zeitpunkten während einer Transaktion direkt von der internen I²C-Steuerungs-Hardware (nicht gezeigt) des Mikrocontrollers getrieben, wobei der Takt mit 5 MHz läuft.
Die einzige in der bevorzugten Firewall-Software-Implementierung verwendete Unterbrechung ist zum Erkennen eines Port-A-START am Beginn einer Transaktion. Da ein START dadurch, daß die SDA-Leitung 310 von HOCH auf NIEDRIG geht, signalisiert wird, ist dieses Signal mit einem niedrig-wahr (im niedrigen Zustand wahren) Unterbrechungseingang an den Mikrocontroller 301 (Stift 8) verbunden. Ebenso aktiviert die Firewall-Software diese Unterbrechung nur nach einer vorangehenden STOP-Bedingung (oder nachdem diese aus einer Zurücksetz-Bedingung kommt), so daß im voraus bekannt ist, daß das nächste LOW-Niveau auf der Port-A-SDA-Leitung 310 ein START sein wird. Die Unterbrechungsdienstroutine überprüft jedoch, daß das kombinierte SCL/SDA-Leitungspaar 306, 310 einen gültigen START gebildet hat, bevor sie weitermacht.
Der Hauptteil der Firewall-Vorrichtungssoftware weist einen Software-Automaten auf, der synchron mit der Port-A-Schnittstelle 308 läuft. 5 ist ein Zustandsdiagramm, das den anfänglichen Adreßfluß zeigt. In diesem und den folgenden Diagrammen stellen die Ellipsen Zustände dar, die als ein Codeabschnitt definiert sind, der durch einen unten beschriebenen Zustand-Übergangsmechanismus zu einem anderen Zustand oder funktionalen Block springt. Ein funktionaler Block, im Diagramm als Rechteck dargestellt, ist ein Code-Abschnitt, der nicht durch den Zustand-Übergangsmechanismus endet, sondern stattdessen durch einen einfachen Sprung. Die meisten Bögen, die die Zustände und die funktionalen Blöcke verbinden, haben eine Notation der Form 0x, 10 oder 11. Diese Notation zeigt den Zustand der Port-A-SCL- beziehungsweise -SDA-Stifte an. Daher bedeutet ein Bogen mit der Bezeichnung 0x, die Software folgt dem Bogen, wenn SCL NIEDRIG ist und SDA HOCH oder NIEDRIG ist. Zustände und funktionale Blöcke mit gestrichelten Linien stellen Ziele dar, die in anderen Figuren vollständig beschrieben werden.
Das in der I²C-Busspezifikation definierte Signalisierungsverfahren ist dergestalt, daß sowohl die SCL- als auch die SDA-Leitung gleichzeitig beobachtet werden müssen, um START-und STOP-Bedingungen zu erkennen. Deshalb testet die Software, die die Bit-Bang-Port-A-Schnittstelle 308 anregt, beide Signale gleichzeitig zur Entscheidungsfindung hinsichtlich Transitionen des Port-A-Automaten. Zusätzlich wurde ein effizientes Verfahren zum Zustandswechsel des Port-A-Automaten basierend auf den abgetasteten Port-A-SCL/SDA-Daten benötigt, damit die Software mit der erforderlichen Bitrate von 100Kbit/sec auf dem Bus mithalten kann.
In einer bevorzugten Ausführungsform benutzt das ausgewählte Zustandsübergangsverfahren Sprungtabellen, die für jeden Zustand des Port-A-Software-Automaten speziell zugewiesen sind. Um auf beiden, den SCL- und den SDA-Stiften gleichzeitig zu agieren, benutzt die Software den Wert von SCL und SDA, die mit den Port#0-Bits des Mikrocontrollers <2:1> verbunden sind, als einen binäreren Abstand bzw. Offset in die Sprungtabelle. Beim Laden der Adresse der Sprungtabelle in das „dptr"-Register des Mikrocontrollers springt der einzelne Befehl „ jmp @a+dptr" zum korrekten Eintrag in der Sprungtabelle, der für den aktuellen Wert von SCL und SDA kodiert ist und damit zum nächsten Zustand übergeht.
5 zeigt die anfänglichen Adreßzustände und den Programmfluß. Die Software beginnt im Strom-an Zurücksetz-Zustand 500 und schreitet zum Initialisierungszustand 502 weiter. Von dem Initialisierungszustand schreitet die Software zu dem Leerlauf-Block 504 weiter, wo der Automat auf eine START-Bedingung vom Port-A-Master 302 wartet. Sobald START erscheint, wie von dem von der Unterbrechungsdienstroutine (unten beschrieben) gesetzten Besetzt-Flag angezeigt, schreitet der Code zum init_scl_low genannten Zustand 506 weiter.
Der init_scl_low-Zustand 506 initialisiert einfach die cnt- bzw. Zähler-Variable und geht dann zu den Zuständen 510 und 512 weiter, die Adreßbits akkumulieren, bis das gesamte anfängliche Adreß- und Lese-/Schreib-Bit vom Port-A-Master 302 empfangen wurde. Danach geht die Steuerung in den xmit-iaddr-Zustand 516 über.
In dem iaddr-zero-Zustand 510 wurde von dem Automaten ein Adreßbit '0' von Port-A-Master 302 empfangen. Der Wert des Adreßbits wird mittels eines Clear-Carry-Befehls in das Carry-Flag gesichert und dann wird der Übergangsmechanismus zum Fortschreiten in den nächsten Zustand aufgerufen oder wartet hier in diesem Zustand, wenn sich die SCL/SDA-Signale bei Port-A noch nicht geändert haben.
Die Sprungtabelle für den iaddr-zero-Zustand 510 hat vier mögliche Zielzustände und funktionale Blöcke, in die aus dem Zustand 510 die Steuerung übergehen kann. Die Software erreichte den Zustand 510, weil die SCL-Leitung bei niedriger SDA-Leitung HOCH ging, und damit ein „0"-Bit anzeigte, was in diesem Fall zufällig ein Adreßbit ist. Beim Übergang aus diesem Zustand bleibt die Steuerung im Zustand 510, wenn das SCL/SDA-Leitungspaar immer noch den Wert „10" hat, wie durch den Sprung zurück in den Zustand 510 nachgewiesen wird. In ähnlicher Art und Weise tritt eine STOP-Bedingung auf, wenn das SCL/SDA-Leitungspaar einen Übergang von „10" nach „11" signalisiert. Somit geht der Zustand 510 zu Block 514 über, der eine STOP-Bedingung vor Beendigung der anfänglichen Adresse behandelt.
In einem iaddr-one-Zustand 512 wurde von dem Automaten ein Adreßbit ,1' vom Port-A-Master 302 empfangen. Der Wert des Adreßbits wird im Carry-Flag mittels eines set-carry-Befehls gespeichert und dann wird der Übergangsmechanismus zum Fortschreiten in den nächsten Zustand aufgerufen oder wartet hier in diesem Zustand, wenn sich die SCL/SDA-Signale bei Port-A noch nicht geändert haben.
Die Sprungtabelle für den iaddr-one-Zustand 512 hat vier mögliche Zielzustände und funktionale Blöcke, an welche die Steuerung aus Zustand 512 übergehen kann. Die Software erreichte den Zustand 512, weil die SCL-Leitung bei hoher SDA-Leitung HOCH ging, und damit ein „1"-Bit anzeigte, was in diesem Fall zufällig ein Adreßbit ist. Beim Übergang aus diesem Zustand bleibt die Steuerung im Zustand 512, wenn das SCL/SDA-Leitungspaar immer noch den Wert „11" hat, wie durch den Sprung zurück in den Zustand 512 gezeigt wird. In ähnlicher Art und Weise tritt eine Neustart-Bedingung auf, wenn das SCL/SDA-Leitungspaar einen Übergang von „11" nach „10" signalisiert. Somit geht der Zustand 512 zurück zu Block 506, der die Neustart-Bedingung behandelt.
Der xmit-iaddr-Zustand 516 ist die erste Stelle in dem Code, in dem der Multimaster-Port-B-I²C-Bus verwendet wird. Nach dem Warten darauf, daß der Bus mittels der I²C-Vermittlung frei wird, wird die anfängliche Adresse auf dem Bus übertragen und ein Bestätigungs-Impuls (acknowledge, ACK oder NAK) von dem adressierten Abhängigen wird empfangen. Falls die Vermittlung während der Übertragung dieser anfänglichen Adresse negativ ausgeht, wird der Code in dem xmit-iaddr-Zustand 516 eine begrenzte Anzahl von Malen erneut versuchen, die Adresse mit Erfolg auf dem Bus zu übertragen. Dies ist die einzige Stelle im Design der Firewall-Vorrichtung, an der die Firewall eine Operation automatisch erneut versucht. Diese anfängliche Adresse wird hier erneut versucht, da ein Verlieren bei der Vermittlung während der anfänglichen Adreßphase einer Transaktion als normales, korrektes Verhalten in einem Multimastersystem betrachtet wird. Daher versucht Firewall wiederholt die Übertragung der anfänglichen Adresse, um übermäßiges Belasten des Port-A-Masters 302 mit NAKs zu vermeiden.
In dem xmit-iaddr-Zustand 516 hält die Software den Port-A-Bus 306, 316 an, indem sie den Port-A-SCL-Leitung 306 auf NIEDRIG treibt. Daher ist der Port-A-Master 302 gezwungen zu warten, während die Firewall-Vorrichtung mit dem Port-B-Bus 312, 316 in Verbindung steht. Dieses Verfahren des Anhaltens des Port-A-Busses, wenn die SCL-Leitung NIEDRIG geht, wird in fast allen Zuständen verwendet, in denen SCL beim Eintritt in den Zustand niedrig ist. Dies gibt der Software die Zeit, die sie zum Abschließen der mit dem Zustand verbundenen Arbeit benötigt, während sie den Port-A-Master 302 abhält, bis die Software bereit ist, in den nächsten Zustand weiterzugehen.
Im Anschluß an die erfolgreiche Übermittlung der anfänglichen Adresse leitet die Software das von der abhängigen Einrichtung empfangene ACK/NAK-Bit zurück an den Port-A-Bus 306, 310 und geht dann weiter zu Zustand 518, für den Fall, daß ein NAK empfangen wird oder geht weiter in den Zustand 524, für den Fall, daß ein ACK empfangen wird. Von den Zuständen 518 und 524 geht der Codefluß weiter in den pre_dat-lock 522, der die Datenverarbeitungsphase der Transaktion ist, oder in den Neustart-Zustand 520 für den Fall, daß ein wiederholter START empfangen wird.
Die 6A und 6B zeigen den Zustandsfluß für den Datenteil aller Transaktionen im transparenten Modus. Nachdem eine Adreßphase wie in 5 gezeigt zu Ende geht, geht die Kontrolle zu dem pre_dat-Block 522 über, was einfach den Bitzähler initialisiert und die Kontrolle entweder zu dem in 6A gezeigten Lesestrom leitet oder zu dem in 6B gezeigten Schreibfluß. Von diesem Punkt an fließt die Kontrolle für Lese- und Schreibvorgänge in ähnlicher Weise. Die Lese- und Schreibströme unterschieden sich leicht, um die unterschiedliche Übertragungsrichtung der ACK-Bits unterzubringen; ACK-Bits werden vom Port-A 308 zum Port-B 314 für Lesen getrieben und umgekehrt für Schreiben.
In dem in 6A dargestellten Lesefluß werden, anderes als in der anfänglichen Adreßphase, Datenbits in den Zuständen 602, 604 und 606 zwischen den Port-A- und Port-B- I²C-Bussen bitweise übergeben. Insbesondere in dem rgetbit-Zustand 602 dekrementiert der Code die cnt-Variable, erhält ein Port-B-Bit und überträgt das Bit an Port-A. Der Zustand 602 geht dann entweder in den Zustand 604 oder den Zustand 606 über abhängig davon, ob das Bit eine „1" oder „0" war. Die Zustände 604 und 606 erkennen, ob eine STOP- beziehungsweise eine START-Bedingung auftritt. Zum Beispiel zeigt ein Übergang der SDA-Leitung von NIEDRIG zu HOCH bei HOCH auf der SCL-Leitung eine STOP-Bedingung an. in diesem Fall geht der Zustand 604 weiter zu dem Stop-Verarbeitungsblock 616. Alternativ zeigt ein Übergang der SDA-Leitung von HOCH nach NIEDRIG bei HOCH auf der SCL-Leitung eine START-Bedingung an. In diesem Fall geht der Zustand 606 in den wiederholten START-Zustand 618 über.
Der Ablauf geht auf diese Weise weiter, bis die cnt-Variable Null erreicht, wobei an diesem Punkt der Zustand 602 in den Zustand 608 übergeht, in welchem der Code die SDA-Leitung 310 HOCH treibt und entweder auf ein ACK oder ein NAK vom Port-A-Master 302 wartet. In dem Fall, daß ein ACK empfangen wird, geht der Code zu dem Zustand 612 und zu dem Zustand 614 über. Wenn ein NAK empfangen wird, geht der Code zu dem Zustand 612 und dem Zustand 614 über. In beiden Zuständen 610 und 612 wird der Zustand der SDA-Leitung in dem Carry-Bit (Übertrags-Bit) gespeichert. Alternativ geht der Codefluß, wenn ein STOP in Zustand 610 empfangen wird, zur Verarbeitung der STOP-Bedingung zu dem Verarbeitungsblock 616 über. Wenn im Zustand 612 eine START-Bedingung empfangen wird, geht der Codefluß zum Zustand 618 über, um, wie unten diskutiert, die wiederholte START-Bedingung zu verarbeiten.
In Schritt 614 wurde entweder ein ACK oder ein NAK von dem Port-A-Master 302 empfangen. Das empfangene ACK oder NAK wird dann an die Port-B-Schnittstelle 314 zur Übertragung an die abhängige Einrichtung übertragen. Wenn ein ACK empfangen wurde, geht der Codefluß zurück zum Zustand 620, um zusätzlich Datenbytes zu verarbeiten. Am Ende einer Lese-Transaktion sendet der Port-A-Master 302 als Reaktion auf den Erhalt des letzten Datenbytes ein NAK an die abhängige Einrichtung, um der abhängigen Einrichtung zu signalisieren, daß sie aufhören sollte, Daten auf die SDA-Leitung einzuführen. Wenn dies eintritt, ist die Lese-Transaktion abgeschlossen und der Code tritt in einen Zustand w4ss 624 ein, in dem er nur nach einer START- oder einer STOP-Bedingung Ausschau hält. Eine START-Bedingung wird empfangen wie durch einen Übergang zu Zustand 628 und dann an Zustand 618 angezeigt, wo eine wiederholte START-Bedingung (unten diskutiert) verarbeitet wird. Alternativ geht der Code zum Zustand 626 und dann zu einem Stop-Block 616 zur Verarbeitung der Stop-Bedingung weiter, wenn eine STOP-Bedingung empfangen wird. In Zustand 614 verursacht ein Fehler in dem Empfang eines ACK- oder NAK-Signals einen Sprung zu einer gemeinsamen Fehlerroutine 622, die unten diskutiert wird.
In dem in 6B dargestellten Schreibdatenverarbeitungsfluß werden in ähnlicher Weise wie beim Leseverarbeitungsfluß in den Zuständen 632, 634 und 636 Datenbits von dem Port-A-I²C-Bus bitweise zum Port-B-Bus weitergeleitet. Besonders wenn eine „0" vom Port-A-Master 302 empfangen wurde, wie durch einen Übergang durch die Zustände 632 und 634 zum Zustand 640 angezeigt, speichert der Code das empfangene Bit im Carry-Flag, überträgt das gespeicherte Bit an Port-B und dekrementiert die cnt-Variable. Wenn eine „1" vom Port-A-Master 302 empfangen wurde, wie durch einen Übergang durch die Zustände 632 und 634 zum Zustand 640 angezeigt, speichert der Code das empfangene Bit im Carry-Flag, überträgt das gespeicherte Bit an Port-B und dekrementiert die cnt-Variable. Eine vom Port-A-Master generierte STOP-Bedingung erreicht, wie durch einen Übergang durch die Zustände 632 und 634 angezeigt, den Verarbeitungsblock 638, der die STOP-Bedingung behandelt. Alternativ erreicht eine vom Port-A-Master generierte START-Bedingung, wie durch einen Übergang durch die Zustände 632 und 634 angezeigt, den Zustand 642, der die START-Bedingung behandelt.
Die Operation wird auf die Art und Weise fortgesetzt, bis die cnt-Variable Null erreicht, woraufhin Zustand 640 zum Zustand 644 übergeht, in dem der Code entweder auf ein ACK- oder ein NAK von der abhängigen Einrichtung auf Port-B wartet und das ACK/NAK zum Port-A-Master überträgt. Nach der Übertragung des ACK oder NAK von der abhängigen Einrichtung an Port-B an den Port-A-Master 302 geht die Kontrolle zurück zum Verarbeitungsblock 652, um mit der Transaktion, wie vom Port-A-Master 302 vorgegeben, fortzufahren. Alternativ werden START- und STOP-Bedingungen, die während der Übergänge durch die Zustände 646 zu 650 und 648 zum Verarbeitungsblock 654 erkannt werden, von Zustand 650 beziehungsweise Verarbeitungsblock 654 behandelt.
Anders als der anfängliche START und die anfängliche Adreßphase einer I²C-Transaktion puffert die Firewall-Vorrichtung keine Adreßinformation nach einem wiederholten START. Dies folgt der allgemeinen Philosophie, daß die Firewall-Vorrichtung so wenige Daten wie möglich puffert, um so transparent wie möglich zu bleiben. Wie zuvor erwähnt, ist das Puffern der gesamten anfänglichen Adresse nötig, um das normale Verlieren bei der Vermittlung und wiederholte Versuche zu verbergen, die vor dem erfolgreichen Erwerb des Port-B-Multimaster-Busses auftreten können.
Der wiederholte Start-Zustand wird in 7 gezeigt. In diesen Zustand wird eingetreten, wenn der Übergangsmechanismus erkennt, daß sich Signale auf dem SCL-/SDA-Leitungspaar von „11" auf „10" verändert haben. Dieser Zustandsfluß ist sehr ähnlich dem in 6B gezeigten Schreibdatenfluß, jedoch vereinigt sich die Kontrolle nach dem Bewegen von 8 Adreßbits und einem ACK-Bit zwischen den beiden Ports mit demselben Zustandsfluß, wie dem nach einer anfänglichen Adresse benutzten.
Insbesondere beginnt der Codefluß im Zustand 700. Wenn das SCL-/SDA-Leitungspaar „11" wird, wird eine STOP-Bedingung empfangen und Zustand 700 geht zum Verarbeitungsblock 702 zum Verarbeiten der STOP-Bedingung über.
Ansonsten geht Zustand 700 zum Zustand 704 über, in dem die cnt-Variable zurückgesetzt wird und eine START-Bedingung auf der Port-B-Schnittstelle 314 ausgegeben wird. Vom Port-A-Master empfangene Daten werden mittels Übergängen durch Zustände 708 bis 712 im Falle eines „1"-Bits und durch Zustände 710 bis 712 im Falle eines „0"-Bits erkannt. Das empfangene Bit wird in den beiden Zuständen 708 und 710 im Carry-Flag gespeichert. Ein Fehler in einem der beiden Zustände 704 und 712 veranlaßt einen Übergang zum Verarbeitungsblock 706 zum Verarbeiten des Fehlers.
In Zustand 712 wird das gespeicherte Bit an Port-B übertragen und die cnt-Variabe wird dekrementiert. Wenn der Zähler Null erreicht, geht Zustand 712 zum Zustand 714 über, wo ein ACK/NAK von Port-B 314 empfangen und an Port-A 308 übertragen wird. Im Falle eines empfangenen NAK geht Zustand 714 zum Zustand 716 über, der derselbe ist wie Zustand 518, und die Verarbeitung geht von dort aus weiter. Im Fall eines empfangenen ACK geht Zustand 714 zum Zustand 718 über, der derselbe ist wie Zustand 524, und die Verarbeitung geht von dort aus weiter.
Jeder Fehler, der auf dem Port-B-Multimaster-Bus nach der anfänglichen Adreßphase auftritt, bewirkt, daß die Kontrolle an den gemeinsamen Fehlerzustandsfluß übergeht, abort_w4stop genannt, was für „abort and wait for a STOP condition" oder „Abbrechen und auf STOP-Bedingung warten" bedeutet, Dieser Zustandsfluß, dargestellt in 8, tut genau das, was der Name andeutet; jede ausgehende Port-B-Transaktion wird in Zustand 800 abgebrochen. Wenn die Firewall-Vorrichtung immer noch der Master auf dem Port-B-Bus ist, dann gibt sie die Kontrolle des Busses auf, indem sie auf dem Bus eine STOP-Bedingung sendet. Die momentane Port-A-Transaktion wird auch abgebrochen, indem auf die Port-A-SDA- und SCL-Leitungen HOCH geschrieben wird.
Der Codefluß geht dann zum Zustandsfluß des Zustandes 802 über, der auf eine STOP-Bedingung wartet. Auf jeden/jedes wiederholte START, Adreßbit oder Datenbit, die der Port-A-Master 302 lesen oder schreiben kann, wird von der Firewall-Vorrichtung geantwortet, wie durch einen Übergang zum Zustand 804 angezeigt, indem eine NAK-Antwort so lange zurückgegeben wird, bis der Port-A-Master 302 die Transaktion mittels einer STOP-Bedingung beendet.
Dieser Fehlerfluß bewirkt zwei Dinge. Erstens übersetzt er jedwede Port-B-Fehlerbedingung in Port-A-NAK-Bits, die während der momentanen Port-A-Transaktion bestehen bleiben. Da die Port-B-Fehlerbedingung dazu führte, daß die Firewall-Vorrichtung die Herrschaft über den Multimasterbus verloren hat, ist die Firewall-Vorrichtung nicht in der Lage, auf weitere Bytes in der aktuellen Transaktion einzuwirken. Zusätzlich wird die Software der Firewall-Vorrichtung mit dem Port-A-Master 302 neu synchronisiert, indem sie darauf wartet, daß der Port-A-Master ein STOP ausführt. Sobald die STOP-Bedingung erkannt wird, wird die doreti-Routine aufgerufen, wie durch einen Übergang zum Verarbeitungsblock 806 angezeigt, was das System möglicherweise in eine Leerlauf-Bedingung bringt, wie durch einen Sprung in den Zustand 808 angezeigt.
Zusätzlich zu dem in 8 gezeigten Fehlerbehandlungs-Zustandsfluß hat die Software verschiedene Zeitgeber zur Erfassung von Zeitüberschreitungen, die eingebaut sind, um zu verhindern, daß auf beiden Seiten pathologische Protokollverletzungen die Firewall-Vorrichtung aufhängen. Zum Beispiel ist es in einer Ein-Master-I²C-Bus-Implementierung möglich, den Bus aufzuhängen, wenn der Master eine Lese-Transaktion zu dem Abhängigen initiiert und dann den Transfer abbricht, ohne dem korrekten Protokoll zu folgen, was in diesem Fall heißt, auf das letzte Byte mit einem NAK zu antworten und dann eine STOP-Bedingung zu generieren. Wenn die abhängige Einrichtung Nullen als Daten einführt, dann wird sie die SDA-Leitung niedrig halten, während sie auf die nächste ansteigende SCL-Flanke wartet. Wenn es der Master versäumt, ein NAK auf das letzte gewünschte Byte zu senden, und dabei versäumt, die abhängige Einrichtung zu informieren, das Treiben der SDA-Leitung einzustellen, dann kann der Abhängige fortfahren, die SDA niedrig zu halten. Dies macht es dem Master unmöglich, eine START- oder STOP-Bedingung einzuleiten, und der Bus wird effektiv aufgehängt. Der einzige Ausweg aus diesem Szenario besteht für den Master darin, die Aufgehängt-Bedingung zu erkennen und die Taktimpulse so lange zu stimulieren, bis der Abhängige damit aufhört, SDA NIEDRIG zu treiben, was er während des ACK-Taktimpulses tun wird, bei dem der Master ein STOP ausgeben kann und den Bus wieder einer nützlichen Verwendung zuführen kann. Unglücklicherweise sind viele I²C-Master nicht ausgeklügelt genug, um diese Prozedur zum Wiederherstellen des Busses durchzuführen.
In einer bevorzugten Ausführungsform benutzt die Firewall-Vorrichtung einen in dem Mikrocontroller 301 eingebauten Überwachungs-Zeitgeber, um zu erkennen, wann der Port-A-Automat für etwa eine Sekunde in einem nicht-Leerlauf-Zustand bleibt, wobei sich der Mikrocontroller 301 einem Rücksetzen der Hardware unterzieht. Dieses Rücksetzen gibt die Port-A-SCL- und -SDA-Leitungen 306, 310 frei und erlaubt dem Port-A-Master, seine Transaktion erneut zu versuchen. Es ist daher wesentlich, daß der Port-A-Master niemals seine eigene Transaktion in irgendeinem gegebenen Zustand für mehr als eine Sekunde anhält, da dies die Firewall-Vorrichtung zum Rücksetzen bringen würde.
Fehler bei Port-B 314 wie Verlieren bei der Vermittlung und asynchrone START/STOP-Fehler werden von der in den Mikrocontroller 310 eingebauten I²C-Schnittstelle signalisiert und mittels des in 8 abgebildeten Fehlerzustandsflusses behandelt. Zusätzlich zu diesen Fehlertypen implementiert die Software eine Software-Zeitüberwachung beim Warten auf besondere Vorkommnisse, wie beim Warten auf abfallende oder ansteigende SCL-Flanken auf dem Port-B-I²C-Bus. Wenn eines dieser Ereignisse die Zeit überschreitet, dann geht die Kontrolle in den Fehlerzustandsablauf über.
In einer bevorzugten Ausführungsform dürfen zwei Timeout- bzw. Zeitüberschreitungs-Werte auf dem Port-B-Bus 312, 314 nicht überschritten werden, um die Firewall-Vorrichtung davon abzuhalten, in ihren Fehlerablauf einzutreten. Dies sind, (1) daß keine abhängige Port-B-Einrichtung eine Transaktion mit der SCL-Leitung 312 anhalten soll, die für mehr als 100 Millisekunden während eines einzelnen Taktzyklus' niedrig gehalten wird, und (2) daß kein Port-B-Master eine Transaktion durchführen darf, die länger als 200 Millisekunden dauert.
Wird der Anforderung (1) nicht Genüge getan, führt dies dazu, daß die Firewall-Vorrichtung annimmt, daß der Multimasterbus während einer Transaktion hängengegeblieben ist, in der er aktuell der Master ist, und sie daher ihre Prozedur zur Bus-Wiederherstellung einleitet. Wird der Anforderung (2) nicht Genüge getan, führt dies dazu, daß die Firewall-Vorrichtung annimmt, daß der Multimasterbus hängengegeblieben ist, während sie darauf wartet, der Master zu werden, was dazu führt, daß sie die Verarbeitung der Transaktion anhält und mit NAKs auf alle Adreß- und Datenbytes antwortet, die mit der aktuellen Port-A-Transaktion verbunden sind.
Die Unterbrechungsdienstroutine wird in 9 dargestellt. Diese Routine wird während der anfänglichen Adreßverarbeitung zum Erkennen eines gültigen START verwendet. Der Unterbrechungszustand 900 wird anfänglich mittels einer Hardware-Unterbrechung eingeleitet, die von einem NIEDRIG-Niveau auf dem externen Unterbrechungsstift (irq Stift 8 dargestellt in 3) auf dem Mikrocontroller 301 verursacht wird, welcher Stift mit der Port-A-SDA-Leitung 310 verbunden ist. Da die Unterbrechung nur nach einer STOP-Bedingung ermöglicht wird, erkennt die Unterbrechung zuverlässig eine START-Bedingung.
Wenn eine Start-Bedingung erkannt wird, geht Zustand 900 zum Zustand 904 über, in welchem die Unterbrechungsroutine die SCL-Datenleitung 306 NIEDRIG treibt und ein „besetzt"-Flag setzt, um die Tatsache der in 5 gezeigten Hauptschleife der anfänglichen Adreßverarbeitung anzuzeigen. Wenn der unterbrochene Softwarefluß damit beschäftigt war, die STOP-Bedingung der vorangegangenen Transaktion auf dem Port-B-Bus 312, 316 zu Ende zu bringen, ist der Port-A-Master 302 gezwungen zu warten, bis die Firewall-Vorrichtung aufholt. Nach dem Abschluß einer STOP-Transaktion auf dem Port-B-Bus 312, 316 geht die Kontrolle zur Hauptschleife in 5 über, die in Zustand 504 bleibt und auf die Anzeige wartet, daß von der Unterbrechungsserviceroutine eine neue Transaktion auf Port-A 308 begonnen wird.
Alternativ nimmt die Software an, wenn es in Zustand 900 den Anschein hat, daß die Unterbrechung eher bei einem Datenbit auftrat als bei einer START-Bedingung, daß die Synchronisation zwischen dem Port-A-Automaten und dem Port-A-Master 302 verloren gegangen ist, und gibt somit die Kontrolle an den Fehlerzustand 902 weiter, um durch Warten auf eine STOP-Bedingung ein erneutes Synchronisieren zu erzwingen.
Die 10A–10C zeigen, wie der mit den Lese- und Schreib-Transaktionen verbundene Zustandsfluß von dem Port-A-Master 302 in das interne Registerarray 400 getrieben wird. Dieser Zustandsfluß beginnt in Zustand 1000 und geht zum Zustand 1002 über, wenn der Port-A-Master eine Adresse generiert, die dem lokalen Indexregister entspricht. In Zustand 1002 sendet die Firewall-Vorrichtung ein ACK an den Port-A-Master und gibt die Port-A-SCL-Leitung 306 frei. Der Code geht durch den Zustand 1004 während eines Übergangs auf der SCL-Leitung 306 von HOCH zu NIEDRIG, was eine START-Bedingung vom Port-A-Master signalisiert. Die Verarbeitung der vom Port-A-Master gesandten Daten wird beginnend in Verarbeitungsblock 1006 ausgeführt, was genauer zu den 10B und 10C beschrieben wird, abhängig davon, ob die Transaktion ein Lesevorgang oder ein Schreibvorgang ist.
In dem in 10B dargestellten Lesefluß bzw. -ablauf werden in den Zuständen 1008, 1010 und 1012 Datenbits aus den Registern bitweise an den Port-A-Bus weitergegeben. Insbesondere dekrementiert der Code in dem Lrgetbit-Zustand 1008 die cnt-Variable, erhält ein Bit von dem entsprechenden Register und überträgt das Bit an Port-A. Der Zustand 1008 geht dann entweder zum Zustand 1010 oder Zustand 1012 über, abhängig davon, ob das Bit eine „1" oder eine „0" war. Die Operation geht auf diese Art und Weise weiter, bis die cnt-Variable Null erreicht, an welchem Punkt der Zustand 1008 zum Zustand 1014 übergeht, in dem der Code entweder auf ein ACK oder ein NAK vom Port-A-Master 302 wartet.
Der Fall, in dem ein ACK empfangen wird, wird durch einen Übergang durch Zustand 1016 zum Zustand 1022 angezeigt. Ein NAK wird angezeigt durch einen Übergang durch Zustand 1018 zum Zustand 1022. Alternativ geht, wenn ein STOP in Zustand 1016 empfangen wird, der Codefluß zum Verarbeitungsblock 1020 über, um die STOP-Bedingung zu verarbeiten. Wenn im Zustand 1018 eine START-Bedingung empfangen wird, geht der Codefluß zur Verarbeitung der START-Bedingung in den Zustand 1024 über. Zustand 1024 entspricht Zustand 506 in 5 und die Verarbeitung geht von dort weiter.
In Verarbeitungsblock 1022 wurde entweder ein ACK oder ein NAK vom Port-A-Master 302 empfangen. Das Indexregister 410 wird dann inkrementiert und es werden Vorkehrungen getroffen, auf ein vom Port-A-Master 302 empfangenes NAK zu antworten. Wenn ein ACK empfangen wurde, geht der Codefluß zurück zu Zustand 1026, um zusätzliche Datenbytes zu verarbeiten. Am Ende einer Lese-Transaktion wird der Port-A-Master 302 als Antwort auf den Empfang des letzten Datenbytes ein NAK an die Firewall-Vorrichtung senden, um der Firewall-Vorrichtung zu signalisieren, daß sie aufhören sollte, Daten auf die SDA-Leitung zu treiben. Wenn dies geschieht, ist die Lese-Transaktion komplett und der Code tritt in Zustand w4ss 1028 ein, in dem er einfach auf eine STOP- oder START-Bedingung wartet. Eine START-Bedingung wird empfangen, wie durch Übergang zu Zustand 1032 und dann zu Zustand 1024 angezeigt. Alternativ geht der Code zu Zustand 1030 und dann zu einem Stop-Block 1020 zur Verarbeitung der Stop-Bedingung über, wenn eine STOP-Bedingung empfangen wird.
In dem in 10C dargestellten Verarbeitungsfluß bzw. -ablauf der Schreibdaten werden Datenbits in ähnlicher Art und Weise wie beim Lese-Verarbeitungsfluß in den Zuständen 1034, 1036 und 1038 von dem Port-A-I²C-Bus Bit-für-Bit an die Register 400 übergeben. Insbesondere, wenn eine „0" vom Port-A-Master 302 empfangen wird, was durch Übergang durch die Zustände 1034 und 1036 zum Zustand 1042 angezeigt wird, speichert der Code das empfangene Bit im Carry-Flag, akkumuliert die Bits und dekrementiert die cnt-Variable. Wenn eine „1" vom Port-A-Master 302 empfangen wird, was durch Übergang durch die Zustände 1034 und 1038 zum Zustand 1042 angezeigt wird, speichert der Code das empfangene Bit im Carry-Flag, akkumuliert die gespeicherten Bits und dekrementiert die cnt-Variable. Eine vom Port-A-Master generierte STOP-Bedingung, was durch Übergang durch die Zustände 1034 und 1036 angezeigt wird, erreicht den Verarbeitungsblock 1040, der die STOP-Bedingung behandelt. Alternativ erreicht eine vom Port-A-Master generierte START-Bedingung, wie durch Übergang durch die Zustände 1034 und 1038 angezeigt, den Zustand 1044, der, wie zuvor beschrieben, die START-Bedingung behandelt.
Die Operation geht auf diese Art und Weise weiter, bis die cnt-Variable Null erreicht, an welchem Punkt der Zustand 1042 zum Zustand 1046 übergeht, in dem ein ACK-Signal an den Port-A-Master 302 gesendet wird. Die akkumulierten Daten werden dann in dem entsprechenden Register gespeichert und das Indexregister wird dekrementiert. Wenn kein STOP empfangen wird, bereitet der Code das Senden zusätzlicher Daten durch Übergang zum Verarbeitungsblock 1050 vor (zurück zu Block 1006). Wenn eine STOP-Bedingung empfangen wird, geht der Zustand 1048 zum Verarbeitungsblock 1052 über.
Wie in diesem Fluß bzw. Ablauf ersichtlich, wird das Indexregister nach jedem dem ACK/NAK-Bit folgenden Lese-Datenbyte und nach jedem Schreib-Datenbyte kurz vor dem Senden des ACK-Bits inkrementiert.
Die folgenden drei 11, 12 und 13 zeigen tatsächliche Oszilloskopaufzeichnungen einer Implementierung einer bevorzugten Ausführungsform im Betrieb. In diesen Diagrammen ist die Port-A-Seite der Firewall, gezeigt in Form der untersten beiden Aufzeichnungsspuren, mit einem Port-A-Master 302 verbunden. Die Port-B-Seite, gezeigt in den beiden obersten Aufzeichnungsspuren, ist mit dem Multimaster-I²C-Segment verbunden, das zwei weitere Master in dem System enthält.
11 zeigt die anfängliche Adreßphase einer vom Port-A-Master 302 getriebenen Transaktion. In diesem Fall ist die vom Port-A-Master getriebene Adresse 20 hex. Vor der ersten abfallenden Flanke auf der SDA-Leitung 310 bleibt der Firewall-Vorrichtungsautomat in dem idle-Zustand 504 (5) und wartet darauf, daß das Besetzt-Flag gesetzt wird. Wenn die SDA-Leitung 306 anfänglich NIEDRIG geht, wird ein Interrupt bzw. eine Unterbrechung an dem Mikrocontroller 301 generiert, wie zuvor beschrieben. Diese Unterbrechung führt dazu, daß die Kontrolle an den in 9 gezeigten Unterbrechungsdienstroutinenfluß übergeht. Nachdem der Port-A-Master 302 die SCL-Leitung 306 NIEDRIG treibt, hält die Unterbrechungsdienstroutine die Transaktion an, indem sie die SCL-Leitung 306 NIEDRIG hält, das Besetzt-Flag setzt und die Kontrolle zurück an den idle-Zustand 504 zurückgibt. Dieser anfängliche Adreßfluß von 5 geht dann weiter, um alle sieben Adreßbits und das Lese-/Schreib-Bit zu konsumieren, bevor der Port-A-Bus 306, 310 angehalten wird.
Als nächstes erwirbt die Firewall-Vorrichtung den Port-B-Multimaster-Bus und treibt erneut die Adresse auf den SDA- und SCL-Leitungen 312, 316. Nach dem neunten Taktpuls auf dem Port- B-Bus übergibt die Firewall-Vorrichtung das auf dem Port-B-Bus 314 empfangene NAK-Bit an den Port-A-Bus 308. Man beachte an diesem Punkt, daß der Multimaster-Bus von der Firewall-Vorrichtung angehalten wird, während der Port-A-Bus läuft und darauf wartet, daß die Systemsoftware den Port-A-Master bedient, um ein Fortschreiten der Transaktion zu ermöglichen.
12 zeigt den Betrieb der Firewall-Vorrichtung während einer vom Port-A-Master 302 getriebenen wiederholten Start-Bedingung. In diesem Beispiel ist eine vom Port-A-Master 302 getriebene Transaktion bereits im Gang und wird an das Multimaster-I²C-Bussegment 314 übergeben. Zur Linken der Figur treibt der Port-A-Master 302 eine wiederholte START-Bedingung zur Ausgabe einer neuen Adresse während der laufenden Übertragung. Die Firewall-Vorrichtung erkennt diesen wiederholten START und übergibt die Kontrolle an den in 7 gezeigten Fluß. Im Fluß von 7 ist ersichtlich, daß die dieser wiederholten START-Bedingung folgenden Adreßbits Bit-für-Bit von Port-A 308 an Port-B 314 übergeben werden. Daher erschient die von der Firewall-Vorrichtung der Transaktion hinzugefügte Latenz als ein Ausdehnen der NIEDRIG-Anteile auf den Port-A- und Port-B-SCL-Leitungen 306 und 312. Während dieser NIEDRIG-Zeiten auf den SCL-Leitungen 306, 312 bedient die Firewall den anderen Port.
13 zeigt den Betrieb der Firewall-Vorrichtung, wenn der Port-A-Master versucht, eine Transaktion zu einer Zeit zu starten, zu der der Port-B-I²C-Multimaster-Bus besetzt ist. Dieses Diagramm beleuchtet einen wichtigen Aspekt der Erfindung. Wie in 13 aus den Signalen auf den Multimaster-SDA- und SCL-Leitungen 312, 316 ersichtlich, ist der Port-B-Bus 314 bereits mit einer Transaktion zu dem Zeitpunkt belegt, an dem der Port-A-Master 302 eine neue Transaktion startet. In diesem Fall ist die auf dem Port-B-Bus ablaufende Transaktion ein 32-Byte-Lesen einer abhängigen Einrichtung (nicht gezeigt) durch einen der Port-B-Master (nicht gezeigt). 13 zeigt, wie die Firewall-Vorrichtung die von dem Port-A-Master 302 getriebenen Adressen absorbiert und dann die Transaktion auf Port-A anhält, bis sie in der Lage ist, die Adresse auf dem Port-B-Bus 314 erfolgreich zu erwerben und zu treiben.
Anschließend wird der Transaktion auf Port-A erlaubt fortzufahren. Somit ist der Port-A-Master 302 von der Last befreit, Zusammenstöße bzw. Kollisionen zu behandeln oder den busylidle-Zustand von Multimaster-Bus 314 zu verfolgen. Der Port-A-Master 302 startet einfach eine neue Transaktion, und wenn der Multimaster-Bus gerade beschäftigt ist, wird der Port-A-Master 302 angehalten, bis Besitz an dem Multimaster-Bus erworben wurde.
Obwohl eine exemplarische Ausführungsform der Erfindung offenbart wurde, wird Fachleuten auf diesem Gebiet ersichtlich, daß verschiedene Änderungen und Modifikationen vorgenommen werden können, die einige der Vorteile der Erfindung erreichen werden, ohne von dem Zweck der beanspruchten Erfindung abzuweichen. Zum Beispiel wird gut bzw. hinreichend ausgebildeten Fachleuten auf dem Gebiet ersichtlich, daß in anderen Implementierungen ein anderer Mikrocontroller verwendet werden kann. Andere Aspekte wie der spezifische Zustandsfluß ebenso wie andere Modifikationen des erfindungsgemäßen Konzeptes der Erfindung sollen von den anhängenden Ansprüchen abgedeckt werden.

Claims

Vorrichtung für die Verbindung einer Einrichtung (202), die einen einzigen Busmaster hat, mit einer Multimaster-I²C-Busumgebung (204), mit: einer Schnittstelle (208) für einen Anschluß A, welche Adreß- und Datensignale von der Einrichtung empfängt und Bestätigungs- und negative Bestätigungssignale an die Einrichtung sendet, einer Schnittstelle (214) eines Anschlusses B, welche Adreß- und Datensignale an den Multimaster-Bus (212, 216) sendet und Fehler des Multimaster-Busses in der Multimaster-Bus-Umgebung erfaßt, und einer Steuerung (201), die in transparenter Weise Adreß- und Datensignale, welche an der Schnittstelle des Anschlusses A von der Einrichtung empfangen werden, an die Schnittstelle des Anschlusses B weiterleitet für die Übermittlung an den Multimaster-Bus und welche die Schnittstelle des Anschlusses A steuert, um ein negatives Bestätigungssignal an die Einrichtung zu senden, wenn auf dem Multimaster-Bus ein Fehler erfaßt worden ist und Daten- und Adreßsignale von der Einrichtung empfangen werden.
Vorrichtung nach Anspruch 1, wobei die Steuerung Datensignale, die auf der Schnittstelle des Anschlusses B von dem Multimaster-Bus empfangen wurden, in transparenter Weise an die Schnittstelle des Anschlusses A weiterleitet für das Senden an die Einrichtung, wenn kein Fehler auf dem Multimaster-Bus erfaßt worden ist.
Vorrichtung nach Anspruch 1 oder 2, wobei die Schnittstelle des Anschlusses B einen Belegt-Mechanismus aufweist, um zu erfassen, wenn der Multimaster-Bus belegt ist.
Vorrichtung nach Anspruch 3, welche weiterhin einen Verarbeitungsmechanismus aufweist, der betrieben werden kann, wenn der Belegt-Mechanismus erfaßt, daß der Multimaster-Bus belegt ist, um Adreßsignale aufzunehmen, die von der Einrichtung empfangen wurden und um die Einrichtung in einen Haltezustand zu bringen, bis der Multimaster-Bus nicht mehr belegt ist (516).
Vorrichtung nach Anspruch 4, wobei die Einrichtung mit der Schnittstelle des Anschlusses A durch eine Taktleitung (SCL) und eine Datenleitung (SDA) verbunden ist und wobei der Verarbeitungsmechanismus die Einrichtung durch Steuerung der Taktleitung in einen Haltezustand bringt (516).
Vorrichtung nach einem der vorstehenden Ansprüche, wobei die Steuerung eine Zustandsmaschine aufweist.
Vorrichtung nach Anspruch 6, wobei die Zustandsmaschine einen programmierten Mikrocontroller aufweist.
Vorrichtung nach Anspruch 7, wobei die Einrichtung mit der Schnittstelle des Anschlusses A durch eine Taktleitung und eine Datenleitung verbunden ist und wobei die Einrichtung durch Steuern der Takt- und der Datenleitung ein START-Signal erzeugt, und wobei das START-Signal durch den Mikrocontroller erfaßt wird, indem auf der Basis eines Signals auf der Datenleitung ein Interrupt erzeugt wird (311).
Vorrichtung nach einem der vorstehenden Ansprüche, welche weiterhin einen Busbeschaffungsmechanismus aufweist, der arbeiten kann, wenn der Master des Anschlusses A eine Transaktion auslöst, welche automatisch versucht, den Multimaster-Bus für eine vorbestimmte Anzahl von Malen zu beschaffen (516), wenn der Multimaster-Bus belegt ist und wenn eine Vermittlung abhanden gekommen ist.
Vorrichtung nach einem der vorstehenden Ansprüche, wobei die Steuerung aufweist: einen programmierbaren Mikrocontroller (301) mit einer durch Software gesteuerten Schnittstelle (308) des Anschlusses A, welche Adreß- und Datensignale von der Einrichtung empfängt und Bestätigungs- und negative Bestätigungssignale an die Einrichtung überträgt, und mit einer durch Hardware gesteuerten Schnittstelle des Anschlusses B, welche Adreß- und Datensignale an den Multimaster-Bus sendet und Fehler des Multimaster-Busses in der Multimaster-Bus-Umgebung erfaßt, und ein Zustandsmaschinenprogramm, welches in dem Mikrocontroller läuft, und welches in transparenter Weise Adreß- und Datensignale, die auf der Schnittstelle des Anschlusses A von der Einrichtung empfangen wurden, an die Schnittstelle des Anschlusses B weiterleitet für das Senden auf dem Multimaster-Bus, und die Schnittstelle des Anschlusses A steuert, um ein negatives Bestätigungssignal an die Einrichtung zu senden, wenn auf dem Multimaster-Bus ein Fehler erfaßt wird und Daten- und Adreßsignale von der Einrichtung empfangen werden.
Vorrichtung nach Anspruch 10, wobei der programmierbare Mikrocontroller eine interne Uhr (322, 324, 326) hat, die eine Taktgeschwindigkeit hat und den Mikrocontroller steuert, und wobei das Zustandsmaschinenprogramm die interne Taktgeschwindigkeit steuert, um eine erste Geschwindigkeit zu haben, wenn Adreß- und Datensignale an der Schnittstelle des Anschlusses A empfangen werden, und um eine zweite Geschwindigkeit zu haben, wenn Adreß- und Datensignale an der Schnittstelle des Anschlusses B empfangen werden.
Vorrichtung nach Anspruch 10 oder 11, wobei der Multimaster-Bus einen Belegt-Zustand hat und wobei das Zustandsmaschinenprogramm den Belegt-Zustand des Multimaster-Busses erfaßt und Adreßsignale, welche von der Einrichtung empfangen werden, auffängt und die Einrichtung in einen Haltezustand bringt, bis der Multimaster-Bus nicht mehr im Belegt-Zustand ist (516).
Vorrichtung nach Anspruch 12, wobei die Einrichtung Adreß- und Datensignale auf einer Taktleitung (SCL) und einer Datenleitung (SDA) erzeugt und wobei das Zustandsmaschinenprogramm die Einrichtung in einen Haltezustand bringt, indem sie die Taktleitung steuert.
Vorrichtung nach einem der Ansprüche 10 bis 13, welche weiterhin eine Busbeschaffungseinrichtung aufweist, die betrieben werden kann, wenn die Einrichtung mit einem einzelnen Busmaster eine Transaktion auslöst, welche automatisch für eine vorbestimmte Anzahl von Malen versucht, den Multimaster-Bus für eine vorbestimmte Anzahl von Malen zu beschaffen bzw. auf diesen zuzugreifen, wenn der Multimaster-Bus belegt ist und wenn eine Vermittlung verlorengegangen ist (516).
Verfahren zum Verbinden einer Einrichtung (202), welche einen einzelnen Busmaster hat, mit einer I²C-Busumgebung (204) mit Mehrfach-Busmaster, welches aufweist: (a) Erfassen von Fehlern des Multimaster-Busses in der Multimaster-Bus-Umgebung (646), (b) Empfangen von Adreß- und Datensignalen von der Einrichtung (632) und Senden der empfangenen Adreß- und Datensignale an den Multimaster-Bus (640), wenn auf dem Multimaster-Bus kein Fehler erfaßt wird (648), und (c) Senden eines negativen Bestätigungssignals (NACK) an die Einrichtung, wenn ein Fehler auf dem Multimaster-Bus erfaßt wird und Daten- und Adreßsignale von der Einrichtung empfangen werden (804).
Verfahren nach Anspruch 15, welches weiterhin aufweist: (d) transparentes Senden von Datensignalen, die von dem Multimaster-Bus empfangen wurden, an die Einrichtung, wenn auf dem Multimaster-Bus kein Fehler erfaßt wird (602).
Verfahren nach Anspruch 15 oder 16, welches weiterhin aufweist: (f) Erfassen, wenn der Multimaster-Bus belegt ist (516).
Verfahren nach Anspruch 17, welches weiterhin aufweist: (g) Auffangen von Adreßsignalen, welche von der Einrichtung empfangen werden, wenn der Multimaster-Bus belegt ist (516), und (h) Anhalten der Einrichtung, bis der Multimaster-Bus nicht mehr belegt ist (516).
Verfahren nach Anspruch 18, wobei die Einrichtung Adreß- und Datensignale auf einer Taktleitung (SCL) und einer Datenleitung (SDA) erzeugt, und wobei der Schritt (h) das Anhalten der Einrichtung durch Steuern der Taktleitung umfaßt.
Verfahren nach einem der Ansprüche 15 bis 19, wobei die Schritte (a), (b) und (c) durch eine Zustandsmaschine ausgeführt werden.
Verfahren nach Anspruch 20, wobei die Zustandsmaschine einen programmierten Mikrocontroller aufweist.
Verfahren nach Anspruch 21, wobei die Einrichtung ein START-Signal erzeugt, indem sie einen Takt und eine Datenleitung steuert und wobei das Verfahren weiterhin das Erfassen des START-Signals aufweist, indem auf der Basis eines Signals auf der Datenleitung ein Mikrocontroller-Interrupt erzeugt wird (311).
Verfahren nach einem der Ansprüche 15 bis 22, welches weiterhin aufweist: (i) Auslösen einer Transaktion in Reaktion auf den Master an Anschluß A, für eine vorbestimmte Anzahl von Malen automatisches Versuchen, den Multimaster-Bus zu beschaffen, wenn der Multimaster-Bus belegt ist und wenn eine Vermittlung verloren gegangen ist (516).