-
Logikanalysatoren
sind Testausrüstungen, die
eine Untersuchung von Mustern ("logischen
Zuständen") in logischen Signalen
ermöglichen,
und das Auftreten von ausgewählten
Ereignissen in denselben erfassen. Frühere Ausrüstungen, die diese Definition
erfüllen,
werden mit seriell übertragenen Daten
betrieben, wie z. B. die Bits von Zeichen, die über RS-232 gesendet werden,
oder ein Registerinhalt, der über
serielle Busse in einer seriellen Mikroprozessorumgebung gesendet
wird. Derzeit sind serielle Mikroprozessoren weniger vorherrschend
als ihre parallelen Gegenstücke,
obwohl die serielle bitweise Übertragung
von Daten in vielen Formen (z. B. dem Internetprotokoll über ein
Ethernet) fortgesetzt wird, und der Ausdruck "Logikanalysator" bezieht sich nun allgemein auf eine
Ausrüstung,
die Daten behandelt, die in paralleler Form (wie z. B. in einem 64
Bit breiten Bus) auftreten. Die Aufgabe der seriellen Datenanalyse
wurde durch "serielle
Datenanalysatoren" und
Protokollanalysatoren durchgeführt. Trotz
dieser Abweichungen verbleiben viele der Grundkonzepte (z. B. der
Begriff des Triggerns (Auslösens))
gleich oder ziemlich ähnlich,
und trotz der Tatsache, daß hierin
Beispiele auf dem Gebiet der parallelen Daten dargestellt werden,
ist es dennoch offensichtlich, daß die im folgenden beschriebenen Verfahren
eine Anwendbarkeit in der seriellen Umgebung sowie in der parallelen
Umgebung besitzen. Dies ist nicht überraschend, wenn man berücksichtigt,
daß heutzutage
eine Nacherfassungsverarbeitungseinrichtung, die eine serielle Datenanalysefähigkeit
vorsieht, oftmals als ein Zubehör
oder als eine Option zu einem parallelen Logikzustandsanalysator verkauft
wird.
-
Von
ihren bescheidenen Anfängen
mit acht Datenkanälen
und Speichern mit lediglich 16 Zuständen bezüglich der Tiefe haben sich
(parallele Daten-)Logik-Analysatoren in leistungsvolle und verfeinerte
Systeme entwickelt, die Hunderte von Kanälen überwachen und Zehnfache von
Millionen von zuständen
speichern können,
die gemeinsam eine Spur genannt werden, die in einem Spurspeicher
gespeichert wird. Ein derartiger Reichtum an Daten ist jedoch lediglich
wertvoll, wenn die interessierenden Ereignisse nicht durch die reine
Anzahl von anderen Ereignissen, die in dem Spurspeicher gespeichert
werden können,
verborgen werden. Obwohl die Nacherfassungsanalyse der Spur immer
eine Möglichkeit darstellt,
besitzt eine effizientere Lösung
dieses möglichen
Dilemmas eine Form, die anfangs Ereignisse, die als uninteressant
betrachtet werden, vor der Speicherung ausschließt. Die Speichervoraussetzung bzw.
Speicherqualifikation und das Triggern (Auslösen) sind zwei Arten, auf die
dies durchgeführt
wird. Die Speicherqualifikation beschränkt, welche Ereignisse in dem
Speicher zu jenen plaziert werden, die bestehende Kriterien erfüllen; z.
B. Daten, die von einer bestimmten Adresse in dem Speicher gelesen werden.
Da der Speicher endlich ist, wird der Speicher schließlich gefüllt, worauf
derselbe als kreisförmig
behandelt wird, und neue Daten die ältesten Daten überschreiben.
Das Triggern wird auf der anderen Seite verwendet, um das Auftreten
von einer bestimmten Bedingung zu erkennen, die das INTERESSIERENDE
EREIGNIS ist, und um anschließend
die Datenerfassungsphase der Messung (damit das interessierende
Ereignis nicht durch die anschließend erfaßten Daten überschrieben wird) (unmittelbar
oder schließlich)
zu beenden. Die gespeicherten Daten der Spur können mit einer Liste verglichen
werden, und wenn das Triggerereignis auf eine Art und Weise verwendet
wird, daß dasselbe
in der Mitte der vollständigen
Spurliste auftritt, dann zeigt die anschließende Untersuchung der Spurliste
Ereignisse, die zu dem Trigger-Ereignis geführt haben, sowie dieselben,
die danach aufgetreten sind. Es ist üblich, daß man spezifizieren kann, wo
in der Spurliste der Trigger erscheinen soll, und derselbe wird
auffallend als solcher in der Liste identifiziert.
-
Das
häufige
Erfassen der gewünschten
Daten hängt
davon ab, daß man
eine ausreichend bedeutungsvolle Trigger-Bedingung spezifizieren
kann. Das heißt,
die Trigger-Bedingung (die Trigger-Spezifikation) kann eine ziemlich
komplizierte Folge von Ereignissen, möglicherweise sogar Alternativen
betreffend, sein. Oftmals ist diese Aufgabe der Trigger-Spezifikationsentwicklung
problematisch, da, wenn bekannt ist, was falsch ist, normalerweise
kein Bedarf besteht, einen Trigger an erster Stelle zu spezifizieren.
Unter der Voraussetzung, daß ein
unbekanntes Problem besteht, ist man manchmal gezwungen, eine effektive
Trigger-Spezifikation durch eine aufeinanderfolgende Verfeinerung,
selbst unter Zuhilfenahme von leistungsfähigen Trigger-Verfahren, zu
entdecken. Dies hat zu der Entwicklung von vielen nützlichen
Trigger-Schemata
geführt,
denen Logikanalysatoren einen Großteil ihrer derzeitigen Nützlichkeit
verdanken.
-
Anfangs
wurden Trigger-Spezifikationen in booleschen Ausdrücken unter
Verwendung von Signalnamen, die den fabrikzugewiesenen Eingangskanalnamen
zugeordnet sind, die zu dem Analysator selbst gehören, und
nicht unter Verwendung von Namen, die dem untersuchten System zugeordnet
sind, beschrieben. Rechtzeitig ermöglichten es Analysatoren dem
Benutzer, zu spezifizieren, daß bestimmte Eingänge in den
Analysator als ein Feld, das durch einen Namen identifiziert wird, üblicherweise
ein Etikett bzw. eine Bezeichnung genannt, behandelt werden. Folglich
besitzt der Betreiber die Freiheit, Ereignisse hinsichtlich von
bedeutungsvolleren Beschreibern (Deskriptoren), wie z. B. ADDR (bezugnehmend auf
eine definierte Sammlung von 32 Eingängen, die eine Adresse darstellen),
DATEN (eine weitere benutzerdefinierte Sammlung von Eingängen) und
LESEN (eine Einzelbitsteuerleitung), zu beschreiben. Sobald diese
Entsprechungen eingerichtet sind, können die zugeordneten Bezeichnungen
als Variablen behandelt werden, was die Bildung von Beziehungen,
wie z. B. ADDR = XXXXXXXX16 ermöglicht.
Eine Trigger-Spezifikation ist eine Ansammlung von Bezeichnungen,
die als Operanden in Verbindung mit verschiedenen logischen Operatoren verwendet
werden, wie z. B. UND, ODER und NICHT, die möglicherweise Klammern umfassen
und die logische Ausdrücke
mit Konstanten (festen Werten) und den Beziehungen =, <und> bilden. Mit Bezeichnungen kann
wesentlich einfacher gearbeitet werden als beispielsweise mit Logikanalysatorkanalnummern,
da dieselben hinsichtlich des untersuchten Systems beschreibend
sind. Eine derartige textliche boolesche Beschreibung einer Trigger-Spezifikation ähnelt einem
Programmiersegment, das möglicherweise ähnlich zu
C ist. Mänche
Logikzustandsanalysatoren stellen diesen Textmodus der Trigger-Spezifikation dar.
Obwohl derselbe handlich ist, kann die textliche boolesche Darstellung
manchmal schwer korrekt zu erzeugen sein, insbesondere wenn komplizierte
Zeitfolgen betroffen sind. Nicht alle Benutzer finden eine solche
textliche Beschreibung angenehm, insbesondere wenn Zeit- oder Dauer-Beziehungen
zwischen den Signalen ausgedrückt
werden sollen.
-
Eine
gelegentlich starke Unzufriedenheit mit den textlichen symbolischen
booleschen Trigger-Spezifikationen hat zu der Entwicklung von graphischen
Verfahren der Trigger-Spezifikationen geführt. Diese Verfahren stellen
logische Signale als logische Signalformen dar, und der Benutzer
spezifiziert, welche Signalform (oder welche verwandte Familie von
Signalformen) die Trigger-Spezifikation bildet. Diese Beschreibungsweise
ist für
die meisten Benutzer eine natürlichere
Ausdrucksweise zum Beschreiben von bestimmten Beziehungsarten zwischen
interessierenden Signalen. Es gibt beispielsweise einen Logikanalysator
mit einem graphischen Modus einer Trigger-Spezifikation.
-
Die
zwei Trigger-Spezifikations-Verfahren, textlich und graphisch, werden
allgemein hinsichtlich ihrer Fähigkeiten
philosophisch als gleich betrachtet, dahingehend, daß das, was
mit dem einen Verfahren durchgeführt
werden kann, üblicherweise
mit dem anderen Verfahren durchgeführt werden kann. Das heißt jedoch,
niemand ist dazu gezwungen, dieselben als in allen Situationen gleich
einfach anzuwendend zu betrach ten. Einige Trigger-Spezifikations-Situationen
werden mit einer textlichen Beschreibung (durch mindestens einige
Benutzer) leichter gehandhabt, und andere Situationen werden leichter
mit der graphischen Beschreibung gehandhabt. Bekannte Logikanalysatoren
zwingen den Benutzer dazu, zwischen diesen zwei Verfahren auszuwählen.
-
Aus
der
DE 39 22 907 A1 ist
ein Schnittstellentester zur Prüfung
von synchronen Datenkommunikationssystemen bekannt. Der Schnittstellentester arbeitet
mit einer Menütechnik.
Innerhalb der Menütechnik
kann eine Triggerkonfiguration ausgewählt werden. In dem Menüpunkt "Triggerkonfiguration" wird die Möglichkeit
geboten, für
jeden Datenkanal eine Triggerbedingung einzustellen.
-
Aus
der
EP 0 291 301 A2 ist
bereits eine Benutzerschnittstelle für einen Logikanalysator bekannt.
Durch eine Verzögerungsauswahloperation kann
eine Triggerposition ausgewählt
werden.
-
Aus
der
US 5,953,009 A ist
bereits eine graphische Benutzerschnittstelle für ein Signalmesssystem bekannt.
Mittels sogenannter "Icons" kann eine gewünschte Signalformmessfunktion
ausgewählt werden.
-
Die
Aufgabe der vorliegenden Erfindung besteht darin, eine triggerbare
Signalerfassungs- und Anzeige-Vorrichtung und eine graphische Editorbildschirmdarstellung
zu schaffen, die eine einzelne Trigger-Spezifikation ermöglichen,
die die Vorteile von sowohl der graphischen als auch der textlichen
Trigger-Spezifikation kombiniert.
-
Diese
Aufgabe wird durch eine triggerbare Signalerfassungs- und Anzeige-Vorrichtung
gemäß Anspruch
1 und eine graphische Editorbildschirmdarstellung gemäß Anspruch
4 gelöst.
-
Eine
Lösung
des Problems einer Trigger-Spezifikations-Vorrichtung in einem Logikanalysator
besteht darin, die Fähig keiten
von sowohl der textlichen als auch der graphischen Beschreibung
in einer gemeinsamen Umgebung zu integrieren, so daß beide,
wie benötigt,
und in Verbindung mit der anderen verwendet werden können. Bei
einem exemplarischen Ausführungsbeispiel,
das beschrieben ist, kann eine Trigger-Spezifikation bis zu sechs "Schritte" aufweisen. Ein Schritt
kann als ein atomares Segment eines Flußdiagramms aufgefaßt werden,
das eine interessierende Größe oder
eine interessierende Bedingung betrifft oder untersucht. Diese Schritte
können
das Testen und eine Entscheidung betreffen, ob getriggert oder nicht
getriggert wird, oder ob zu einem nächsten Schritt fortgefahren
oder nicht fortgefahren wird. Ein gegebener Schritt (wie im vorhergehenden
definiert) kann entweder textlich oder graphisch sein. Eine GUI
(Graphische Benutzerschnittstelle (= Graphical User Interface),
wie bei Windows für
Computer, und nicht zu verwechseln mit 'graphisch' mit der Bedeutung 'signalformähnlich') in einem CRT-Bildschirm in Verbindung
mit einer Zeigevorrichtung (z. B. einer Maus) liefert die Darstellung der
integrierten textlichen und graphischen (signalformähnlichen)
Trigger-Spezifikations-Schritte.
-
Bevorzugte
Ausführungsbeispiele
der vorliegenden Erfindung werden nachfolgend unter Bezugnahme auf
die beigefügten
Zeichnungen näher
erläutert.
Es zeigen:
-
1A eine
Darstellung eines GUI-Bildschirmbilds für ein bekanntes textliches
Trigger-Spezifikations-Verfahren in einem Logikanalysator;
-
1B ein
schematisches Flußdiagrammsegment,
das logisch die Struktur eines Entscheidungsverfahrens zeigt, das
durch die textliche Trigger-Spezifikation von 1A durchgeführt wird;
-
2A eine
Darstellung eines GUI-Bildschirmbilds für ein bekanntes graphisches
Trigger-Spezifikations-Verfahren in einem Logikanalysator;
-
2B ein
schematisches Flußdiagrammsegment,
das logisch die Struktur eines Entscheidungsverfahrens zeigt, das
durch die graphische Trigger-Spezifikation von 2A durchgeführt wird;
-
3 eine
Darstellung eines GUI-Bildschirmbilds für ein Logikanalysator-Trigger-Spezifikationsverfahren,
das das Vermischen von Schritten, die auf eine textliche Art und
Weise beschrieben sind, und von Schritten ermöglicht, die auf eine graphische Art
und Weise beschrieben sind;
-
4 eine
Darstellung eines GUI-Bildschirmbilds, das in Verbindung mit der
Erzeugung und dem Editieren eines graphischen (signalformähnlichen)
Schritts in einer Trigger-Spezifikation für einen Logikanalysator verwendet
wird, der gemäß der Erfindung aufgebaut
ist; und
-
5 eine
Darstellung eines Menüs,
das in Verbindung mit dem GUI-Bildschirmbild von 4 nützlich ist.
-
Es
wird nun auf die 1A und 1B Bezug
genommen. 1A ist eine Darstellung eines GUI-Bildschirmbilds 1 für ein bekanntes
textliches Trigger-Spezifikations-Verfahren, das in einem Logikanalysator
verwendet wird. Das Bildschirmbild 1 weist ein Fenster 2 auf,
das einen Abschnitt 3 mit einer Liste von Schritten (15, 16, 17)
umfaßt,
die die tatsächliche
Trigger-Spezifikation sind. Ferner ist in dem Fenster 2 eine
Region 4 umfaßt,
das Reiter 5–9 oder
Streifen und eine Sammlung 10 von Ikons (oder Knöpfen mit
Etiketten bzw. Bezeichnungen, die aus Text und/oder Bildern gebildet
sind) aufweist. Die spezielle Sammlung von Ikons, die in der Region 4 vorhanden
ist, hängt
davon ab, welcher der Reiter 5–9 durch einen Bildschirmzeiger
(nicht gezeigt) angeklickt wurde. Die unterschiedlichen Reiter stellen verschiedene
Kategorien der Signalaktivität
dar, die beim Aufbau einer Trigger-Spezifikation interessant sein
könnten.
Im Prinzip können
alle Ikons auf einmal in der Region 4 sichtbar sein, mit
der Ausnahme, daß praktisch
so viele vorliegen, daß das
Bildschirmbild 1 als überfüllt erscheint.
Daher sind dieselben in Funktionskategorien gruppiert und werden
nach Bedarf sichtbar gemacht. In 1A entsprechen
die Ikons 11–14,
die in der Region 4 sichtbar sind, dem Flanke-Reiter 5.
Das Klicken auf einen Reiter macht eine andere Sammlung von Ikons
sichtbar.
-
Ein
Ikon, das in der Region 4 sichtbar ist, kann in die Region 3 gezogen
und fallengelassen werden, worauf dasselbe einen entsprechenden Schritt
in der Trigger-Spezifikation erzeugt. Die Figur zeigt drei existierende
Schritte, die SCHRITT 1 (15), SCHRITT 2 (16) und
SCHRITT 3 (17) genannt werden. Wenn das Ikon zwischen zwei
existierenden Schritten fallengelassen wird, wird ein neuer Schritt zwischen
denselben eingefügt.
Wenn dasselbe ähnlicherweise
vor oder nach einer existierenden Folge von Schritten fallengelassen
wird, wird ein neuer Schritt vor oder nach den existierenden Schritten
hinzugefügt.
(Ein Schritt wird gemäß einem
der üblichen und
herkömmlichen
Verfahren für
die Microsoft-Windows-Umgebung gelöscht. Der Schritt wird beispielsweise
hervorgehoben und dann die Entfernen-Taste gedrückt; oder es wird rechts geklickt,
während
sich der Bildschirmzeiger innerhalb des Schritts befindet, und es
wird Entfernen aus dem erscheinenden Menü ausgewählt.) Ein Schritt wird durch
ein Menü mit
einer bestimmten Struktur basierend auf der dem Ikon zugeordneten
Bedeutung beschrieben, und dies wird in verschiedenen Feldern und
Knöpfen,
die das Menü bilden,
widergespiegelt. Anfangs können
einige Felder (wie z. B. dieselben, die benutzerdefinierte Bezeichnungen
für Eingangskanäle aufnehmen)
leer sein, während
Modusspezifikationsanzeigen auf Vorgabewerte eingestellt sein können. In
jedem Fall füllt der
Benutzer, sobald ein Schritt an Ort und Stelle plaziert wurde, das
Menü darin
aus. Einige der zugeführten
Informationen können
Schritte miteinander in einer Folge verbinden, die von möglichen
Ereignissen abhängt.
Beispielsweise zeigt der SCHRITT 1 Bedingungen, bei denen der nächste Schritt
der SCHRITT 2 sein wird, und jene Bedingungen, bei denen der nächste Schritt
statt dessen der SCHRITT 3 sein wird. Die resultierende verbundene
Folge von Schritten ist gleich einem Flußdiagramm und bei einigen bekannten
Analysatoren kann dieses Flußdiagramm automatisch
auf Anfrage erzeugt werden. 1B ist ein
derartiges verallgemeinertes Flußdiagramm 18 von 1A.
-
Es
wird nun auf 2A und 2B Bezug genommen. 2A ist
eine Darstellung 19 eines GUI-Bildschirmbilds für ein bekanntes
graphisches (signalformbezogenes) Trigger-Spezifikations-Verfahren,
das in einem Logikanalysator verwendet wird. Das Bildschirmbild 19 weist
ein Fenster 20 auf, das einen Abschnitt 21 umfaßt, der
Signale auflistet, die zur Verwendung in der Trigger-Spezifikation
zur Verfügung stehen,
und ferner Abschnitte 22 und 23 umfaßt, die
eine Zwei-Schritt-Trigger-Spezifikation bilden. Bei dem Beispiel
von 2A sind die Regionen 22 und 23 Spalten
von verschiedenen Symbolen mit nützlichen
Bedeutungen. Beispielsweise zeigt das Symbol 24 in der
Region 22 an, daß sich
der Kanal 3 an der Prüfspitze 1 in
einem niedrigen Zustand befinden soll, während das Symbol 25 anzeigt,
daß sich der
Kanal an der Prüfspitze
in einem hohen Zustand befinden soll. Der Schritt 1 (der durch die
Region 22 definiert ist) ist aus mehreren derartigen Anzeigen gebildet,
wie es in der Spalte gezeigt ist. Die Legende 29 zeigt,
daß die
Bedingung, die durch die Region 22 definiert ist, mehr
als 16 Nanosekunden dauern muß. Der
Schritt 2 (Region 23) erfordert, daß eine steigende Flanke in
dem Kanal 4 der Prüfspitze 1 (Symbol 27)
vorhanden ist, und daß alle
anderen Signale egal (don't
cares) sind. Dies wird für
die verbleibenden Signale des Etiketts bzw. der Bezeichnung Bus 1 durch die
verschiedenen eingeklammerten X (26) angezeigt. Das durchgezogene
X 28 ist eine Abkürzungsweise,
um anzuzeigen, daß alle
Signale innerhalb des Etiketts Bus 2 egal sind. Rechts
der Triggerspezifikation erscheint eine Region 29, in der
Signalformdiagramme, die in der Art und Weise eines Zeitanalysators
gezeichnet sind, erscheinen, sobald Daten erfaßt und der Analysator getriggert
wurde.
-
2B stellt
das verallgemeinerte äquivalente
Flußdiagramm 30 der
Regionen 22 und 23 in 2A dar,
die die Zwei-Schritt-Trigger-Spezifikation bilden.
-
Details
darüber,
wie GUIs, wie dieselben, die in 1A und 2A gezeigt
sind, den Betrieb eines Logikanalysators steuern können, sind
in vorhergehenden Patentanmeldungen erläutert. Dort finden sich umfassende
Blockdiagramme und eingehende Hardware- und Software-Systembeschreibungen, die
die Steuerung einer Vorrichtung (z. B. eines Logikanalysators) mit
der Wechselwirkung mit einer GUI über eine Anzeige und eine Zeigevorrichtung,
wie z. B. eine Maus, in Verbindung bringen.
-
Es
wird Fachleuten ferner offensichtlich sein, daß die textlichen und graphischen
Modi des Steuerns der Trigger-Spezifikation, sowie der kombinierte eine
Modus, der im folgenden beschrieben ist, allgemein auf andere Formen
einer getriggerten Signalerfassungsausrüstung als Logikanalysatoren,
einschließlich,
jedoch nicht darauf begrenzt, Zeitanalysatoren, Protokollanalysatoren
und Digitaloszilloskopen, anwendbar sind.
-
Es
wird nun auf 3 Bezug genommen, in der eine
Darstellung eines GUI-Bildschirmbilds 31 zum Definieren
einer Trigger-Spezifikation in einem Logikanalysator gezeigt ist.
Das Bildschirmbild 31 weist ein Fenster 32 auf,
das einen Abschnitt 33 mit einer Liste von Schritten (35, 36 und 37)
aufweist, die die tatsächliche
Trigger-Spezifikation sind. Das Ausführungsbeispiel von 3 ermöglicht das
Vermischen von textlich definierten und graphisch definierten (d.
h. signalformähnlichen)
Trigger-Spezifikations-Schritten. Bei dem speziellen Beispiel, das
in 3 gezeigt ist, sind die Schritte 35 und 36 textlich, während die
Schritte 37 auf eine signalformähnliche (graphische) Art und
Weise definiert sind. (Um sicherzugehen, ist der Schritt 37 in 3 eine
Textlegende. Diese Legende ist jedoch eine nicht-editierbare Zusammenfassung
und erscheint nach der tatsächlichen
Definitionsaktivität,
die vollsändig
graphisch ist und in Verbindung mit 4 erörtert ist.) Um
fortzufahren, umfaßt
das Ausführungsbeispiel von 3 viele
der Merkmale, die in Verbindung mit 1A erklärt sind,
und denen entsprechend die gleichen Bezugszeichen, wo es angebracht
ist, zugewiesen sind. In dem Fenster 32 ist ferner eine
Region 34 umfaßt,
die Streifen bzw. Reiter (5–9) und eine Sammlung 38 von
Ikons (11–14 und 39)
aufweist. Wie im vorhergehenden können die Mitglieder dieser Sammlung 38 lediglich
Ikons oder Knöpfe
oder andere umrissene Regionen des Bildschirmbilds sein, die Bilder
und/oder Text enthalten, die die Funktion derselben identifizieren.
Auf eine bekannte Art und Weise sind dieselben jeweils eine "Steuerung", die etwas durchführt, wenn
die Zeigevorrichtung den Bildschirmzeiger (nicht gezeigt) in den
jeweiligen Grenzen derselben positioniert und anschließend geklickt wird,
oder vorzugsweise, wenn dieselben zu einer bedeutungsvollen Position
in dem Listenbereich 33 gezogen und dann fallengelassen
werden (dragged and dropped).
-
Dementsprechend
resultiert das Bildschirmbild 31 daraus, daß zwei textliche
Schritte 35 und 36 durch Verfahren definiert werden,
die in Verbindung mit 1A beschrieben sind. Der Schritt 37 ist
ein graphisch definierter Schritt, dessen Hauptbedeutung oder Hauptbedingung
mit Worten (40) gezeigt ist, der jedoch anfangs mittels
der graphischen (Signalform-)Editorbildschirmdarstellung 43 von 4 definiert
wurde. Es sei bemerkt, daß nicht
erwähnt wurde,
daß die
Hauptbedeutung oder Hauptbedingung textlich, d. h. in Worten, angezeigt
wird. Das Format der Anzeige 40 unterscheidet sich jedoch
von demselben des Schritts 1 und des Schritts 2 dahingehend, daß es keine
Auswahlkästen
gibt, deren Inhalt gescrollt (gerollt) bzw. bewegt werden kann,
um eine Auswahl zu treffen. Die Anzeige 40 ist eine zusammengefaßte lesbare
Legende, die die Signalformdefinitionsaktivität widerspiegelt, die mit der
Bildschirmdarstellung 43 durchgeführt wird. Der Schritt 3 (37) kann,
wenn notwendig, geändert
werden, jedoch nicht durch Manipulieren der Zeichen, die in der
Anzeige 40 erscheinen. Statt dessen muß der Editier-Knopf 41 angeklickt
werden, was dann eine ausgefüllte
graphische (Signalform-)Editorbildschirmdarstellung 43 von 4 zurückgibt.
Die Bildschirmdarstellung wird dann, wie notwendig, geändert, und
der OK-Knopf 45 wird geklickt, wenn das Editieren beendet
ist. Eine zu 3 ähnliche Bildschirmdarstellung erscheint
dann wieder, deren Region 37 die Änderungen widerspiegelt, die
unter Verwendung der graphischen Editorbildschirmdarstellung 43 durchgeführt wurden.
-
Das
Verfahren ist im folgenden detaillierter dargestellt. Das Ikon (Definieren
des Triggers unter Verwendung der Signalform) wird in den Listenbereich 33 gezogen
und dann fallengelassen. Dasselbe hätte dort vor der Definition
des Schritts 1 und des Schritts 2 (wobei in diesem Fall der Schritt
3 als Schritt 1 beginnt und zwei neue Schritte später vor demselben
eingefügt
werden) fallengelassen werden können,
oder der Schritt 1 und der Schritt 2 hätten gefolgt von dem Schritt
3 zuerst spezifiziert werden können.
Alternativ kann der Schritt 3 anfangs dem Schritt 1 (derselbe wäre der Schritt
2) folgen, und das, was nun der Schritt 2 ist, kann zwischen denselben
eingefügt
werden. Die Folge wurde jedoch früher erzeugt. Zu dem Zeitpunkt,
zu dem das Ikon 39 in den Listenbereich 33 fallengelassen
wurde, erschien dann die graphische Editorbildschirmdarstellung 43 von 4,
wurde anschliessend ausgefüllt,
und der OK-Knopf 45 desselben wurde geklickt. Die graphische
Editorbildschirmdarstellung 43 verschwand dann und die
Bildschirmdarstellung 32 von 3 erschien.
Wenn während
der Anwesenheit der graphischen Editorbildschirmdarstellung 43 der
Betreiber die Vorzüge
oder die Änderungen,
die während
des Editierens durchgeführt
wurden, überdenkt,
kann derselbe auf den Abbrechen-Knopf anstelle des OK-Knopfs drücken, um
die Editier-Sitzung zu beenden, ohne jegliche Änderungen durchzuführen. Um den
Schritt 3 zu entfernen, kehrt der Betreiber zu der Bildschirmdarstellung 31 von 3 zurück, und
kann Microsoft-Windows-basierte Entfernungsvorrichtungen, die im
vorhergehenden erwähnt
sind, verwenden.
-
Die
graphische Editorbildschirmdarstellung 43 ermöglicht signalformähnliche
Beschreibungen von Trigger-Bedingungen und wird verwendet, um zu definieren,
was die Hauptbedeutung oder die Hauptbedingung eines Schritts in
einer Trigger-Spezifikation genannt wird. Was zu tun ist (Triggern
und Füllen des
Speichers, oder, Gehe zu einem <weiteren Schritt>) ist keine signalformähnliche
Idee und wird anschließend
durch Auswählen
von Wahlmöglichkeiten
in einem Menükasten 42 (von 3)
ausgefüllt.
-
Die
Hauptbedeutung oder die Hauptbedingung des Schritts 3 in 3 ist
das "Finden einer steigenden
Flanke von W/R UND DATEN = 23 gefolgt von möglicherweise einer steigenden
Flan ke von ALE".
Das heißt,
es gibt einzelne Signale W/R und ALE und eine Sammlung von Signalen,
die mit DATEN bezeichnet sind. Die Bedingung wird erfüllt, wenn
das Signal W/R eine steigende Flanke aufweist, die mit den DATEN-Signalen übereinstimmt, die
einen Wert von 23 darstellen, und dann einige Zeit später eine
steigende Flanke von ALE auftritt. Wenn diese Hauptbedingung erfüllt ist,
muß gemäß dem Menükasten 42 der
Analysator triggern und den Speicher füllen.
-
Bezugnehmend
nun auf 4 ist in derselben eine Darstellung
einer graphischen Editorbildschirmdarstellung 43 gezeigt,
die beim Durchführen der
Definitionen verwendet werden kann, die oben in Verbindung mit Schritt
3 (37) von 3 beschrieben sind. Die graphische
Editorbildschirmdarstellung 43 befindet sich in einem Fenster 44,
das erscheint, wenn das Ikon 39 (von 3)
angeklickt wird. Die graphische Editorbildschirmdarstellung 43 umfaßt eine
Sammlung 49 von vorher definierten Signalnamen und Busnamen,
für das
die graphische Editiervorrichtung verwendet werden kann. Die Sammlung 49 ist
vertikal (als ob dieselbe eine Spalte ist, obwohl dies nicht so
genannt wird, da bevorzugt wird, dieses Wort für etwas anderes zu verwenden)
angeordnet und erscheint benachbart zu einer Anzahl von Eintragsspalten 50, 51 und 52.
Jede dieser Spalten (50–52) stellt von links
nach rechts betrachtet spätere Zeitpunkte
dar. Jede Spalte umfaßt
entlang der vertikalen Richtung derselben eine Zahl von Einträgen: einen
für jeden
Namen in der Sammlung 49. Die Spalteneinträge, die
dem gleichen Signal oder dem gleichen Busnamen entsprechen, befinden
sich auf gleicher Höhe,
was eine Matrix von Zeilen und Spalten erzeugt. Die Zeilen sind
Namen und die Spalten sind (von links nach rechts) folgende Zeitpunkte.
Ein Eintrag ist der Schnittpunkt einer Zeile und einer Spalte und
kann als eine Bedingung definiert sein, die in einem Schritt einer
Trigger-Spezifikation umfaßt
sein soll. Kästen 55, 56 und 57 sind
Beispiele. In dem Kasten 55 ist ein Eintrag definiert,
der eine steigende Flanke in dem Signal W/R erfordert; der Kasten 56 zeigt
an, daß das
Signal ALE egal (Don't
Care) (zu dem Zeitpunkt, zu dem die steigen de Flanke des W/R auftritt)
ist; und bei dem Kasten 57 ist ein Eintrag definiert, der
erfordert, daß der
Bus, der mit DATEN bezeichnet ist, den Wert 23 während der
steigenden Flanke des Signals W/R zeigt. Der Kasten 56 (und tatsächlich alle
Kästen
für die
verschiedenen Einträge)
ist anfangs auf egal bei einem ersten Aufruf der graphischen Editorbildschirmdarstellung 43 für einen gegebenen
Schritt in einer Trigger-Spezifikation eingestellt. Folglich muß der Kasten 56 nicht
explizit auf egal eingestellt werden, solange dies nicht durchgeführt wird,
um denselben auf egal einzustellen, nachdem derselbe vorher auf
etwas anderes eingestellt wurde. Die Egal-Bedingung ist durch ein
Kreuzschraffierungsmuster für
Einträge,
die einzelnen Signalen entsprechen, und durch Symbole 'xx' für Einträge, die
Bussen entsprechen, gezeigt.
-
Bei
dem Beispiel, das in 4 gezeigt ist, weist die Spalte 51 einen
Eintrag für
das Signal ALE auf, der eine steigende Flanke erfordert. Dieses
Erfordernis wird als "gefolgt
von" impliziert,
indem erwartet wird, daß Ereignisse,
die sich auf die Spalte 51 beziehen, folgend zu denselben
in der Spalte 50 auftreten. Es sollte mehr über dies
in Verbindung mit 5 gesagt werden.
-
Der
Inhalt eines speziellen Eintrags, wie z. B. 47, wird durch
Positionieren des Bildschirmzeigers (nicht gezeigt) über dem
interessierenden Eintrag und dann durch Klicken spezifiziert. Ein
Menü 48 erscheint über dem
Eintrag (47) und die Zeigevorrichtung (z. B. eine Maus)
wird verwendet, um den Bildschirmzeiger zu steuern, um einen Eintrag
aus diesem Menü auszuwählen. Die
Einträge
in dem Menü 48 stellen
die verschiedenen Möglichkeiten
für das Signalformverhalten
dar, die ein entsprechendes ikonisches Symbol aufweisen können, das
in dem Eintrag (47) plaziert ist. Bei dem Beispiel sind
die Menüeinträge Textlegenden:
steigende Flanke, fallende Flanke, jede Flanke, hoher Zustand, niedriger
Zustand und egal. Anstelle solcher Textlegenden kann das Menü 48 ikonische
Symbole selbst aufweisen. Es wird entschieden, Legenden zu verwenden,
um die Auswahlen zu beschreiben, da dies eine mögliche Kreisdefinitionssituation
vermeidet, bei der eine ikonische Darstellung eines Signalformübergangs durch
sich selbst anstatt durch Text angezeigt wird, der in einer menschlichen
Sprache beschreibend ist. Es scheint eine Sache der Auswahl zu sein,
ob ein Menü 48 Text
oder ikonische Symbole enthält.
Die meisten Benutzer besitzen möglicherweise
zu beidem einen guten Bezug.
-
Es
wird nun kurz 5 betrachtet. Dieselbe stellt
ein Menü 58 dar,
das in einem Fenster 59 erscheint, wenn entweder der Kasten 53 oder
der Kasten 54 (in 4) angeklickt
wird. Das Menü 58 ermöglicht es,
daß die
implizierte "Gefolgt-Von-"Beziehung, die oben
erwähnt
ist, ausdrücklich
definiert wird. Anfangs wird dieselbe auf "unbestimmt" eingestellt, das heißt, daß die Spalteneinträge anfangs
auf egal eingestellt werden. Das Menü 58 zeigt die drei Grundkategorien:
unbestimmte Zeitperiode (60); kleiner als (61);
und größer als
(62). Eine herkömmliche Microsoft-Windows-Schnittstelle
ermöglicht
die Auswahl von einer dieser Wahlmöglichkeiten. Wenn die Wahlmöglichkeit
beispielsweise kleiner als (61) ist, dann ist eine numerisch
ausgedrückte
Zeitperiode erforderlich. Dieselbe wird einfach eingetippt, während der
Bildschirmzeiger innerhalb des Kastens 63 positioniert
ist, und der Kasten 64 ist selbst ein kleiner Menükasten,
um die Auswahl der Zeiteinheit zu ermöglichen. Die Wahlmöglichkeit 62 (größer als)
weist ähnliche
Kästen
für die
Spezifikation eines numerischen Zeitintervalls auf. Sobald die gewünschte Zeitbeziehung
für zwei
benachbarte Spalten in 4 (Knopf 53 für die Spalten 50–51 oder
Knopf 54 für
die Spalten 51–52)
definiert ist, wird das Menü 58 durch Klicken
auf den OK-Knopf 65 geschlossen bzw. beendet. Wenn gewünscht, kann
ein Aufruf des Menüs 58 durch
Klicken auf den Abbrechen-Knopf 66 abgebrochen
werden.
-
Bei
einem bevorzugten Ausführungsbeispiel kann
mehr als ein Eintrag in einer Spalte (51–52)
definiert werden, solange die verschiedenen Definitionen nicht mehr
als einen Übergang
betreffen. Das Spezifizieren eines hohen Zustands, eines niedrigen Zustands
oder von egal betrifft nicht die Erfordernis eines Übergangs,
dies ist jedoch bei den Wahlmöglichkeiten
(in dem Menü 48)
steigende Flanke, fallende Flanke und jede Flanke der Fall. Die
Gründe
dafür sind
teilweise technisch und teilweise psychologisch. Es nimmt nahezu
jedermann an, daß,
wenn eine Signalformdarstellung betrachtet wird, die zwei Flanken,
eine unter der anderen, zeigt, dieselben zum gleichen Zeitpunkt
auftreten (oder nicht auftreten), oder wenn eine Zeitachse vorhanden
ist, innerhalb eines Zeitunterschieds auftreten, der durch Untersuchung
des Trennungsabstands entlang der Achse feststellbar ist. Diese
Annahme führt
naturgemäß zu der
Idee, daß das
Definieren von zwei Übergängen, einer über dem
anderen (d. h. als unterschiedliche Einträge in einer Spalte, selbst
wenn dieselben durch einen weiteren Eintrag getrennt sind), das "UND" (die logische Konjunktion)
der zwei spezifizierten Übergänge bedeutet.
(Es bedeutet tatsächlich,
daß für jede andere
Kombination von Definitionen – lediglich zwei
oder mehr übergänge ausgeschlossen
werden sollen.) Die Darstellung der ikonischen Signalformsegmente
in 4 ist jedoch nicht eine, die entlang einer echt
abgestuften Zeitachse angeordnet ist. Von allen Ereignissen innerhalb
einer Spalte wird angenommen, daß dieselben innerhalb eines
bestimmten Zeitquantums auftreten, unabhängig davon, ob dieselben tatsächlich auftraten
oder nicht. Aufgrund der Art und Weise, mit der die Erfassungshardware
des Analysators arbeitet, ist es schwierig oder unmöglich, einen
Trigger-Spezifikations-Schritt zu definieren, der die echte Gleichzeitigkeit
von Übergängen in
zwei getrennten Signalen erfordert, und es kann erwartet werden,
daß die
Betriebsanleitung für
einen Logikanalysator eine bestimmte Länge besitzt, um Benutzer davor
zu warnen, daß sie
nicht das erhalten, was sie erwarten, wenn dieselben solche Trigger-Spezifikationen
durchführen.
(Es liegt nicht so sehr daran, daß dies absolut verboten ist;
die Textdefinitionen werden dies ermöglichen. Die graphische Definition
wird, wenn ermöglicht,
jedoch so erscheinen, daß mehr versprochen
wird, als wahrscheinlich erwartet werden kann.) Benutzern, die mit
Logikanalysatoren vertraut sind, wird diese Erörterung offensichtlich sein, und
sie werden sich erinnern, daß die
beste Art und Weise, um das "UND" von Übergängen zu
erhalten, die Zuhilfenahme einer speziellen Schaltungsanordnung
auf dem Sondenspitzenniveau ist. In jedem Fall ermöglicht die
Bildschirmdarstellung 43 von 4 nicht
mehrere Übergänge in einer
Spalte, selbst wenn eine derartige "UND"-Verknüpfung mit
der textlichen Definitionsbildschirmdarstellung spezifiziert werden
kann.
-
Eine ähnliche
Situation betrifft das Thema des Spezifizierens des "ODER" (der logischen Disjunktion)
von zwei Signalformbedingungen, egal ob Übergänge oder etwas anderes. Ein
Startpunkt dieser Erörterung
ist die Beobachtung, daß ein
spezielles Signalformdiagramm für
Regionen, mit Ausnahme für
Regionen, die als egal gezeigt sind, ziemlich klar dahingehend ist,
was dasselbe beschreibt. Es gibt keine allgemein akzeptierten Übereinkünfte zum Darstellen
von alternativen Umständen,
insbesondere wenn eine Folge von zu beschreibenden Ereignissen auftritt.
(Wenn dies entsprechend in einem Flußdiagramm passiert, breitet
sich dasselbe aus, um alle Möglichkeiten
zu umfassen. Bei Signalformen ist dies nicht der Fall.) Dementsprechend
ist der Versuch, intuitiv und herkömmlich das "ODER" in
einer graphischen Definition eines Trigger-Spezifikations-Schritts anzuzeigen,
gefährlich,
obwohl frei zugegeben wird, daß es
verständlich
ist, daß man
auf das "Signalformereignis
A" ODER das "Signalformereignis
B" triggern möchte, wobei
A und B alles sein können,
was sonst frei als ein Eintrag in einer Spalte (50–52)
der graphischen Editorbildschirmdarstellung 43 definiert werden
kann. Es ist richtig, daß eine
bestimmte Anzeige der "ODER"-Bedingung zusammengestellt werden
kann. Wie immer dieselbe aussieht, sie sollte keine Inkonsistenz
einführen.
Beispielsweise wird angenommen, daß es eine schlechte Wahl ist,
zu ermöglichen,
daß mehrere Übergänge in einer
Spalte definiert werden können,
und dieselben als Übergänge, die "ODER"-verknüpft werden
sollen, aufgefaßt werden.
Es ist ein ziemliches Unterfangen für den unvorsichtigen Betreiber.
Schließlich
bedeuten alle anderen mehrfachen Definitionen in einer Spalte nicht "ODER", sie bedeuten "UND". Und wenn dies trotzdem
implementiert ist, was kann dann unternommen werden, um "ODER" zwischen Nicht-Übergangs-Ereignissen
anzuzeigen? Zu gefährlich!
Dies ist insbesondere hinsichtlich der Tatsache der Fall, daß die textliche
Definitionsvorrichtung die "ODER"-Situation bereits
mit einer großen
Eleganz handhabt. Folglich ist bei dem hierin beschriebenen bevorzugten
Ausführungsbeispiel
kein "ODER"-Mechanismus für die graphische
Definition eines Trigger-Spezifikations-Schritts vorgesehen.
-
Es
wird wiederum auf 4 Bezug genommen, und es wird
beobachtet, daß die
graphische Editorbildschirmdarstellung 43 drei Spalten 50–52 aufweist.
Bei einem bevorzugten Ausführungsbeispiel
erscheinen diese Spalten einfach als Teil der Bildschirmdarstellung.
Wenn eine Spalte ausreichend ist, dann werden die anderen beiden
als egal belassen und alles ist gut. Wenn zwei Spalten benötigt werden,
dann werden die verbleibenden zwei Spalten verwendet und die rechte
wird als egal belassen. Alle drei Spalten können, wenn notwendig, abhängig von
der Verfügbarkeit
dessen, was als "Trigger-Betriebsmittel" bekannt ist, definiert
werden. Dies sind die Hardware-Elemente, die neu konfiguriert und durch
die steuernden Algorithmen innerhalb des Logikanalysators für den Zweck
des Erfassens des Trigger-Ereignisses oder der gewünschten
Folge von Ereignissen in Echtzeit angewendet werden. Diese Betriebsmittel
tragen zu der Größe, Komplexität und dem
Aufwand des Logikanalysators bei und sind allgemein begrenzt. Es
sind Trigger-Spezifikationen vorstellbar, die über der Kapazität des Analysators liegen,
obwohl die einzelnen Komponentenschritte der Trigger-Spezifikation
innerhalb der allgemeinen Fähigkeiten
desselben liegen. Eine derartige Situation wird erzeugt, wenn der
Analysator einfach nicht die Vielfalt der erforderlichen Trigger-Betriebsmittel besitzt.
Dementsprechend wird angenommen, daß für das vorliegende Ausführungsbeispiel
drei Spalten ausreichen, obwohl zugegeben wird, daß über eine Vorrichtung
zum Hinzufügen,
Entfernen und Einfügen
von Spalten in einer Bildschirmdar stellung, wie z. B. einer graphischen
Editorbildschirmdarstellung 43, nachgedacht werden kann.
Während
dies tatsächlich durchgeführt werden
kann, deuten die praktische Grenze der Trigger-Betriebsmittel und
die Studiendaten, die anzeigen, daß wenige Benutzer jemals mehr als
drei Spalten benötigen,
darauf hin, daß das
bevorzugte Ausführungsbeispiel
der drei Spalten derzeit für
die große
Mehrheit der Fälle
ausreichend ist.
-
Es
werden nun Alternativen zu dem betrachtet, was in 3 dargestellt
ist. Es sei in Erinnerung gerufen, daß ausführlich erörtert wurde, wie der Schritt 37 in
der Bildschirmdarstellung 31 als eine nicht-editierbare
lesbare Zusammenfassungslegende dargestellt wird. Obwohl dies derzeit
bevorzugt wird, muß dies
nicht immer so sein. Der Hauptanstoß besteht darin, ein Vermischen
von textlichen und graphischen Definitionen vorzusehen. In dem Listenbereich 33 der
Bildschirmdarstellung 31 werden die textlich definierten
Schritte (35, 36) in ihrer Textform belassen.
Der Schritt 37 kann ebenfalls in der graphischen Editorform
desselben belassen werden. Dies wurde tatsächlich versucht und getestet.
Obwohl dies sehr viel Bildschirmraum verbraucht, funktioniert es. Es
gibt jedoch Lösungen
dafür,
wie z. B. Mehr-Seiten-Bildschirmdarstellungen und eine überlappende Anzeige
von Schritten, jeder in einem eigenen Fenster. Der Bildschirmzeiger
kann das gewünschte Fenster
durch Klicken auf dasselbe nach oben bringen. Da die Schritte bezeichnet
sind, ist die Reihenfolge, mit der dieselben erscheinen oder in
einem Eltern-Fenster untersucht werden, prinzipiell irrelevant. Das
Anordnen ist jedoch dennoch zweckdienlich, und ein Knopf kann vorgesehen
sein, um die überlappende
Anzeige in einer natürlichen
Anordnung bei der Beendigung eines Editierens oder einer Untersuchung
wiederherzustellen. Trotz dieser Möglichkeit legt ein weiterer
Grund das Verwenden des offenbarten Schemas nahes Benutzer bevorzugen
es, die Endresultate in einem allgemein konsistenten Format zu sehen,
sobald die Definitionsaktivitäten
beendet sind. Es wird hier gewählt,
ein Format zu verwenden, das ähnlich
zu dem Text formst für
Anzeigen in dem Listenbereich von graphisch definierten Trigger-Spezifikations-Schritten
(wie z. B. der Schritt 37) ist. Dies befriedigt die sich
durch Tests zeigende Vorliebe des Benutzers, erhält jedoch eine ohne weiteres
erkennbare Anzeige der graphischen Ursprünge des Schritts. Bei dem bevorzugten
Ausführungsbeispiel werden
der Editier-Knopf 41 und die Dienste der graphischen Editorbildschirmdarstellung 43 benötigt, um einen
graphisch definierten Schritt zu verändern.
-
Diese
letzte Bemerkung führt
zu einer weiteren Betrachtung. Wenn die textliche Definitionsvorrichtung
alles definieren kann, was die graphische Definition definieren
kann (die Letztere ist ein Funktionsteilsatz der Ersteren), warum
sollten dann nicht alle Enddefinitionen in dem Listenbereich als
textlich angezeigt werden, und dann jeder Schritt entweder textlich
oder graphisch, wie gewünscht,
editiert werden. Im Prinzip kann dies durchgeführt werden, ist jedoch kompliziert.
Zunächst
wurde erkannt, daß es Umstände gibt,
die sich einfach nicht für
die Darstellung in beiden Formaten eignen: Z. B. beziehen sich Wenn/Dann/Sonst-
und Gehezu- bzw. If/Then/Else- und Go-To-Konstruktionen nicht auf
Signalformen. Ferner kann das Anzeigen des mehrfachen Auftretens
von Dingen in einem Signalformformat ohne weiteres aus der Hand
geraten. Zweitens gibt es andere Umstände (die das "ODER-Verknüpfen" und die wirkliche
Bedeutung des "UND-Verknüpfens" betreffen), die
unangenehm oder fehlleitend sind, wenn dieselben als ikonische Darstellung
eines Signalformverhaltens dargestellt werden. Aus diesen Gründen wird
entschieden, nicht das Abbilden von textlich definierten Schritten
in der graphischen Vorrichtung zu unterstützen. Es gibt zu viele Ausnahmen
und lose Enden. Eine derartige Umgebung fördert tatsächlich Betreiberfehler und
tendiert dazu, eine Frustration zu erzeugen anstatt eine Hilfe und
eine intuitiv leichte Anwendung vorzusehen. Es wird daher entschieden, daß die graphisch
definierten Trigger-Spezifikations-Schritte graphisch editiert werden
sollten, und daß es
daher wünschenswert
ist, daß die
textlichen und graphischen Endresultate in dem Listenbereich ohne
weiteres unterscheidbar gemacht werden, um die Auswahl der geeigneten
Editiervorrichtung zu erleichtern.