-
Gebiet der
Erfindung
-
Diese
Erfindung betrifft Kommunikationsgeräte im Allgemeinen und betrifft
Kommunikationsgeräte
mit einer Mehrzahl von Unterabschnitten im Besonderen.
-
Hintergrund
der Erfindung
-
Die
Notwendigkeit für
diese Erfindung entstand aus Problemen der Hochgeschwindigkeitskommunikation
zwischen registermodellierten Funkgeräten. Aktuelle registermodellierte
Funkkommunikationsgeräte kommunizieren
zueinander mittels Kommunikationsprotokolle, die Informationspakete
variabler Länge
enthalten. Mit Fortschritten in den Komponententechnologien können Funkkommunikationsgeräte nun Speicherkomponenten
in Größen verwenden,
die früher
für tragbare
oder mobile Funkanwendungen nicht realisierbar waren. Insbesondere
elektronisch löschbare,
programmierbare Nurlesespeicher ("Electronically Erasable Programmable
Read Only Memories (EEPROMs)")
und Flash-Speicher sind nun in Größen verfügbar, in denen das Betriebssystem
eines Kommunikationsgerätes
gespeichert werden kann. In Geräten,
in denen das Funkgerät
mittels registermodellierter Protokolle programmiert wird, ist unter
Verwendung gegenwärtig
verfügbarer Protokolle
für Nachrichten
fester Länge
eine beträchtliche
Menge an Zeit erforderlich. Das Zeiterfordernis ergibt sich aus
dem signifikanten Overhead, der bei dem Nachrichtentransfer fester
Länge,
wie er gegenwärtig verfügbar ist,
benötigt
wird. Diese Protokolle für
Nachrichtentransfers fester Länge
werden in den U.S. Patenten Nr. 4,637,022 und Nr. 4,684,941 beschrieben.
Um die Programmierzeit des Funkgeräts wesentlich zu reduzieren,
sind ein verbessertes registermodelliertes System und ein Verfahren
der Kommunikation zwischen den registermodellierten Komponenten
erwünscht,
die die Mängel
des Standes der Technik bewältigen
würden.
-
Die
WO 90 06027 offenbart ein lokales Netzwerk mit mehreren dynamisch
wählbaren
Betriebskapazitäten.
Mehrere verschiedene Betriebskapazitäten, wie Datentransferraten
oder Kommunikationsprotokolle, sind für die Verwendung auf einem
einzelnen, eine Mehrzahl von Knoten umfassenden LAN wählbar. Verbesserte
Knoten des LAN haben die Fähigkeit,
beim Kommunizieren mit anderen Knoten entweder eine verbesserte
Leistungsfähigkeit
oder eine gebräuchliche
Leistungsfähigkeit
zu verwenden. Diese Grundknoten, die nicht von der verbesserten
Art sind, verfügen
unter Verwendung der gebräuchlichen
Leistungsfähigkeit über die
Fähigkeit
des Kommunizierens. Die verbesserten Knoten wählen für die wirksamste Kommunikation
mit anderen Knoten dynamisch die Betriebskapazität aus.
-
Zusammenfassung
der Erfindung
-
In
einem ersten Aspekt stellt die vorliegende Erfindung ein Funksystem,
wie in Anspruch 1 beansprucht, zur Verfügung.
-
In
einem weiteren Aspekt stellt die vorliegende Erfindung ein Verfahren
zum Betreiben eines Funkkommunikationsgerätes, wie in Anspruch 11 beansprucht,
zur Verfügung.
-
Kurze Beschreibung
der Zeichnungen
-
1 ist
ein Blockdiagramm eines registermodellierten Kommunikationssystems
gemäß der vorliegenden
Erfindung.
-
2 zeigt
ein sehr vereinfachtes Blockdiagramm eines Programmier-Teilsystems
gemäß der vorliegenden
Erfindung.
-
3 zeigt
ein Flussdiagramm eines zum Ändern
von Kommunikationsprotokollen verwendeten Verfahrens gemäß der vorliegenden
Erfindung.
-
4 zeigt
ein Flussdiagramm eines zum Ändern
der Kommunikationsbaudrate verwendeten Verfahrens gemäß der vorliegenden
Erfindung.
-
5, 6 und 7 zeigen
Timingdiagramme für
ein Verfahren zum Eintreten in den erweiterten Serienbusprotokoll-("Serial Bus Expanded Protocol (SBEP)")Modus gemäß der vorliegenden
Erfindung.
-
8, 9 und 10 zeigen
Timingdiagramme des Verlassens des SBEP-Modus gemäß der vorliegenden
Erfindung.
-
11 zeigt
in dem Protokoll verwendete Musternachrichten gemäß der vorliegenden
Erfindung.
-
12 und 13 zeigen
Ausstrahlungen gemäß der vorliegenden
Erfindung.
-
14 zeigt
eine SBEP-Rückmeldung
gemäß der vorliegenden
Erfindung.
-
15 und 16 zeigen
Wiederholungstimingdiagramme gemäß der vorliegenden
Erfindung.
-
17 zeigt
das Bestätigungstiming
gemäß der vorliegenden
Erfindung.
-
18 zeigt
ein Negativbestätigungstiming
gemäß der vorliegenden
Erfindung.
-
19 zeigt
ein Rücksetzausstrahlungstiming
gemäß der vorliegenden
Erfindung.
-
20, 21 und 22 zeigen
eine erste Speicherprogrammierungs-Bustransaktion mit guten Schreibrückmeldungen
gemäß der vorliegenden
Erfindung.
-
23, 24 und 25 zeigen
eine zweite Speicherprogrammierungs-Bustransaktion mit guten und
schlechten Schreibrückmeldungen
gemäß der vorliegenden
Erfindung.
-
Beschreibung einer bevorzugten
Ausführungsform
-
Bezug
nehmend auf 1 wird ein Funkkommunikationsgerät 100 gezeigt,
das einen Satz definierter adressierbarer Unterabschnitte gemäß der vorliegenden
Erfindung aufweist. Diese Figur zeigt eine konzeptionelle Architektur
zum Integrieren gegenwärtiger
und zukünftiger
Systemoptionen und Befehls-/Steuer-Teilsysteme mit gemeinsamen Verknüpfungen
in ein strukturiertes, vereinheitlichtes, mobiles oder tragbares
Zweiwege-Funksystem.
-
Gezeigt
werden drei Unterabschnitte, ein Steuerungsunterabschnitt 150,
ein externer Optionsunterabschnitt 180 und ein Funkunterabschnitt 200.
Diese Unterabschnitte stellen die registermodellierte adressierbare
Prozessoreinrichtung der vorliegenden Erfindung bereit. Diese Unterabschnitte
werden als registermodellierte Prozessoren betrachtet, da sie als
Register betrachtet werden können,
sofern ihr wechselseitiger Sprachverkehr betroffen ist. Die Inhalte
dieser Unterabschnitte können
dann zum Definieren der von dem Funkgerät 100 durchzuführenden
Betriebe verwendet werden. Der virtuelle Zustand des Geräts 100 und/oder
der Unterabschnitte 150, 280 und 200 kann
jeweils durch das Kommunizieren von Information an die und von der
Mehrzahl von Unterabschnitten bestimmt oder geändert werden. Diese Kommunikation
wird über
einen seriellen Bus 230 gemäß der vorliegenden Erfindung
durchgeführt.
Diese Grundstruktur verleiht dem Funksystem 100 die Fähigkeit,
ohne unnötige
Redundanzen über
eine Vielfalt verschiedener Funkgeräte, Funktionen, Eigenschaften
und Verstärkungen
in einem einzelnen Funksystem zu verfügen.
-
Jeder
Unterabschnitt umfasst eine Mikroprozessoreinheit ("microprocessor unit
(MPU)") und ein
oder mehrere Speicherkomponenten umfassende Register. Der Steuerungsunterabschnitt 150 umfasst
eine Steuerungs-MPU 158, ein Display 152, eine
Tastatur 156 und eine Speicherkomponente 154.
Die Tastatur umfasst irgendwelche der Kombination numerischer, alphanumerischer,
Funktions-Tasten oder Tasten zur Eigenschaftsaktivierung, wie PTT
(PTT = "Push-To-Talk"). Die externe Option
wird eine MPU 182 umfassend gezeigt. Andere Register können diesem
Unterabschnitt hinzugefügt
werden, sowie die Notwendigkeit eintritt. Der Funk unterabschnitt 200 umfasst
einen Empfänger 204,
eine MPU 206 und verschiedene Speicherkomponenten 208, 210 und 212.
Diese Speicherkomponenten sind über
einen, Steuer-, Adressen- und Daten-Leitungen umfassenden Bus 214 an
die MPU 206 gekoppelt. Die MPUs 158, 182 und 206 sind
vorzugsweise adressierbar, um das Kommunikationssystem 100 mit
Eins-zu-Eins-Kommunikation
zwischen seinen Unterabschnitten 150, 180 und 200 auszustatten.
-
Zum
Handhaben der Inhalte irgendeiner der Speicherkomponenten in den
Unterabschnitten 150, 180 und 200 ist
ein Satz Betriebscodes (Op-Codes) definiert worden. Diese Anweisungen
werden zum Datentransfer und zur Systemsteuerung verwendet. Diese
Op-Codes umfassen Rücksetzen,
Lesen, Schreiben (Ändern), Bitsetzen,
Bitlöschen,
Bestätigung
(BST) und Negativbestätigung
(NBST). Diese Op-Codes werden über
den seriellen Bus 230 übertragen,
um zu bewirken, dass in Bezug auf irgendein adressiertes Register
in irgendeinem der Unterabschnitte Daten hineingeschrieben, ausgelesen,
modifiziert oder getestet werden.
-
Die
Funktionen der verschiedenen Unterabschnitte werden durch die Inhalte
der auf dem seriellen Bus 230 kommunizierten Nachrichten
gesteuert. Diese Nachrichten können
einzelne Anweisungen oder Kombinationen ähnlicher einfacher Funktionen
(Makros) sein. Diese Eigenschaft schafft für einen Unterabschnitt die
Fähigkeit,
auf neue "Befehle" zu reagieren, ohne
tatsächlich
den neuen Befehls-Op-Code zu implementieren. Dies bewirkt, dass
der Satz einfacher Anweisungen stabil bleibt und die Aufwärtskompatibilität der Peripherieeinheiten 180 begünstigt.
-
Die
Funk-MPU 206 verbindet sich direkt mit dem Empfänger 204 und
einem optionalen Sender und führt
viele der ei nem bestimmten Empfänger
zugeordneten Grundtasks aus. Diese Tasks können die Synthesizersteuerung
für die
Erzeugung der Betriebsfrequenz, die Steuerung des Sendeleistungspegels,
die Tonstummschaltung, die Kanalabtastung, das Timing der Empfangs-/Sende-
und der Sende-/Empfangs-Folge, die Erzeugung und Erfassung einer
tiefstfrequenten bzw. nicht hörbaren
Signalgebung (PL/DPL Codes), Hardware-Diagnose etc. umfassen.
-
Die
Funk-MPU 206 stellt ferner eine Schnittstelle zu dem seriellen
Bus 230 bereit, in dem jeder der einschlägigen Tasks
für die
Steuerungs-MPU 158 oder andere MPUs 182 verfügbar ist.
Diese Tasks umfassen Speicherabfrage, Programmieranweisungen, Handhabung
von Anzeigenachrichten, Handhabung von Tastaturnachrichten etc.
-
Die
Steuerungs-MPU 158 liefert die menschliche Schnittstelle
an das Funksystem 100 zuzüglich Befehle an alle Unterabschnitte 180 und 200.
Ihre Funktionen umfassen die Steuerung des Displays 152,
das dem Anwender die auf dem seriellen Bus 230 empfangenen
oder örtlich
erzeugten Daten und Zustandsinformation anzeigt. Die MPU 158 empfängt ferner
Daten und Steuerungsinformation von der Tastatur 156 und
routet sie selektiv zu dem Display 152 oder dem Bus 230 zur
weiteren Verarbeitung durch andere Unterabschnitts-MPUs.
-
Irgendwelche
und alle außergewöhnlichen
Parameter des Funksystems 100, wie Frequenzinformation,
Einheits-ID-Codes, PL/DPL-Codes, Modusverknüpfungen, Abtastlisten etc.
werden allen Systemperipherieeinheiten durch den Funkprozessor 206 zur
Verfügung
gestellt. Er stellt die Datenbank des Systems 100 bereit
und überträgt diese
Information über
den Bus 230 für
andere MPUs zum Überwachen.
Ein Beispiel wird durch die auf der Funk-MPU 206 residenten
PL/DPL-Treiber zur Verfügung
gestellt. Der gesamte Satz möglicher
Codes für
PL und DPL kann fest in den EEPROM 208 oder den ROM 212 programmiert
werden. Diese Datenbank des EEPROM 208 und des ROM 212 wird
von dem seriellen Bus 230 für andere, diese Information benötigende
MPUs zugänglich
sein.
-
Analoge
Steuerungsfunktionen, wie Volumen und Rauschunterdrückung können von
der Tastatur 156 aus in digitaler oder analoger Form gesteuert
werden. Analoge, diese Steuerfunktionen darstellende Signale können direkt
von der Tastatur 156 über
direkte nicht gezeigte Signalleitungen an das Funkgerät 200 gekoppelt werden.
Alternativ dazu können
analoge Signale durch einen Analog/Digital-Wandler (DAC) in der
Steuerungs-MPU 158 in eine digitale Form umgewandelt und
dann auf dem seriellen Bus 230 an das Funkgerät 200 gesendet
werden. Das Display 152 wird durch die Steuerungs-MPU 158 gesteuert
und ist über
den Bus 230 durch andere MPUs in dem System 100 für Zustands-
und Überwachungs-Zwecke
sowie für
Tastatureingabe-Feedback zugänglich.
-
Die
MPU 182 der externen Option liefert die Unterstützung für die Option 180 und
Erweiterungen des Funksystems 100. Hauptsächliche
Kommunikationsfunktionen, wie Programmieren der Funk- und Steuer-Einheit,
digitale Sprachspeicherung, Telefonsignalgebung, Mehrfrequenz- und
Einzelfrequenz-Trunkierung etc. sind alles Beispiele der Funktionen,
die durch den externen Optionsunterabschnitt 180 unterstützt werden
können.
-
Der
serielle Bus 230 stellt die physikalische Schnittstelle
aller MPUs 158, 182 und 206 in dem Funksystem 100 bereit.
Er besteht aus einer Dreileiterverbindung (Signal, Besetzt und Masse)
und kann per Bus mit anderen internen oder externen nicht gezeigten
Unterabschnitten verbunden werden. Bei externer Verwendung kann
das Kabel eine verdrillte Doppelleitung, eine abgeschirmte Ton-
oder eine Glasfaseroptikleitung sein. Die Verbindung kann auch über Infrarot,
Ultraschall oder HF ferngekoppelt werden. Spezielle Anwendungen
können
diese Anforderungen noch vermehren. Zum Beispiel kann in einer Mobilfunkanwendung
die Signalleitung in abgeglichene Signal+/Signal-Leitungen geteilt
werden, gemeinhin auch als Bus+/Bus-Leitungen bezeichnet, um eine
ergänzende
Signal-Rausch-Unterdrückung
zu bilden. Die Signalleitung(en) ist die bidirektionale Leitung,
auf der die tatsächlichen
seriellen Daten gesendet und empfangen werden. In dem SB9600-Modus
wird die bidirektionale BESETZT-Leitung verwendet, um anzuzeigen,
wenn sich Daten auf der Signalleitung befinden. Sie zeigt an, wenn
der Beginn und das Ende einer Transaktion stattfinden und sie wird ebenfalls
verwendet, um eine NBST anzuzeigen. In der bevorzugten Ausführungsform
verwenden alle die Signal- und Besetzt-Leitungen anzapfenden Unterabschnitte,
interne oder externe, eine "verdrahtete
ODER" Konfiguration.
-
Der
serielle Bus 230 kann verwendet werden, wann immer bei
den MPUs 158, 182 und 206 in dem System 100 untereinander
oder zwischen irgendwelchen dieser MPUs und einer externen MPU(s)
ein Kommunikationsbedarf besteht. In dem SB9600-Modus erfolgt die
Kommunikation mittels serieller, bei 9600 Bits pro Sekunde (BPS)
auf dem bidirektionalen seriellen Bus 230 gesendeter Daten.
Die Architektur ist allgemein genug, dass viele verschiedene Anwendungen
vorgesehen werden können.
Der Zugriff auf verschiedene Prozessoren in dem System wird über die
bidirektionale Datenleitung und eine bidirektionale Besetzt-Leitung
mittels Techniken er halten, die CSMA/CD ("Carrier Sense, Multiple Access with
Collision Detection"),
was häufig in
lokalen Computernetzwerken verwendet wird, ähnlich und in der Technik bekannt
sind.
-
Die
auf dem seriellen Bus 230 durchgeführte Kommunikation verwendet
zwei Protokolle. Anfänglich wird
das SB9600-Protokoll
fester Länge,
das von allen Unterabschnitten verstanden wird, verwendet. Ein zweites
Protokoll, das erweiterte Serienbusprotokoll ("Serial Bus Expanded Protocol (SBEP)"), kann durch zwei MPUs
auf einmal verwendet werden. Wenn die Verwendung des SBEP-Protokolls
gewünscht
wird, wird mittels des SB9600-Protokolls von der veranlassenden
MPU ("Host") an die empfangende
MPU (Ziel) eine Nachricht gesendet, die eine Änderung an dem SBEP-Modus fordert.
Diese Nachricht wird über
ein Informationspaket fester Länge
gesendet. Die empfangende Einheit fährt fort, die Anweisung des
Informationspakets fester Länge
zu beachten. In der bevorzugten Ausführungsform fordert dieses Informationspaket
von der empfangenden Einheit, auf eine zweite SBEP-Betriebsart zu schalten.
Sobald auf diesen Modus geschaltet ist, können Nachrichten variabler
Länge bei
verschiedenen Baudraten kommuniziert werden, was die Kommunikation
zwischen den Unterabschnitten beträchtlich beschleunigt. Das zusammen
mit anderen Eigenschaften des SBEP-Protokolls umschaltende Protokoll
wird später
erläutert.
-
Um
für die
vorliegende Erfindung ein besseres Verständnis zu vermitteln, wird hiermit
eine Zusammenfassung der Eigenschaften des SB9600-Protokolls abgegeben.
Dieses Protokoll ist nicht mit dem SBEP-Protokoll zu verwechseln,
das später
in allen Einzelheiten erörtert
werden wird.
-
Ein
Gerät greift
zuerst durch Prüfen,
um zu erkennen, dass die BESETZT-Leitung inaktiv ist (auch "frei" genannt) auf den
Bus zu. Falls sie nicht frei ist, muss das Gerät eine Zeitspanne abwarten,
bevor es einen erneuten Versuch machen kann. Falls sie frei ist,
muss es BESETZT sofort aktiv schalten, auf der BUS-Leitung senden
und dann die BESETZT-Leitung freigeben.
-
Der
Grundbaustein, auf dem das SB9600 aufgebaut ist, ist das 8-Bit Datenbyte.
Das Datenbyte mit den Start- und Stopp-Bits (insgesamt 10 Bits)
wird als "Datenpaket" bezeichnet. Diese
Pakete werden verknüpft,
um eine einzelne "Nachricht" zu bilden. Nachrichten
bestehen typischerweise aus:
einem Op-Code-Paket,
einem
Adressenpaket,
Daten-(Argumenten-)Paketen,
und einem zyklischen
Redundanzcode-("Cyclic
Redundancy Code (CRC)")Paket.
-
Die
zwei in dem System 100 zugelassenen Nachrichtentypen sind
Anforderungen und Ausstrahlungen. Anforderungen werden verwendet,
um Information von anderen Prozessoren in dem System zu beziehen. Eine
Ausstrahlung ist entweder eine Reaktion auf eine spezielle Anforderung
(angeforderte Ausstrahlung oder Rückmeldung) oder wird spontan
erzeugt und an alle Geräte
in dem System gesendet (unaufgeforderte Ausstrahlung), wie etwa,
wenn ein Druckknopf betätigt
wird.
-
Die
BESETZT-Leitung in dem seriellen Bus 230 ist eine bidirektionale
Leitung, die hauptsächlich
dazu dient, anzuzeigen, wenn eine Nachricht auf dem Bus existiert.
Bevor eine Nachricht auf dem Bus gesendet werden kann, muss ein
Gerät,
das zu senden wünscht,
zuerst prüfen,
um zu erkennen, ob die BESETZT-Leitung aktiv ist. Falls sie nicht
aktiv ist, schaltet das Gerät
die BESETZT-Leitung aktiv und sendet die Nachricht. Falls ein Gerät auf seine
Sendung eine Reaktion erwartet, muss die BESETZT-Leitung nach dem
Empfang des ersten Bytes der Rückmeldung
freigegeben werden oder ein Timer läuft ab. Falls keine Reaktion
erwartet wird, muss die BESETZT-Leitung nach dem Versenden des letzten
Pakets der Nachricht freigegeben werden. Die BESETZT-Leitung wird ferner
dazu verwendet, für
eine NBST zu formulieren und zu testen.
-
Wenn
eine Nachricht einen CRC-Fehler aufweist oder falls eine Interpaketverzögerungsverletzung vorkommt,
muss das Empfangsgerät
sofort die BESETZT-Leitung aktiv schalten. Nach dem Senden der Ausstrahlung
wird der ursprüngliche
Sender die BESETZT-Leitung freigeben und dann abtasten, um zu erkennen, ob
sie nach wie vor aktiv gehalten wird, wodurch angezeigt wird, dass
die Nachricht nicht ordnungsgemäß empfangen
wurde. Falls die BESETZT-Leitung nach wie vor aktiv gehalten wird,
dann wird die Nachricht NBSTt, und der ursprüngliche Sender kann die Nachricht
erneut senden. Zu beachten ist, dass während Neusendungen BESETZT
niemals den Zustand ändert
(immer aktiv). Sobald eine zulässige
Nachricht empfangen worden ist, sollten alle nachfolgenden Nachrichten
ignoriert werden, bis BESETZT den Zustand ändert.
-
Fehler
treten aufgrund äußerer Rauschquellen,
Kollisionen oder unsachgemäßer Systemanwendung auf.
Fehler in der Datensendung werden durch den CRC, durch Timing-Verletzungen
oder durch Erfassung einer Kollision erfasst. Die Erfassung einer
Kollision wird durch Überwachen
der gesendeten Information an der MPU des Veranlassers erzielt.
Wenn ein derartiger Fehler auftritt, wird eine negative Bestätigung (NBST) gesendet.
Eine NBST besteht aus dem Aktivschalten der BESETZT-Leitung während der
einer Ausstrahlung folgenden "NBST-Periode". Die bloße Präsenz einer
aktiven BESETZT in diesem Zeitintervall zeigt an, dass wenigstens
ein Zuhörer
einen Fehler erfasste. Eine NBST hat zur Folge, dass jegliche Ausstrahlung
neu gesendet wird.
-
Falls
Rauschen den Bus verstümmelt
oder falls zwei oder mehrere MPUs zum selben genauen Zeitpunkt die
Steuerung des Busses übernehmen,
dann wird der empfangene CRC nicht der erwartete sein. Während dem
Senden muss jedes Paket dem vorherigen Paket innerhalb 1 Paketzeit
(Interpaketverzögerung)
folgen. Falls eine "Interpaketverzögerungsverletzung" vorkommt, muss der
Empfänger
sofort NBST. Wann immer eine Interpaketverzögerungsverletzung vorkommt,
muss die empfangen Nachricht außer
Acht gelassen werden und der Empfänger muss zum Empfang einer
neuen Nachricht neu initialisiert werden.
-
Jede
Option, jeder Steuerkopf und jedes Funkgerät in dem System weist eine
ihr bzw. ihm zugewiesene Gruppe und Geräteadresse auf. Keine zwei Optionen
können
die gleiche Geräteadresse
und Gruppe haben. Geräteadressen
werden mit einer Nachricht versendet, wenn es erforderlich ist,
ein bestimmtes Gerät
zu spezifizieren.
-
Bezug
nehmend auf 2 ist ein Programmierer 195 über den
seriellen Bus 230 an das Funkgerät 100 gekoppelt. Das
Funkgerät 200 kann
mittels des Programmierers 195 und des SBEP-Protokolls
gemäß der Erfindung
programmiert werden. Das Funkgerät 200 wird
gemäß der vorliegenden
Erfin dung über
den seriellen Bus 230 an den Programmierer 195 gekoppelt
gezeigt. Der Programmierer 195 ist als externe Option 180 an
das Funkgerät 200 gekoppelt.
In dieser Ausführungsform
ist der Programmierer 195 als Host tätig, da sie Programmiernachrichten
in Form von Informationspaketen erzeugt. Andererseits funktioniert
das Funkgerät 200 als
Ziel, da es die durch den Programmierer 195 ausgegebenen
Programmierbefehle empfängt
und ausführt.
-
Beim
Programmieren des Funkgeräts 200 fordert
der Programmierer 195 mittels des SB9600-Protokolls, des
ersten und eine feste Baudrate aufweisenden Kommunikationsprotokolls
eine Änderung
in dem Kommunikationsprotokoll an. Mit anderen Worten, das Funkgerät 200 ist
frei und erwartet den Empfang der SB9600-Information von irgendeinem
der auf dem Bus 230 operierenden Unterabschnitte. Das Funkgerät 200 bestätigt den
Empfang der Protokolländerungsanforderung
an den Programmierer 195. Mit dieser Bestätigung schalten
sowohl der Programmierer 195 als auch das Funkgerät 200 auf
den SBEP-Modus, dem zweiten und eine variable Länge aufweisenden Kommunikationsprotokoll.
Mit sowohl dem Programmierer 195 als auch dem Funkgerät 200 in
dem SBEP-Modus beginnt das Programmieren. Die von dem Programmierer 195 kommunizierten
Programmierinformationen sind Teilpakete umfassende Informationspakete.
Diese Teilpakete enthalten ein Op-Code-Teilpaket variabler Länge, ein
Teilpaket variabler Länge
in Nachrichtengröße, ein
Datenteilpaket, eine Adresse, ein Fehlererfassungsteilpaket etc.
Eine ausführlichere
Beschreibung dieses Handshakes und dieser Programmierung wird durch
Bezugnahme auf die Flussdiagramme von 3 und 4 beschrieben,
wobei diese FIG. den Eintritt in den SBEP-Modus beschreiben.
-
Bezug
nehmend auf 3 wird nun ein Flussdiagramm
des durch den Programmierer 195 verwendeten Ablaufs zum
Durchführen
eines erfolgreichen Wechsels und Kommunikation auf dem SBEP gezeigt.
Das Programmieren des Funkgeräts 200 verwendet
den Kommunikationsbereich des Flussdiagramms 600. Des Weiteren
resultiert dieses Programmieren in der Änderung des virtuellen Zustands
des Funkgeräts 200.
Von einem Startblock 601 aus sendet der Host über den
Block 602 eine SB9600-Nachricht, die einen Wechsel zu dem
SBEP-Modus anfordert. Das Funkgerät 200 bestätigt den
Empfang dieser SB9600-Nachricht, indem die Nachricht nicht NBSTt
wird. Diese Bestätigung
(Fehlen der NBST) zeigt an, dass das Funkgerät 200 über den Block 604 eine
Nachricht ohne Fehler empfing. Der Ausgang von Block 604 ist
an einen Block 606 gekoppelt, in dem der Programmierer 195 eine
Besetzt-Leitung aktiviert. Diese Besetzt-Leitung wird verwendet,
um andere Geräte
zu informieren, dem seriellen Bus 230 fernzubleiben, während der
Programmierer 195 an das Funkgerät 200 kommuniziert.
Indem die Besetzt-Leitung aktiviert ist, sendet der Host SBEP-Nachrichten, Block 614.
-
Ab
Block 614 bestimmt ein Bedingungsblock 616, ob
in den SBEP-Nachrichten von dem Programmierer 195 irgendwelche
Fehler empfangen wurden. Der NEIN-Ausgang, der anzeigt, dass die
von dem Programmierer 195 an das Funkgerät 200 übermittelten
Nachrichten mit Fehlern empfangen wurden, ist an einen Block 618 gekoppelt,
in dem das Funkgerät 200 an
den Programmierer 195 eine SBEP-Negativbestätigungsnachricht
(NBST) zurücksendet,
die anzeigt, dass einige Fehler in der empfangenen Nachricht erfasst
wurden. Diese Negativbestätigung
ist eine SBEP-NBST, die wie irgendeine andere in dem SBEP-Modus
kommunizierte Nachricht ein Datenbyte ist. Die Erfassung von Fehlern
kann mittels irgendeines von verschiedenen verfügbaren, in der Technik wohlbekannten
Verfahrens erzielt werden. In der bevorzugten Ausführungsform
wird die Prüfsummenfehlererfassung
verwendet, bei der Prüfsummenpakete
kommuniziert werden. Andere Fehlererfassungstechniken, wie das zyklische
Redundanzprüfungs-("Cyclic Redundancy
Check (CRC)")Paket
können bei
gleicher oder besserer Fehlererfassungsleistung durch Prüfsummenpakete
ersetzt werden. Als Teil der Durchführung von Block 618 wird
die Anzahl von NBST-Versuchen um einen erhöht. Wie viele Male eine NBST von
dem Ziel an den Host gesendet wird, wird als nächstes mittels Block 620 und
Block 621 überwacht.
Block 620 und Block 621 werden implementiert,
um die Anzahl von Versuchen zu begrenzen, wenn in der Verbindung zwischen
dem Funkgerät 200 und
dem Programmierer 195 ein signifikantes Problem besteht,
das die Nachrichten verstümmelt,
während
sie weitergeleitet werden. Dieses Problem kann ein physikalisches
in dem seriellen Bus oder der Verbindung zugefügtes Rauschen sein, wobei beide
sich wiederholende Fehler verursachen. Die Anzahl von Versuchen
wird basierend auf den Eigenschaften eines bestimmten Systems ausgewählt. In
der bevorzugten Ausführungsform
werden drei Versuche zugelassen, bevor ein Flag, das eine hohe Anzahl
von Versuchen mit Fehlern anzeigt, gesetzt wird. Die hohe Anzahl
von Fehlern erzeugt den JA-Ausgang des Bedingungsblocks 621,
der an den Block 610 gekoppelt ist, in dem der Host die
Besetzt-Leitung freigibt und den SBEP-Modus bestimmt. An dieser
Stelle muss von dem Host eine neue Änderungsanforderung gesendet
werden, um den Wechsel von dem SB9600- zu dem SBEP-Modus neu zu
initiieren.
-
Der
JA-Ausgang des Bedingungsblocks 616 ist an Block 624 gekoppelt,
in dem von dem Funkgerät 200 eine
Bestätigung
(BST) an den Programmierer 195 gesendet wird. Es ist klar,
dass an dieser Stelle oder an irgendeiner Stelle vor Block 614 die
Anzahl von Versuchen auf Null gesetzt wird. Die den Block 616 und den
Block 624 koppelnde Strecke umfasst einen Block, der die
Anzahl von Versuchen löscht,
nicht gezeigt. Sobald die BST zurückgesendet worden ist, wird
das Funkgerät 200 über Block 626 den
durch die SBEP-Nachricht
angeforderten Betrieb durchführen.
In dem speziellen Fall des Programmierens fährt das Funkgerät 200 fort,
die Programmierinformationen von dem Programmierer 195 zu
empfangen und sie in dem RAM 210 und dem EEPROM 208 zu
speichern.
-
Block 626 ist
an einen Bedingungsblock 628 gekoppelt, in dem eine Entscheidung
bezüglich
der Erfordernisse des Programmierers 195 getroffen wird.
Abhängig
von der Art von Nachricht, die an das Funkgerät 200 weitergeleitet
wurde, kann eine neue Rückmeldung
erwartet werden. Im Allgemeinen ist eine Rückmeldung erforderlich, wenn
durch den Host eine Anforderung gesendet worden ist. Jedoch erfordert
eine Ausstrahlung keine Rückmeldung.
Mehr Einzelheiten über
verschiedene Nachrichtentypen werden folgen. Der Bedingungsblock 628 bestimmt,
ob die übermittelte
Nachricht eine Reaktion von dem Funkgerät 200 erfordert. Der
JA-Ausgang ist an einen Block 630 gekoppelt, in dem das
Funkgerät 200 eine
Rückmeldung
an den Programmierer 195 zurücksendet. Von diesem Block
aus ist der Betrieb an einen Bedingungsblock 608 gekoppelt, in
dem eine Entscheidung dahingehend getroffen wird, ob alle Hostanforderungen
abgearbeitet worden sind. Der JA-Ausgang von Block 608 ist
an Block 610 gekoppelt, in dem der Host 195 die
Besetzt-Leitung freigibt, um die Beendigung des SBEP-Modus anzuzeigen.
Ein Block 612 folgt, der sowohl den Host als auch das Ziel auf
den SB9600-Modus zurückführt. Der
NEIN-Ausgang des Bedingungsblocks 608 wird an Block 614 zurückgekoppelt.
-
Obwohl
es sein kann, dass es beim Programmieren des Funkgeräts 200 für das Funkgerät nicht
notwendig ist, dem Host mit einem bestimmten Informationspaket zu
antworten, ist es in anderen Aspekten der Erfindung völlig klar,
dass der Programmierer 195 von dem Funkgerät 200 sehr
wohl Informationen anfordern kann. Eine solche Anwendung ist ein
durch den Programmierer 195 ausgegebener Lesebefehl, der
fordert, dass ein Bereich des Speichers in irgendwelchen der Unterabschnitte
des Funksystems 100 auf sie zurück übertragen wird. In dieser Situation
ist erkennbar, dass das Funkgerät 200 fortfährt, die
Inhalte seines Speichers auf den Programmierer 195 zurück zu übertragen.
Sobald eine Rückmeldung
an den Programmierer 195 zurückgesendet worden ist, kehrt
der Betrieb zu dem Bedingungsblock 608 zurück, um zu
bestimmen, ob die letzten der Anforderungen von dem Host abgearbeitet
worden sind. Der NEIN-Ausgang des Bedingungsblocks 628 wird
ebenfalls zurück
an den Bedingungsblock 608 gekoppelt.
-
Ein
signifikanter Aspekt des Flussdiagramms 600 ist, dass die
zwischen dem Programmierer 195 und dem Funkgerät 200 hin
und her gesendeten Nachrichten eine variable Länge genießen können und daher jede Nachricht
eine vollständige
Anforderung von dem Programmierer 195 oder eine vollständige Reaktion
von dem Funkgerät 200 enthalten
kann. Im Gegensatz zu gegenwärtig
verfügbaren
Systemen, bei denen Nachrichten fester Länge hin und her kommuniziert
werden und in einem beträchtlichen
Overhead auf dem Kommunikationsprotokoll resultieren, ist dies signifikant.
Die durch das SBEP-Protokoll ermöglichten
Vorteile der variablen Länge
ermöglichen
das Programmieren eines Funkkommunikationsgeräts im Vergleich zu gegenwärtig verfügbaren Konzepten
in einem beträchtlich
kürzeren
Zeitraum. Ein weiterer Nutzen der vorliegenden Erfindung ist, dass
Funkkommunikationsgeräte
nun wirksam in dem Bootstrap-Modus programmiert werden können.
-
Bezug
nehmend auf 4 und das Flussdiagramm 500 wird
ein Verfahren zum Ändern
der in dem Kommunikationsprotokoll zwischen den registermodellierten
Komponenten des Funksystems 100 verwendeten Baudrate gemäß der vorliegenden
Erfindung gezeigt. Von einem Startblock 501 aus sendet
der Host über Block 502 eine
SBEP-Nachricht, die ein Schalten auf eine neue Baudrate anfordert.
Wie erkennbar ist, nimmt der Block 502 an, dass der Host
bereits einen Wechsel zu dem SBEP-Modus angefordert hat und dass
sowohl der Programmierer 195 als auch das Funkgerät 200 bereits
auf diesen Modus geschaltet haben. Sobald eine Baudraten-Schaltnachricht
gesendet worden ist, bestimmt ein Bedingungsblock 504,
ob die Baudraten-Änderungsanforderung
durch das Funkgerät
ohne Fehler empfangen wurde. Der NEIN-Ausgang, der anzeigt, dass Fehler
entdeckt wurden, ist an einen Block 508 gekoppelt, in dem
bei der alten Baudrate eine Negativbestätigung (NBST) von dem Funkgerät an den
Host gesendet wird. Der Ausgang von Block 508 wird über einen Block 506,
der die Anzahl von Versuchen überwacht,
zu Block 502 zurückgekoppelt.
Block 506 überwacht
die Anzahl von Versuchen, um nichtsporadische Fehler in der Kommunikationsverbindung 230 zu
erfassen. Der JA-Ausgang des Bedingungs blocks 504 ist an
Block 510 gekoppelt, indem bei der alten Baudrate eine
Bestätigung
(BST) an den Host zurückgesendet
wird und die Baudrate an dem Funkgerät auf die angeforderte neue geändert wird.
Der Ausgang von Block 510 ist an einen Bedingungsblock 512 gekoppelt,
indem eine Frage bezüglich
der Bedingung der durch den Host empfangenen BST gestellt wird.
Der JA-Ausgang des Bedingungsblocks 512 ist an einen Block 514 gekoppelt,
indem der Host auf eine neue Baudrate schaltet. Der NEIN-Ausgang
des Bedingungsblocks 512 ist noch an einen anderen Bedingungsblock 518 gekoppelt,
in dem ein Timer überwacht
wird. Dieser Bedingungsblock fragt das Ablaufen des Timers ab. Der
JA-Ausgang, der anzeigt, dass der Timer abgelaufen ist, wird an
den Block 502 zurückgekoppelt,
indem der Host eine zweite Anforderung zum Ändern der Baudrate sendet.
Ein NEIN-Ausgang, der anzeigt, dass die dem Host zum Empfangen einer
Bestätigung
zugeteilte Zeit nicht abgelaufen ist, also Block 516, veranlasst
den Host nach der Bestätigung
zu sehen. Der Ausgang von Block 516 kehrt zu dem Bedingungsblock 512 zurück, indem
der Empfang einer BST abgefragt wird.
-
Es
ist erkennbar, dass bei dem Flussdiagramm 500 die Baudrate
der Kommunikation zwischen zwei Komponenten ohne irgendwelche Hardware-Wechselwirkungen
geändert
werden kann. In der bevorzugten Ausführungsform sind hohe Baudraten
erwünscht,
da das Programmieren der Unterabschnitte des Funksystems 100 verlangt,
dass große
Datenmengen weitergeleitet werden. Es ist klar, dass dieses Baudraten-Änderungsprogramm
nicht auf das Programmieren beschränkt ist und dass es für irgendeinen
Transfer von Daten verwendet werden kann.
-
Ein
beträchtlicher
Nutzen der vorliegenden Erfindung kann mit der Verfügbarkeit
von FLASH EEPROM verwirklicht werden. Mit der Verfügbarkeit
dieser Speicherkomponenten ist das Speichern von Firmware in einem
elektrisch löschbaren
Speicher nicht länger
unerreichbar und leicht durchführbar.
Jedoch wäre
bei bestehenden Kommunikationsprotokollen die Zeit zum Programmieren
einer großen
Speicherkomponente, nämlich eines
256 Kilobyte Geräts, übermäßig und
nicht wirkungsvoll. Des Weiteren beschränken verfügbare Protokolle, wie das SB9600,
den Adressenbereich mit ihrem festen Adressenfeld. Die durch die
vorliegende Erfindung verwirklichten Vorteile sind, dass durch die
Baudrate des SBEP-Protokolls keine Beschränkungen auferlegt werden, daher
die Geschwindigkeit, mit der ein Speichergerät über einen seriellen Bus programmiert
wird, beträchtlich
verbessert werden kann. Des Weiteren können wegen der Verbesserung
in den durch das SBEP ermöglichten
Adressierkapazitäten
mittels dieses Protokolls Geräte
bis zu 16 Megabytes und noch höher
programmiert werden. Es kann erwartet werden, dass die Speicherprogrammierzeit
mittels Nachrichten variabler Länge
um einen Faktor von 10 reduziert wird. Dies wird hauptsächlich dadurch
erreicht, dass die Vorteile des Sendens großer Datenmengen mit einem kleinen
Overhead verfügbar
sind, was das Protokoll hochwirksam macht. Ein anderer Vorteil der
vorliegenden Erfindung ist der der Aktualisierung des Displays eines
Funkgeräts,
wenn ein serieller Bus verwendet wird. Wenn dieses Protokoll verwendet
wird, kann wiederum verwirklicht werden, dass durch Verwendung von
Nachrichten variabler Länge
und variablen Baudraten die Leistungsfähigkeit des Anzeigens von Information
auf dem Display beträchtlich
verbessert werden kann.
-
In
der bevorzugten Ausführungsform
wird das SBEP verwendet, um zwischen Optionen auf dem seriellen
Bus oder zwischen einem externen Computer und dem Hauptprozessor
des Funkgeräts
oder seiner Optionen hohe Datentransferraten zu erzielen. Es ist
vorgesehen für
Eins-zu-Eins-Kommunikationen zwischen Knoten auf einem seriellen
Bus oder von dem Host an Optionen, die verbunden sein können oder
nicht. Die Nachrichten bestehen aus Anforderungen, Ausstrahlungen,
Rückmeldungen,
Bestätigungen
(BST) und Negativbestätigungen
(NBST). Anforderungen verlangen, dass ein Ziel verbunden ist, Ausstrahlungen
tun dies nicht. Rückmeldungen
werden nur in Abhängigkeit
von einer Anforderung gesendet.
-
Das
SBEP erzielt hohe Durchflussleistungen, indem es einer bestimmten
Implementierung gestattet, auszuwählen, welche Baudrate zu verwenden
ist. Die bevorzugte Ausführungsform
unterstützt
Raten bis zu 38,4 kBaud. Es ist völlig klar, dass höhere, schnellere
Plattformen verwendende Raten implementiert werden können. Das
Protokoll selbst spezifiziert das meiste Timing in Form von SCI-Bytezeiten.
Die variable Bytezählung
in SBEP-Nachrichten und die einzelnen Bytebestätigungen tragen ebenfalls zu
den hohen Durchflussleistungen bei.
-
Im
Allgemeinen und in der bevorzugten Ausführungsform ist das SBEP ein
temporärer
serieller Bus-"Modus". Der Veranlasser
des SBEP, hiernach als Host bezeichnet, wird eine SB9600-Nachricht
an einen der Knoten auf dem Bus senden, der durch die Gruppe/Adresse
identifiziert wird. Der durch die Gruppe/Adresse angesteuerte Knoten,
das Funkgerät 200,
hiernach als Ziel bezeichnet, wird mittels dieser SBEP-Anforderungs-(SBEP-ANFDG")Nachricht aufgefordert,
das SBEP durchzuführen.
Es kann sein, dass das Ziel nicht präsent ist, in welchem Fall der
Host fortfahren wird, da es keine SB9600-NBST geben wird. Während dieser Situation
machen lediglich Ausstrahlungsnachrichten Sinn. Zusätzlich zu
der Fähigkeit,
das SBEP-Protokoll von dem SB9600 aus einzugeben, kann es direkt
mittels des Bootstrap-Modus eingegeben werden. Mit anderen Worten,
das Ziel wird seinem internen Prozessor ermöglichen, sein Firmware-Gerät (Flash
oder UVEPROM) mittels SBEP-Nachrichten über den seriellen Bus neu zu
programmieren. Da das Firmware-Gerät vermutlich leer ist, wenn
das Ziel gefertigt wird, wird dieses Protokoll in Verbindung mit
für den
Bootstrap-Modus des Prozessors geschriebenen Algorithmen dem Funkprozessor
ermöglichen,
Firmware in sein Programmplatzgerät zu schreiben.
-
Zum
Demonstrieren der Leistungseinzelheiten des SBEP-Protokolls wird auf verschiedene Timing- und
Fluss-Diagramme Bezug genommen. Diese Diagramme sind dazu vorgesehen,
Unterstützung
beim Verstehen von einigen der Eigenschaften des SBEP-Protokolls,
einschließlich
des Wechselns von dem SB9600 zu dem SBEP, bereitzustellen. Es ist
völlig
klar, dass diese Diagramme die Besonderheiten der bevorzugten Ausführungsform
darstellen und nicht als Beschränkungen
der Erfindungen ausgelegt werden sollen.
-
5 zeigt
ein Timing- und Fluss-Diagramm des Eintritts in den SBEP-Modus.
Wenn der Prozessor in dem Ziel über
Firmware in seinem EEPROM verfügt,
wird er in dem SB9600-Modus arbeiten. Zum Wechseln in den SBEP-Modus
existiert ein SB9600-Op-Code, der das Ziel davon unterrichten wird,
dass der Host den SBEP-Betrieb beginnen möchte. Der Host wird eine SBEPANFDG-SB9600-Busnachricht 710 senden.
Im Anschluss an diese Anforderung wird die Besetzt-Leitung freigegeben, 706,
während
nach einer NBST von dem Ziel nachgesehen wird. Falls eine NBST präsent ist,
was durch ein temporäres
Hoch während
dem Tiefzustand der Periode 706 identifiziert wird, wiederholt
der Host. Wiederholungen, gefolgt von NBSTs, resultieren in der Ablehnung
des Eintritts in den SBEP-Modus. Falls keine SB9600-NBST erzeugt
wird, dann muss der Host die "Besetzt"-Leitung wieder aktiv
schalten (730) und fortfahren, die SBEP-Nachrichten 712 zu
senden. Alle anderen Busoptionen werden nach dem Erkennen des SBEPANFDG-Op-Codes
untätig
bleiben, und der SBEP kann fortfahren, so lange die Besetzt-Leitung
aktiv bleibt (730). Falls das Ziel nicht präsent ist,
wird der Eintritt in den SBEP fortfahren, als ob es präsent wäre.
-
Wenn
beim Eintritt in den SBEP ein Ziel angeschlossen ist, muss es (das
Ziel) bei der SBEP-Baudrate BST, so bald es bereit ist. Der Host
sollte auf diese BST 5 SCI-Bytezeiten bei der SBEP-Baudrate warten,
und falls nach 5 SCI-Bytezeiten
keine BST erkannt wird, kann es sein, dass das Ziel nicht präsent ist.
Eine SCI-Bytezeit wird gemeinhin als die Zeitspanne definiert, die
für das Übertragen
eines Bytes (8 Bits) von Daten zuzüglich eines Start- und eines
Stopp-Bits bei der Betriebs-Baudrate erforderlich ist. Diese anfängliche
BST wird verwendet, um dem Host mitzuteilen, dass er eine Nachricht
sofort senden kann, anstatt die 5 SCI-Bytezeiten abzuwarten. Falls
das Ziel für
die BST verspätet
ist und der Host fortfährt,
eine Anforderung oder eine Ausstrahlung zu senden, wird wahrscheinlich
eine Kollision eintreten. Wenn eine solche Kollision vorkommt und
sich ein Ziel auf dem Bus befindet, wird das Ziel die Anforderung
oder die Ausstrahlung NBST. Der Host ist für das Wiederholen verantwortlich,
da das Ziel nicht die vollständige
Nachricht erhielt.
-
Wenn
das Ziel zu Beginn über
keine Firmware verfügt,
wie es für
ein neues Funkgerät
der Fall ist, dann kann der Host nicht erwarten, dass sich das Ziel
nach der Ausgabe der SBEP-ANFDG 710 in dem SBEP-Modus befindet.
Die SBEPANFDG 710 muss dennoch ausgegeben werden, so dass
andere Busoptionen davon unterrichtet sind, dass der SBEP im Begriff
ist, auf dem Bus einzutreten. Da das Ziel unerreichbar ist, ist
der einzige Weg, mit dem Ziel zu kommunizieren, das Ziel in den
Bootstrap-Modus zu stellen und einen Bootstrap-Code auf es herunterzuladen.
In der bevorzugten Ausführungsform
ist die Mikroprozessoreinheit 300 ein MC68HC11-Mikroprozessor.
Dieser Prozessor muss mit tiefen MODA/B-Leitungen aus der Rücksetzung
herauskommen, um den Bootstrap-Modus hochzufahren. Es ist die Verantwortung
des Hosts, sicherzustellen, dass die MODA/B tief sind, wenn das
Ziel rücksetzt.
Optional kann die Funkgerätearchitektur
eine externe Steuerung über
die für
dieses Ereignis erforderlichen Leitungen zulassen.
-
6 zeigt
den Eintritt in den SBEP, wenn das Ziel über keine Firmware verfügt. Mit
anderen Worten, diese Figur stellt die Abläufe dar, die für das Stellen
des Prozessors in den Bootstrap-Modus notwendig sind. Der Nullimpuls 802 kann
durch die Verwendung einer SB9600-Nachricht oder einer SBEP-Nachricht
nicht erzeugt werden, da das Ziel über den seriellen Bus nicht
angewiesen werden kann, rückzusetzen.
In einer Fabrikumgebung wird der Nullimpuls 802 bewirkt,
indem automatisch Leistung für
eine zum Bewirken des Rücksetzens
ausreichend lange Zeitspanne von dem Ziel entfernt wird. Im Feld
muss jedoch dieser Nullimpuls 802 manuell durch die die
Neuprogrammierungsausstattung bedienende Person durchgeführt werden.
Unter normalen Umständen
können es
nur wenige Fälle
im Feld sein, wenn der Bediener das Ziel manuell zum Rücksetzen
veranlassen muss.
-
Zu
beachten ist, dass das Protokoll für das Herunterladen des Bootstrap-Codes
von dem Prozessor und seiner Taktgeschwindigkeit abhängig ist.
Für das
Herunterladen von Information wird der Leser an das MC68HC11-Bedienungshandbuch
verwiesen. Der letzte für
den Eintritt in den SBEP zu erwägende
Fall ist, wenn das Ziel über
Firmware zum Kommunizieren über
den SB9600 verfügt,
sie aber in den Bootstrap-Modus gestellt werden muss. Dies ist der
Fall, wenn die Firmware des Ziels höherzustufen ist. Dieser Eintrittsablauf wird
in 7 dargestellt. Da der Prozessor in dem Ziel Firmware
in seinem ROM hat, wird er in dem SB9600-Modus arbeiten. Um zu dem
SBEP-Modus zu wechseln, wird der Host eine SBEPANFDG-SB9600-Busnachricht 710 senden,
und falls das Ziel diese empfängt
und keine SB9600-NBST
erzeugt, dann muss das Ziel "Besetzt" aktiv schalten (730).
Alle anderen Busoptionen werden untätig bleiben, nachdem erkannt
wird, dass der SBEPANFDG-Op-Code und der SBEP fortfahren können, so
lange die Besetzt-Leitung aktiv bleibt. Falls das Ziel nicht präsent ist,
wird der Eintritt in den SBEP weitergehen, als ob es präsent wäre. Der
RÜCKSTELL-ANFDG-Op-Code
wird von dem Host gesendet, um anzuzeigen, dass das Ziel seinen
eigenen Nullimpuls erzeugen sollte, woraus den Bootstrap-Modus resultiert.
-
Wenn
beim Eintritt in den SBEP das Ziel angeschlossen ist, muss es (das
Ziel) bei der SBEP-Baudrate BST, so bald es bereit ist. Der Host
sollte auf diese BST 5 SCI-Bytezeiten bei der SBEP-Baudrate warten,
und falls nach 5 SCI-Bytezeiten
keine BST erkannt wird, kann es sein, dass das Ziel nicht präsent ist.
Diese anfängliche
BST wird verwen det, um dem Host mitzuteilen, dass er eine Nachricht
sofort senden kann, anstatt die 5 SCI-Bytezeiten abzuwarten. Falls
das Ziel zum BST verspätet
ist und der Host fortfährt,
eine Anforderung oder eine Ausstrahlung zu senden, wird wahrscheinlich
eine Kollision eintreten. Wenn eine solche Kollision vorkommt, befindet
sich ein Ziel auf dem Bus und es wird die Anforderung oder die Ausstrahlung
NBST. Der Host ist für
das Wiederholen nach Bedarf verantwortlich, da das Ziel nicht die
vollständige
Nachricht erhalten wird.
-
Nun
auf 8, 9 und 10 Bezug
nehmend wird das Verlassen des SBEP-Modus für drei verschiedene Betriebsarten
dargestellt. Als von dem SB9600 aus in den SBEP eingetreten wurde
und das Ziel nicht in den Bootstrap-Modus gestellt wurde, kann das
Verlassen des SBEP durch Freigeben der Besetzt-Leitung 1002 erreicht
werden. Sobald Besetzt freigegeben ist, muss der Zielprozessor zu
dem SB9600 zurückkehren.
Dies wird in 8 veranschaulicht. Alle anderen
Busoptionen werden das Hochgehen von Besetzt beachten und sich selbst
in dem SB9600-Modus reaktivieren.
-
Alternativ
dazu, wie in 9 gezeigt, kann der Host das
Ziel aus dem SBEP nehmen, indem er an das Ziel eine RÜCKSETZ-AUSSTRAHLUNG-("RESET-BROADCAST")Nachricht 1106 ausgibt.
Die RÜCKSETZ-AUSSTRAHLUNG-Nachricht 1106 wird
das Ziel veranlassen, das Rücksetzen
zu durchlaufen und dadurch hochfahren, um das normale SB9600-Busprotokoll
zu betreiben. Auf der Besetzt-Leitung zeigt der Impuls 1102 einen
normalen "Eingeschaltet"-Besetzt-Zustand,
der durch den Zielprozessor erzeugt wird. Die aufsteigende Kante
dieses Impulses beginnt das Hochfahren des Ziels in dem SB9600-Modus.
Der Impuls 1104 auf der Busrücksetzleitung ist eine durch
den Zielprozessor erzeugte normale Rücksetzung des "Eingeschaltet"-Typs.
-
Wenn
also noch eine andere Alternative, wie in 10 gezeigt,
das Ziel in dem Bootstrap-Modus war und seine Firmware programmiert
bekam, muss eine SBEP-RÜCKSETZ-AUSSTRAHLUNG-Nachricht 1106 an
das Ziel gesendet werden und die Bedingung, die es ihm ermöglichte,
ursprünglich
in den Bootstrap-Modus zu gehen, muss entfernt werden (MODA/B tief
gesetzt). Besetzt muss ebenfalls freigegeben werden. Falls das Ziel
Firmware auszuführen
hat, dann wird es hervorkommen und den SB9600-Modus betreiben. Der
Impuls 1202 stellt den durch die Cop-Unterbrechung in dem
Zielprozessor verursachten Nullimpuls dar. wieder fährt das
Ziel in dem SB9600 hoch, wie durch die gestrichelte Linie 1204 angezeigt.
-
Das
Format von SBEP-Nachrichten ist insofern sehr flexibel, als Nachrichten
von variabler Länge
sein können,
beginnend ab einem Byte bis zu 216 + 4 Bytes
lang. Praktisch gesprochen, die größte Nachrichtenlänge wird
durch den in dem Ziel verfügbaren
Umfang an RAM beschränkt.
-
Das
erste Byte der Nachricht bestimmt immer, was zu folgen hat. Die
Tabelle 1 veranschaulicht die Möglichkeiten
für das
erste Byte und wie es welche nachfolgenden Byte-Mittel beeinflusst.
-
-
Tabelle
1: Erstes Byte der SBEP-Nachricht
-
Das
erste Byte der SBEP-Nachricht ist auf einer Pro-Halbbyte-Basis (per nibble basis) zu
betrachten. Das heißt,
das erste Halbbyte oder am meisten signifikante Halbbyte (msn) enthält Op-Code-Information,
und das zweite Halbbyte oder am wenigsten signifikante Halbbyte
(lsn) enthält
Information bezüglich
der Anzahl von nachfolgenden Bytes. Deshalb folgen, wenn das lsn
$0 ist, keine weiteren Bytes nach, und alle anfänglichen Bytes, die $0 als
das lsn haben sind Ein-Byte-Nachrichten. BST und NBST sind Ein-Byte-Nachrichten und
haben keine Prüfsumme.
-
Das
lsn des ersten Bytes kann Werte von $0 bis $F annehmen. Wenn das
lsn $0–$E
ist, stellt es die Anzahl von nachfolgenden Bytes in der bestimmten
Nachricht dar. Wenn es $F ist, bedeutet es, dass zwei zusätzliche
Bytes erweiterter Größe folgen
und sie die Nachrichtengröße enthalten.
-
Das
msn des ersten Bytes ist der Op-Code. Es kann Werte von $0 bis $F
annehmen. Wenn es $0–$E ist,
ist es der Op-Code. Wenn es $F ist, dann gibt es ein zusätzliches
nachfolgendes Byte, das der erweiterte Op-Code ist.
-
Die
Kombination drei enthält
ein $F in dem msn, das anzeigt, dass es ein zusätzliches nachfolgendes Byte
gibt. Der erweiterte Op-Code ist nicht Teil der Zählung in
dem lsn, da der erweiterte Op-Code aufgrund der Tatsache, dass das
msn $F war, dafür
bekannt ist, vorhanden zu sein.
-
Es
existiert immer eine Prüfsumme
als letztes Byte einer Nachricht, die entweder in dem lsn oder in der
erweiterten Größe von 1
oder größer eine
Zählung
enthält.
Die Prüfsumme
wird wie folgt gerechnet: Prüfsumme = $FF – ((Summe
aller Bytes in der Nachricht) Modulus 256)
-
11 veranschaulicht
einige Beispielsnachrichten, die mit dem SBEP-Nachrichtenformat
möglich sind.
Die Darstellung dieser Beispielsnachrichten ist dafür vorgesehen,
dem Leser mit einem besseren Verständnis des für das SBEP-Protokoll verwendeten Datentransfers
auszustatten. Eine Einzelbyte-Nachricht 902 wird so gezeigt,
dass sie ein erstes Halbbyte 9022 enthält, das einen gewünschten
Betriebscode (Op-Code) variabler Länge anzeigt. Das zweite Halbbyte
zeigt die Anzahl der Bytes an, die folgen, einschließlich des
Prüfsummenbytes,
wenn überhaupt
welche. Die Op-Codes variabler Länge
können
ein oder mehrere Codes sein, die aus der Gruppe von Codes ausgewählt wurden,
die aus dem Rücksetzbetriebscode,
dem Lesebetriebscode, dem Schreibbetriebscode, dem Bitsetzbetriebscode,
dem Bitlöschbetriebs code,
dem Bestätigungsbetriebscode
und dem Negativbestätigungsbetriebscode
bestehen.
-
In
dieser Figur werden verschiedene Mehrbyte-Nachrichten gezeigt, um
eine breite Spanne verschiedener Möglichkeiten vorzustellen, die
dieses Datentransferformat bereitstellt. Die Mehrbyte-Nachricht 904 enthält einen
Op-Code und eine Bytezählung,
dargestellt durch das erste Byte. Das zweite Byte ist ein Prüfsummenbyte 9042,
das zu Fehlererfassungszwecken verwendet wird. Zu beachten ist,
dass der Inhalt der Bytezählung
in dem zweiten Halbbyte einer ist, der anzeigt, dass ein Einzelbyte
dem ersten Byte folgt. Die Mehrbyte-Nachricht 906 enthält einen
Datenbereich 9062. Der Datenbereich 9062 enthält ein Einzelbyte
in dieser Nachricht. Das Zählungshalbbyte
zeigt an, dass zwei Bytes von Daten, einschließlich der Prüfsumme,
folgen. Auf ähnliche
Weise enthält
die Nachricht 908 vier Bytes von Daten, wie durch die Bytezählung angezeigt.
-
Die
Nachricht 910 enthält
einen erweiterten Op-Code 9102. Die Gegenwart eines erweiterten
Op-Codes wird durch $F in dem ersten Halbbyte angezeigt. Dieses
$F zeigt an, dass das erste Byte nach dem Zählungshalbbyte ein erweiterter
Op-Code ist. Dies ist beim Durchführen einer Anzahl früher mit
dem SB9600-Protokoll nicht verfügbarer
Funktionen von Nutzen. Die Nachricht 912 enthält in dem
zweiten Halbbyte ein $F, das anzeigt, dass eine erweiterte Bytezählung 9122 verwendet
wird. Diese erweiterte Bytezählung
wird in Situationen verwendet, in denen die Anzahl von Datenbytes über die
dreizehn hinausgeht, die mit einem einzelnen Halbbyte angeboten
werden. Bei zwei verfügbaren
Zählungsbytes
können
sofort insgesamt 64 Kilobytes minus eines von Daten weitergeleitet
werden. Fachleuten in der Technik wird klar sein, dass zum Erweitern
der Größe der einzelnen
Nachricht der Datentransfer durch Zuweisung von mehr Bytes für die Zählung weiterhin
erweitert werden kann. Eine Kombination von $F in dem ersten und
dem zweiten Halbbyte zeigt an, dass sowohl ein erweiterter Op-Code
und eine erweiterte Bytezählung
folgen. Dies wird durch die Nachricht 914 gezeigt. Die Nachricht 916 zeigt
noch eine andere Kombination, in der ein erweiterter Op-Code ohne
Nulldatenzählung
verwendet wird. Letztendlich zeigt die Nachricht 918 einen
erweiterten Op-Code, gefolgt von einer Prüfsumme.
-
Die
Nachrichten 902 und 916 sind Einzelbyte- und Mehrbyte-Nachrichten
jeweils ohne Prüfsumme. Diese
Nachrichten werden in der bevorzugten Ausführungsform für Bestätigungen,
positive oder negative, verwendet. Dies ist wieder dazu vorgesehen,
den Datentransfer-Overhead, der bei der Verwendung der Prüfsummen
angetroffen wird, zu minimieren.
-
In
der bevorzugten Ausführungsform
beruht das SBEP-Protokoll
auf dem Konzept des ständigen
Vorhandenseins eines Hosts und eines Ziels. Der Host wird als der
Initiator des SBEP definiert, d. h. das Gerät, das anfänglich die SB9600-SBEPANFDG-Nachricht
sandte. Für
den gesamten Modus des SBEP wird es nur einen Host geben. Das Ziel
ist das Gerät,
dessen Adresse sich in der anfänglichen
SB9600-SBEPANFDG-Nachricht befand. Das Ziel kann in Abhängigkeit
von einer Ausstrahlung von dem Host nur Bestätigungen (BSTen) und Negativbestätigungen
(NBSTen) und in Abhängigkeit
von Anforderungen von dem Host BSTen, NBSTen oder Rückmeldungen
erzeugen. Für
die Dauer eines SBEP-Modus (die gesamte Zeit, in der Besetzt tief
gehalten wird) bleibt die Verwaltung bei dem Host und er muss jegliche
Nachrichten initiieren. Das Ziel bleibt das "Nebengerät" und reagiert nur auf von dem Host gesendete
Nachrichten. Das Funkgerät
kann für einen
Modus des SBEP der Host oder das Ziel sein. Hostnachrichten werden
in zwei Kategorien klassifiziert basierend darauf, welche Art von
Bestätigungen
erforderlich ist. Sie sind Ausstrahlungen und Anforderungen. Zielnachrichten
sind BSTen, NBSTen und Rückmeldungen.
Eine Erörterung
von jeder folgt.
-
Bezug
nehmend auf 12 und 13 werden
die Timingdiagramme für
zwei Beispiele von SBEP-Ausstrahlungen gemäß der vorliegenden Erfindung
gezeigt. Wie früher
erklärt,
sind Ausstrahlungen von dem Host gesendete Nachrichten ohne spezielle
Zielinformation. Ausstrahlungen werden von dem Host initiiert und
benötigen
keine BST oder NBST, er wird aber eine annehmen, wenn sie präsent ist.
Sie sind zur Verwendung vorgesehen, wenn das Funkgerät den SBEP
als Host initiiert, um die Außenwelt über Vorgänge zu informieren,
die in dem Funkgerät
vorkommen. Da es sein kann, dass ein Ziel angeschlossen ist oder
nicht, ist eine BST oder eine NBST für eine Ausstrahlung nicht erforderlich.
Ein Host, der eine Ausstrahlung initiiert, muss sich bewusst sein,
dass BSTen/NBSTen optional sind.
-
Für Ausstrahlungen
brauchen Ziele nicht angeschlossen zu sein. Das SBEP ist konstruiert
worden, um in einer Halbduplex-, hardwarelosen Handshake-Umgebung
zu arbeiten und ist deshalb nicht so robust in seiner Fehlerbehebung,
wie es ansonsten sein könnte.
Das Protokoll ist so konstruiert, dass wenn Daten an das Ziel geschrieben
werden, die Herunterlade-Baudrate oder die Programmlaufzeit an das
Gerät in
dem Ziel der einschränkende
Faktor für
die Durchflussleistung ist.
-
Falls
ein Ziel angeschlossen ist, muss es eine Ausstrahlung BST oder NBST.
Falls das Ziel bestätigt (BSTt),
dann kann der Host eine andere Nachricht senden, wenn er es wünscht. 12 zeigt
die Situation, wenn eine BST von dem Ziel zurückgesendet wird. Falls das
Ziel negativ bestätigt
(NBSTt), dann besteht positive Bestätigung, dass die Ausstrahlung
nicht durchgekommen ist, somit muss der Host bis zu viermal wiederholen,
bis eine BST erkannt wird oder keine BST/NBST erkannt wird (der
Fall, wenn das Ziel nach der Hälfte einer
Wiederholung entfernt wurde).
-
Bezug
nehmend auf 13, wenn kein Ziel angeschlossen
ist, dann wird der Host niemals eine BST oder eine NBST erkennen.
Da der Host nach dem Senden der ersten Ausstrahlung 1502 nicht
weiß,
ob ein Ziel angeschlossen ist, muss er 10 SCI-Bytezeiten abwarten,
um zu erkennen, ob eine BST oder eine NBST auf dem Bus erscheint.
Falls der Host in 10 SCI-Bytezeiten nichts erkennt (1504),
kann er annehmen, dass kein Ziel angeschlossen ist und fortfahren,
eine andere Ausstrahlung zu senden, 1506. Es ist nahe liegend, dass
der Host nach der Erkenntnis, dass kein Ziel angeschlossen ist,
niemals eine Anforderung senden sollte. Falls er es tut, wird er
eine Wiederholungsfolge durchlaufen und niemals eine BST/NBST oder
eine Rückmeldung
erkennen. Falls das Ziel eine Ausstrahlung BSTt, ist das alles,
was es tun muss.
-
Anforderungen
werden durch den Host initiiert und erfordern eine BST oder eine
NBST. Falls der Host keine von beiden erkennt, muss er daraus folgern,
dass kein Ziel angeschlossen ist und das Anforderungen nicht länger Sinn
machen. Dies würde
der Fall sein, wenn das Ziel nach der Hälfte eines SBEP-Modus entfernt wurde.
Anforderungen er fordern immer irgendeine Art von Rückmeldung.
Sie werden von dem Ziel nach der BST an den Host gesendet. Dem Host
ist es nicht gestattet, eine weitere Anforderung oder Ausstrahlung
zu senden, bis die Rückmeldung
für die
letzte Anforderung erkannt wird.
-
BSTen
und NBSTen werden von dem Ziel zu jeder erkannten Nachricht (Ausstrahlung
oder Anforderung) an den Host gesendet. BSTen können sofort durch das Ziel
gesendet werden, sobald eine korrekte Nachrichtenprüfsumme empfangen
wird. Eine BST dient dazu, dem Host mitzuteilen, dass die Nachricht
(Ausstrahlung oder Anforderung) von dem Ziel korrekt empfangen wurde
und dass der Host es nicht wiederholen sollte. BSTen werden nur
von dem Ziel an den Host gesendet, niemals von dem Host an das Ziel.
BSTen und NBSTen werden in 14, 15 und 16 für Fälle gezeigt,
wenn das Ziel jeweils bestätigte
(BSTte), negativ bestätigte
(NBSTte) oder keinerlei Rückmeldungen
sendete.
-
BSTen
müssen
innerhalb eines 10 SCI-Bytezeitenfensters, nachdem die Prüfsumme durch
das Ziel empfangen wird, gesendet werden. Typischerweise wird ein
Host in der Lage sein, diese BST fast unverzüglich zu senden. NBSTen werden
von dem Ziel an den Host gesendet, wenn eine verstümmelte Nachricht
von dem Ziel empfangen wird. Eine schlechte Prüfsumme oder unkorrekte Zählung der
Bytes wird das Ziel veranlassen, eine schlechte Prüfsumme wahrzunehmen
und sich zum Senden einer NBST einzurichten. Da der Bus bidirektional
ist, kann eine NBST nicht wie die BST sofort gesendet werden, weil
der Bus mit dem Senden von mehr Bytes beschäftigt sein kann, obwohl das
Ziel bereits entschied, dass es NBST wird (wie es der Fall sein würde, falls
das Zählungsbyte
verstümmelt
ist).
-
NBSTen
müssen
5 SCI-Bytezeiten, nachdem der Bus frei geworden ist, gesendet werden.
Das heißt, der
Host könnte
fortfahren, eine Nachricht zu senden, aber das Ziel muss abwarten,
bis der Bus für
5 SCI-Bytezeiten frei ist. Dies wird in 15 gezeigt.
Die NBST muss gesendet werden, bevor 10 SCI-Bytezeiten ab dem letzten
Byte auslaufen. Diese zeitliche Begrenzung (1702) ist erforderlich,
damit der Host weiß,
wann er es wiederholen soll. Wann immer das Ziel eine NBST sendet,
muss es der Host bis zu viermal wiederholen (1704). Falls
der Host fortfährt,
NBSTen zu erkennen, sollte er schlussfolgern, dass das physikalische
Medium für
das Stattfinden von Kommunikationen zu sehr rauscht.
-
Eine
Möglichkeit
besteht, dass das Ziel eine BST oder eine NBST an den Host zurücksenden
wird, sie aber auf dem Bus verstümmelt
wurde, während
sie auf dem Weg zu dem Host war. In diesem Fall sollte der Host
schlussfolgern, dass das Ziel die letzte Nachricht nicht korrekt
empfing und sollte die letzte Nachricht wiederholen, 16.
Diese Wiederholung 1704 kann nur nach 10 SCI-Bytezeiten,
nachdem die Prüfsumme
für die
letzte Nachricht gesendet wurde, stattfinden, 1702 in 16.
In dem Fall, dass der Host eine Ausstrahlung sendete (die keine
BST oder NBST benötigt)
und auf der Leitung in den 10 SCI-Bytezeitenfenster nach der Prüfsumme ein
Störimpuls
auftrat, wird der Host denken, dass ein Ziel angeschlossen war und
dass seine BST oder NBST verstümmelt
war. In diesem Fall muss der Host die Ausstrahlung wiederholen,
bis er in dem 10 SCI-Bytezeitenfenster eine BST/NBST oder nichts
empfängt.
Zu beachten ist, dass die Möglichkeit
besteht, dass das Ziel fortfahren wird, eine Rückmeldung 1802 zu
senden, wenn der Host im Begriff ist, die letzte Anforderung zu
wiederholen. In die sem Fall wird eine Kollision stattfinden. Der
Host muss erkennen, dass eine gewünschte Rückmeldung verstümmelt war
und die letzte Anforderung neu senden.
-
Noch
einmal auf 14 Bezug nehmend ist erkennbar,
dass die Rückmeldungen 1602 von
dem Ziel an den Host in Abhängigkeit
von einer Anforderung gesendet werden und nur nachdem eine BST gesendet wurde.
Der Host wird keine BST/NBST an das Ziel zurücksenden, falls die Rückmeldung
auf ihrem Weg zurück zu
dem Host verstümmelt
wurde. In diesem Fall muss der Host die letzte Anforderung neu senden.
Falls der Op-Code in der Anforderung von dem Ziel nicht unterstützt wird,
muss das Ziel immer noch BST (da die BST lediglich bedeutet, dass
die Nachricht zu dem Ziel durchgekommen ist).
-
Damit
das Bustiming korrekt arbeitet, darf der Host niemals mehr als 5
SCI-Bytezeiten pausieren, während
er eine Nachricht sendet. Falls der Host länger als 5 SCI-Bytezeiten pausiert,
wird das Ziel zum NBST frei sein, da es den Anschein haben wird,
als ob der Host mitten in der Nachricht aufhörte. Während einer Rückmeldung
darf das Ziel nicht für
mehr als 5 SCI-Bytezeiten zwischen Bytes pausieren.
-
Um
den Durchsatz des Protokolls zu erhöhen, kann die Baudrate für SBEP-Nachrichten
geändert
werden. Die anfängliche
SBEPANFDG-SB9600-Nachricht enthält
Bits, die anzeigen, was die anschließende Baudrate von SBEP-Nachrichten
sein wird. Der Host muss vorab wissen, welche Baudraten durch das
Ziel unterstützt
werden und eine von diesen verwenden. In der bevorzugten Ausführungsform
wird die Baudrate, sobald in dem SBEP-Modus befindlich, für diesen
Modus gleich bleiben und kann nicht geändert werden. Andere Aus führungsformen
können
Op-Codes zum Ändern
der Baudrate enthalten, während
man sich noch in dem SBEP-Modus befindet.
-
In
dem Bootstrap-Modus wird die Baudratenauswahl anders durchgeführt. In
der Hostdatei wird ein Header existieren, der den Bootstrap-Code
enthält,
der anzeigt, welche Baudrate für
SBEP während
dem Bootstrap-Modus zu verwenden ist. Der Host wird für das Beobachten
der Information in dieser Datei verantwortlich sein, um seine Baudrate
einzustellen.
-
Bezug
nehmend auf 17 wird die BST-Nachricht als
eine Ein-Byte-Nachricht gezeigt, die ausschließlich dazu verwendet wird,
dem Host mitzuteilen, dass die Nachricht mit einer korrekten Prüfsumme 1904 durch
das Ziel empfangen wurde. Wenn der Host eine BST empfängt, darf
er nicht wiederholen. Die BST muss innerhalb 10 SCI-Bytezeiten,
nachdem eine korrekte Nachricht von dem Ziel empfangen wurde, gesendet
werden. Das BST-Fenster 1902 definiert diese zeitliche
Begrenzung. Ein Nichtsenden der BST innerhalb dieser Zeit wird dem
Host anzeigen, dass das Ziel nicht empfängt, was dem Host die Wiederholung
ermöglicht.
-
Bezug
nehmend auf 18 wird das NBST-Timingprogramm
gezeigt. Die NBST-Nachricht wird verwendet, um dem Host mitzuteilen,
dass die frühere
Nachricht von dem Ziel unkorrekt empfangen wurde. Eine unkorrekt
empfangene Nachricht könnte
durch eine unkorrekte Prüfsumme 2006,
zu wenige Bytes in der Nachricht oder zu viele Bytes in der Nachricht
verursacht werden. Die NBST kann nicht sofort an den Host zurückgesendet
werden. Das Ziel muss vor dem Senden einer NBST abwarten, bis der
Bus für
5 SCI-Bytezeiten frei ist, wie durch 2002 angezeigt. Die
NBST muss innerhalb 5 SCI- Bytezeiten,
nachdem der Bus frei geworden ist, gesendet werden, wie durch 2004 gezeigt.
-
Bezug
nehmend auf 19 wird ein Timingdiagramm für die Rücksetz-Ausstrahlung
gemäß der vorliegenden
Erfindung gezeigt. Die RÜCKSETZUNG-AUSSTRAHLUNG-Nachricht 1106 wird
verwendet, um dem Ziel mitzuteilen, sich selbst rückzusetzen
(2104). Als Ergebnis dieser Nachricht sollte das Ziel eine
Hardware-Rücksetzung
durchlaufen. Ein Weg für
den Zielprozessor sich selbst rückzusetzen
ist, das Aktualisieren des COP-Timers zu stoppen. Diese Nachricht
wird zum Eingeben des Bootstrap-Modus verwendet, oder zum Verlassen
des SBEP. Das Ziel sollte innerhalb 100 ms nach dem Senden der BST
zurück
an den Host aus der Rücksetzung
kommen. Damit der Host andere Knoten auf dem Bus informieren kann,
dass das Ziel rücksetzen wird,
muss das Ziel vor dem Rücksetzen
wenigstens 30 ms abwarten. Dieses Zeitfenster wird durch 2102 angezeigt.
-
In
der bevorzugten Ausführungsform
kann das SBEP-Protokoll
eine Anzahl von Anforderungen handhaben. Einige dieser Anforderungen
umfassen: LESE-DATEN-ANFDG, PRÜFSUMMEN-ANFDG,
ZUSTANDS-ANFDG, LÖSCHE-FLASH-ANFDG,
SCHREIBE-DATEN-ANFDG und KONFIGURATIONS-ANFDG. Es folgt eine kurze
Beschreibung von jeder dieser Anforderungsnachrichten.
-
Die
LESE-DATEN-ANFDG-Nachricht wird dazu verwendet, das Ziel aufzufordern,
einen Block von Daten von einer bestimmten Adresse weiterzuleiten.
Diese Adresse ist in den Adressenbytes der Nachricht enthalten.
Die Zählung
von Bytes, die zurückgesendet
werden müssen,
ist in der BYTE-ZLG
(Bytezählung)
enthalten. Die BYTE-ZLG ist die tatsächliche Anzahl von Datenbytes,
die zurückgesendet
werden müssen,
wobei $00 Null zurückzusendende
Bytes bedeutet und $FF 255 Bytes. Die Nachricht enthält die Daten,
die durch die LESE-DATEN-ANFDG-Nachricht angefordert wurden. Die
LESE-DATEN-ANFDG-Nachricht ist eine implizierte BEREIT-RÜCKMLDG.
-
Die
PRÜFSUMMEN-ANFDG-Nachricht
weist das Ziel an, beginnend an der Adresse, die in den Nachrichtenadressenbytes
für die
Zählung
der in den Zählungsbytes
enthaltenen Bytes enthalten ist, einen Prüfsummenbetrieb durchzuführen. Es
existieren zwei Zählungsbytes,
die spezifizieren, wie viele Bytes summiert werden müssen. Die
Summe wird als eine gerade Summe definiert, die bei der spezifizierten
Adresse beginnt und irgendwelche Bits aussondert, die über die
für das
Ergebnis zugelassenen 16 Bits hinausgehen. Diese Nachricht wird
bei dem Abschluss eines Flash- oder EEPROM-Programmiermodus verwendet,
um sicherzustellen, dass der Teil alle Stellen korrekt programmiert
hat. Das Ergebnis wird in der PRÜFSUMMEN-RÜCKMLDG-Nachricht
zurückgesendet.
Diese Nachricht wird mit der Prüfsumme,
die sie von der in der PRÜFSUMMEN-ANFDG
spezifizierten Adresse bezog, durch das Ziel an den Host zurückgesendet.
Die Prüfsumme
ist in zwei Bytes enthalten. Das Verfahren zum Berechnen der Prüfsumme wird
in der Beschreibung für
die PRÜFSUMMEN-ANFDG-Nachricht
beschrieben.
-
Die
KONFIGURATIONS-ANFDG-Nachricht wird zum Abfragen des Ziels nach
der Größe seines
internen Puffers während
dem SBEP verwendet. Der durch diesen Op-Code erbrachte Wert geht über die
KONFIGURATIONS-RÜCKMLDG-Nachricht.
Der Host muss diese Nachricht ausgeben, wenn er nicht weiß, was die größte Nachrichtengröße ist,
die das Ziel annehmen kann. Die KONFIGURATIONS-RÜCKMLDG-Nachricht enthält drei
zusätzliche
Bytes. Die ersten zwei Bytes der zusätzlichen Bytes enthalten eine
Zählung,
die die größte Nachrichtengröße darstellt,
die das Ziel annehmen kann.
-
Die
ZUSTANDS-ANFDG-Nachricht wird zum Abfragen des Zustandes des Ziels
verwendet. Als Antwort sendet das Ziel eine ZUSTANDS-RÜCKMLDG-Nachricht,
die ein Adressenfeld enthält,
um dem Host anzuzeigen, auf welche Adresse während einem Schreib- oder Lösch-Prozess
zugegriffen wird. Der Zustand wird zu diesem Zeitpunkt nicht verwendet
und wird nach Bedarf auf einer Per-Funkgerät-Basis definiert.
-
Die
LÖSCHE-FLASH-ANFDG-Nachricht
kann nur verwendet werden, wenn sich das Ziel in dem Bootstrap-Modus
befindet und einen FLASH EEPROM enthält. Das Ziel muss beim Empfangen
dieser Nachricht seinen Flash-Speicherteil löschen. Falls diese Nachricht
an das Ziel ausgegeben wird, wenn es sich nicht in dem Bootstrap-Modus
befindet, sollte das Ziel die UNBESTÄTIGTER-Op-CODE-RÜCKMLDG senden
und die Nachricht ignorieren.
-
Bei
Abschluss des Löschablaufs,
der mehrere Sekunden dauern kann, muss das Ziel eine 'GUTE-SCHREIB-RÜCKMLDG' zurücksenden.
Dies ist die Anzeige an den Host, dass er fortfahren kann. Falls das
Ziel den Flash nicht vollständig
löschen
konnte, muss eine 'SCHLECHTE-SCHREIB-RÜCKMLDG' mit der Adresse,
wo der Löschalgorithmus
versagte, zurückgesendet
werden.
-
Zielen
mit Flash-Speichergeräten,
die verlangen, dass der gesamte Teil vor dem Löschen auf Null programmiert
werden muss, muss diese Nachricht vor der LÖSCHE-FLASH-ANFDG-Nachricht übergeben
werden. Jedoch ist es optional, ob der Teil bereits als zu löschen bekannt
ist, wie wenn der Teil als leer bekannt ist. Bei Anschluss des Nullstellungsablaufs,
der mehrere Sekunden dauern kann, muss das Ziel eine 'GUTE-SCHREIB-RÜCKMLDG' zurücksenden.
Die in der 'GUTE-SCHREIB-RÜCKMLDG enthaltene
Adresse ist unwichtig. Dies ist die Anzeige an den Host, dass er
fortfahren kann. Falls das Ziel den Flash nicht vollständig auf
Null stellen konnte, muss eine 'SCHLECHTE-SCHREIB-RÜCKMLDG' mit der Adresse,
wo das Programmieren auf Null versagte, zurückgesendet werden.
-
Die
SCHREIBE-DATEN-ANFDG wird dazu verwendet, das Ziel zu veranlassen,
an eines seiner Speichergeräte
zu schreiben. Dies könnte
der RAM, der EEPROM (intern oder extern) oder der FLASH EEPROM sein.
Zwei Arten von SCHREIBE-DATEN-ANFDG-Bustransaktionen
sind in der bevorzugten Ausführungsform verfügbar, ein
einzeln und ein doppelt gepuffertes Ziel. 20, 21 und 23 zeigen
Timingdiagramme für
diese Transaktionen. Diese sind Speicherprogrammier-Bustransaktionen
mit guten Schreibrückmeldungen.
-
Um
während
dem Schreiben von Daten den maximal möglichen Durchsatz an das Ziel
zu erreichen, ist das SBEP-Protokoll konstruiert, dem Ziel das Implementieren
des Doppelpufferns zu ermöglichen.
Das heißt,
das Ziel kann imstande sein, eine Nachricht über den seriellen Bus anzunehmen,
während
es die letzte Nachricht an das Speichergerät programmiert. Für das Doppelpuffern
muss das Ziel zwei RAM-Puffer
und einen weiteren beiseite stellen, um gleichzeitig eine neue Nachricht
anzunehmen.
-
Dem
Host ist es gleichgültig,
ob das Ziel Doppelpuffern implementiert oder nicht. Jedoch muss
der Host immer überwachen,
welche SCHREIBE-DATEN-ANFDG-Nachrichten eine GUTE-SCHREIB-RÜCKMLDG (GSR)
oder eine SCHLECHTE-SCHREIB-RÜCKMLDG (SSR)
aufweisen. Es ist die Verantwortung des Hosts, diese Nachrichten
zu wiederholen, die nicht in einer GSR resultierten.
-
Da
das SBEP-Protokoll verlangt, dass jede Nachricht von dem Host eine
Rückmeldung
irgendeiner Art empfängt,
bevor er eine andere Nachricht senden kann, wird dem Ziel gestattet,
ein (GSR) mit einer Adresse aller $FF zurückzusenden, was dem Host anzeigt,
eine andere Nachricht zu senden, aber keinerlei Information liefert,
ob die erste Nachricht tatsächlich
korrekt an das Gerät
programmiert wurde oder nicht. An dieser Stelle muss der Host erkennen,
dass das Ziel eine doppelt gepufferte Implementierung durchführt und
fortfahren, eine andere Nachricht zu senden. Sobald das Ziel das
Programmieren der ersten Nachricht beendet, wird es in der Lage
sein, eine GSR oder eine SSR für
die frühere
Nachricht, nicht die gerade empfangene, an den Host zu liefern.
Tatsächlich
wird die in den Rückmeldungen
enthaltene Adresse immer die der vorletzten empfangenen Nachricht
sein. Der Host muss ausreichend flexibel sein, zu erkennen, dass
die in der Rückmeldung
enthaltene Adresse nicht notwendigerweise die Adresse der letzten
gesendeten Nachricht ist. Nachdem die letzte SCHREIBE-DATEN-ANFDG
an das Ziel gesendet ist, wird noch eine weitere GSR oder SSR in
die Warteschlange des Ziels eingereiht werden. Der Host muss noch
eine weitere SCHREIBE-DATEN-ANFDG mit einer Zählung von Null Bytes ausgeben,
die das Ziel ansteuert, die letzte gute oder schlechte Schreibrückmeldung zu
versenden.
-
Wenn
das Ziel eine SCHREIBE-DATEN-ANFDG-Nachricht versendet, ist abgesehen
von einer SCHREIBE-DATEN-ANFDG-Nachricht keine andere Nachricht
zulässig,
bis eine Unterbrechung erfüllt
ist. Das heißt,
der Host kann keine SCHREIBE-DATEN-ANFDG
gefolgt von einer LESE-DATEN-ANFDG senden, es sei denn, die Unterbrechung
für die
Schreibnachricht lief ab. Diese Regel in Verbindung mit der Regel über das Nichtsenden
einer GSR oder SSR, es sei denn, gefolgt von einer BST, wird Kollisionen
zwischen einer GSR- oder einer SSR-Nachricht und einer Wiederholung
einer SCHREIBE-DATEN-ANFDG
verhindern, wenn das Ziel NBSTt.
-
Die
Unterbrechung für
die SCHREIBE-DATEN-ANFDG-Nachricht beträgt 20 ms für jedes zu programmierende
Byte von Daten zuzüglich
zusätzlicher
50 ms Sicherheitszeit. Das heißt,
wenn eine SCHREIBE-DATEN-ANFDG-Nachricht 10 Datenbytes in sich birgt,
kann der Host abgesehen von einer SCHREIBE-DATEN-ANFDG keine andere
Nachricht innerhalb 250 ms nach der letzten BST, die er für eine SCHREIBE-DATEN-ANFDG-Nachricht empfing,
initiieren.
-
Bezug
nehmend auf 20 ist zu beachten, dass in
einem Einzelpufferziel jede GSR der letzten SCHREIBE-DATEN-ANFDG entspricht.
-
Bezug
nehmend auf 21 ist zu beachten, dass die
zweite SCHREIBE-DATEN-ANFDG angenommen wird, während das Ziel die erste Nachricht
programmiert, was den Durchsatz erhöht. Dies ist möglich, weil der
Host die mit einem Stern gekennzeichnete 'Dummy'-GSR erkannte. Die Baudrate oder die
Programmierzeit, was immer langsamer ist, ist der einschränkende Faktor
beim Programmieren eines Geräts
in dem Ziel.
-
In
der bevorzugten Ausführungsform
werden in Abhängigkeit
von den vorstehend erwähnten
Anforderungen eine Reihe von Rückmeldungen
unterstützt.
Einige von diesen umfassen: GSR, SSR, NICHT-UNTERSTÜTZTER-Op-CODE-RÜCKMLDG,
KONFIGURATIONS-RÜCKMLDG,
PRÜFSUMMEN-RÜCKMLDG,
LESE-DATEN-RÜCKMLDG
und ZUSTANDS-RÜCKMLDG.
-
Die
GSR dient dazu, dem Host mitzuteilen, dass eine SCHREIBE-DATEN-ANFDG-Nachricht
erfolgreich in das gekenn zeichnete Speichergerät programmiert wurde. Eine
GSR-Nachricht kann nur einer BST folgen. Das heißt, falls die letzte Nachricht
von dem Host NBSTt wurde, dann muss das Ziel mit dem Senden der GSR
abwarten, bis der Host mit dem Erreichen des Ziels erfolgreich ist,
d. h. eine SCHREIBE-DATEN-ANFDG-Nachricht wird BSTt. Die GSR enthält die Adresse,
die in der SCHREIBE-DATEN-ANFDG-Nachricht enthalten war, deren Daten
korrekt in den Speicher geschrieben wurden. Sie wird in Abhängigkeit
von einer SCHREIBE-DATEN-ANFDG gesendet, aber wie in der Erörterung
bezüglich
der SCHREIBE-DATEN-ANFDG angemerkt, kann es sein, dass die Adresse
nicht die der letzten SCHREIBE-DATEN-ANFDG-Nachricht ist. Eine GUTE-SCHREIB-NACHRICHT
mit einem Adressenfeld aller $FF dient dazu, dem Host mitzuteilen,
eine andere Nachricht zu senden. Wann immer der Host eine GSR empfängt, kann
er sofort eine andere Nachricht senden.
-
Die
SSR-Nachricht dient dazu, dem Host mitzuteilen, dass das Ziel beim
Programmieren der in der SCHREIBE-DATEN-ANFDG-Nachricht an das gekennzeichnete
Speichergerät
enthaltenen Daten erfolglos war. Eine SSR-Nachricht kann nur einer
BST folgen. Das heißt,
wenn die letzte Nachricht von dem Host NBSTt wurde, dann muss das
Ziel vor dem Senden der SSR abwarten, bis der Host mit dem Erreichen
des Ziels erfolgreich ist, d. h. eine SCHREIBE-DATEN-ANFDG-Nachricht
wird BSTt.
-
Die
SSR enthält
die Adresse, die in der SCHREIBE-DATEN-ANFDG-Nachricht enthalten
war, deren Daten nicht an den Speicher geschrieben wurden. Sie wird
in Abhängigkeit
von einer SCHREIBE-DATEN-ANFDG gesendet, aber wie in der Erörterung
bezüglich
der SCHREIBE-DATEN-ANFDG angemerkt, kann es sein, dass die Adresse
nicht die der letzten SCHREIBE-DATEN-ANFDG-Nachricht
ist.
-
Wann
immer der Host eine SSR empfängt,
kann er sofort eine andere Nachricht senden. 23, 24 und 25 veranschaulichen
die Bustransaktionen, wenn schlechte Schreibungen existieren. Diese Figuren
zeigen eine Speicherprogrammier-Bustransaktion mit guten und schlechten
Rückmeldungen
gemäß der vorliegenden
Erfindung.
-
Wie
demonstriert worden ist, ist das SBEP-Protokoll verhältnismäßig einfach
zu implementieren, da der zum Ausführen des Protokolls erforderliche
Code zum Laden in den Bootstrap-RAM eines Mikroprozessors ausreichend
klein ist. Durch die Fähigkeit,
mit einem Funkgerät
in dem Bootstrap-Modus,
kombiniert mit den FLASH EEPROM Geräten, zu kommunizieren, sind
wir nun in der Lage, die Funk-Software des Kunden zu ändern, ohne überhaupt
das Funkgerät
zu öffnen.
Mit anderen Worten, mittels verfügbarer
Bootstrap-Technologie kann ein Funkgerät mittels des Bootstrap-Modus
eines internen Mikroprozessors gestartet und dann mittels des das
hochwirksamen Protokolls mit einem gewünschten Programm programmiert
werden.
-
Zusammengefasst
ist offenbart worden, dass ein signifikanter Aspekt der vorliegenden
Erfindung das Potential zum Schalten von einem Protokoll auf ein
anderes zusammen mit Baudraten-Änderungsanforderungen
ist. Durch das Senden einer Nachricht in dem ersten Protokoll, um
auszuwählen,
welche Optionen umschalten sollten und um allen anderen Optionen
mitzuteilen, die Busbetriebe auszusetzen, wird dies erreicht. Eine
Besetzt-Leitung wird für
die Dauer aller auf dem zweiten Protokoll stattfindenden Aktivitäten in dem
aktiven Zustand gehalten und dazu verwendet, alle Unterab schnitte
zu informieren, dem Bus fernzubleiben. Sobald der SBEP-Datentransfer
abgeschlossen ist, wird die Besetzt-Leitung freigegeben und alle Optionen
kehren zu dem SB9600 zurück.
Die Fähigkeit
des SBEP-Protokolls, auf einem bidirektionalen seriellen Datenbus zu
funktionieren, verringert die Anzahl der erforderlichen Verbindungen.
Dies ist in Anwendungen, in denen sich Ausrüstungselemente nicht in enger
Nachbarschaft zueinander befinden und lange Kabel benötigen, hoch erwünscht.
-
Ein
Vorteil des SBEP-Protokolls ist seine Fähigkeit, sich selbst anzupassen,
so dass entweder die Baudrate oder die Programmierzeit der beschränkende Faktor
in der Kommunikationsgeschwindigkeit werden. Dies ist sehr wertvoll,
weil dieses Protokoll unverändert
bleiben kann, während
sich Baudraten erhöhen
und sich Programmierzeiten verringern. Noch ein anderer Vorteil
der vorliegenden Erfindung ist ihr Potential zum Handhaben von Nachrichten
variabler Länge
in einem strukturierten Format.
-
Obwohl
sich die Beschreibung der bevorzugten Ausführungsform auf zwei bestimmte
Protokolle, SP9600 und SBEP, konzentriert hat, sollte völlig klar
sein, dass die Grundsätze
der vorliegenden Erfindung sehr wohl durch andere Protokolle genutzt
werden können.
Die Darstellung spezifischer Ausführungsformen ist darauf gerichtet,
ein Verständnis
der vorliegenden Erfindung zu schaffen und soll nicht ist als Beschränkung von
dieser ausgelegt werden.