DE102005041312A1

DE102005041312A1 - Speicherzugriff auf virtuelles Targetgerät

Info

Publication number: DE102005041312A1
Application number: DE102005041312A
Authority: DE
Inventors: Michael Fiedler; Ralf Findeisen; Michael Grell; Matthias Lenk
Original assignee: Advanced Micro Devices Inc
Current assignee: Chronocloud Medtech (shanghai) Co Ltd Cn
Priority date: 2005-08-31
Filing date: 2005-08-31
Publication date: 2007-03-15
Also published as: US7672828B2; US20070067151A1

Abstract

Es wird eine Softwareentwicklungstechnik bereitgestellt, die Targetsystem-Virtualisierungssoftware benutzt, welche das Verhalten eines Targetsystems simuliert. Ein Targetgerätetreiber, der auf einem Host-System läuft, gibt Speicherzugriffsbefehle statt an eine Speicherschnittstelleneinheit des Host-Systems an die Targetsystem-Virtualisierungssoftware aus. Die Speicherschnittstelleneinheit kann eine SRAM- (statischer Speicher mit wahlfreiem Zugriff; "Static Random Access Memory") Schnittestelle sein. Das Targetsystem kann ein EGPRS- (verbesserter allgmeiner paketorientierter Funkdienst; "Enhanced General Packet Radio Service") Modem sein.

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Die Erfindung betrifft Softwareentwicklung im Allgemeinen und insbesondere die Entwicklung und das Testen von Gerätetreibern für Targetsysteme (Zielsysteme; target systems"), die in einem Host-System benutzt werden können.

Host-Systeme wie Personal Computer, Notebooks, Palmtops oder Ähnliches haben manchmal Targetsysteme eingebettet. Solche eingebetteten Targetsysteme können integrierte Schaltkreischips, Chipsätze, Prozessoren oder Leiterplatten (gedruckte Schaltungen; „printed circuit boards") oder andere Arten von Hardwareeinheiten sein. Die Targetsysteme fügen dem Host-System Funktionalität hinzu, welche dem Host-System ohne das eingebettete Targetgerät nicht verfügbare wäre.

Damit das eingebettete Targetsystem richtig arbeitet, kann das Host-System dedizierte auf dem Host-System laufende Treibersoftware erfordern. Dieser Gerätetreiber gibt Daten an das eingebettete Target aus und empfängt Daten von ihm in einem speziellen Format, das bestimmten Protokollen genügt.

Solche Targetgerätetreiber müssen auf dem Host-System entwickelt und getestet werden, um sicher zu sein, dass das Host-System, das das Targetsystem eingebettet hat, richtig arbeitet. Somit erfordert die Entwicklung von Gerätetreibern das Vorhandensein eines Targetgeräts in dem Host-System.

Wenn ein neues Hardware-Targetgerät entwickelt werden soll, werden die Entwicklung und das Testen der Treibersoftware verschoben, bis ein Targetsystem-Muster für die Softwareentwickler verfügbar ist. Selbst wenn für die Softwareentwicklung ein früher Pro totyp des Targetsystems benutzt wird, besteht eine Unsicherheit, dass die entgültige Hardware-Implementierung verändert wird. Das heißt. es können Situationen entstehen, in denen beispielsweise in einer Hardware-Simulationsumgebung bereits neue Hardware existiert, aber noch keine verlässlich arbeitende Treibersoftware verfügbar ist.

ÜBERSICHT ÜBER DIE ERFINDUNG

Es wird eine Softwareentwicklungs- und -testtechnik bereitgestellt, die verbesserte Verlässlichkeit und Effizienz aufweist, insbesondere, wenn ein Targetsystem neue Funktionalität herausbringt.

In einer Ausgestaltung wird ein computerlesbares Speichermedium bereitgestellt, welches Befehle speichert, die, wenn sie durch einen Prozessor eines Host-Systems ausgeführt werden, den Prozessor dazu veranlassen, eine Speicherschnittstelle, mit der das Targetsystem verbunden werden kann, zu simulieren, indem ein Softwaremodul eine virtuelle Speicherschnittstelleneinheit implementiert. Die virtuelle Speicherschnittstelleneinheit generiert eine Targetsystem-Registerkarte („target system register map") in einem Speicher des Host-Systems. Die Targetsystem-Registerkarte ist durch das Host-System adressierbar, wenn mit der Speicherschnittstelle kein Targetsystem verbunden ist.

Gemäß einer weiteren Ausgestaltung wird ein Verfahren zum Testen eines auf einem Host-System, an das ein Targetsystem gekoppelt werden kann, laufenden Target-Gerätetreibers bereitgestellt. Der Target-Gerätetreiber ist dazu konfiguriert, Speicherlese- und/oder -schreibbefehle an eine Speicherschnittstelleneinheit des Host-Systems auszugeben, um auf das Targetsystem zuzugreifen (anzusteuern, aufzurufen; „access"), wenn es an das Host-System gekoppelt ist. Das Verfahren umfasst das Ausführen (Betreiben, Laufen lassen; „running") mindestens eines ersten Teils einer Targetsystem-Virtualisierungssoftware, die das Verhalten des Targetsystems simuliert, wenn das Targetsystem nicht an das Host-System gekoppelt ist, und das Veranlassen des Target-Gerätetreibers, Speicherlese- und/oder -schreibbefehle an die Targetsystem-Virtualisierungssoftware anstatt an die Speicherschnittstelleneinheit auszugeben.

Eine wiederum weitere Ausgestaltung betrifft ein Softwareentwicklungssystem, das in der Lage ist, einem Benutzer zu erlauben, einen EGPRS- (verbesserter allgemeiner paketorientierter Funkdienst; „Enhanced General Packet Radio Service") Modemgerätetreiber zu entwickeln und zu testen, selbst wenn ein EGPRS-Modemgerät nicht verfügbar ist. Das Softwareentwicklungssystem ist in der Lage, ein virtuelles EGPRS-Modem zu implementieren und durch den EGPRS-Modemgerätetreiber vorgenommene Speicherzugriffe an das virtuelle EGPRS-Modem umzuleiten. Das virtuelle EGPRS-Modem ist in der Lage, auf die Speicherzugriffe in einer Weise zu antworten, die es dem EGPRS-Modemgerätetreiber erlaubt, zu arbeiten, als wenn die Speicherzugriffe an ein existierendes EGPRS-Modemgerät vorgenommen worden wären.

KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die beigefügten Zeichnungen sind in die Beschreibung eingefügt und bilden einen Teil derselben zum Zwecke der Erläuterung der Prinzipien der Erfindung. Die Zeichnungen sind nicht als die Erfindung auf nur die veranschaulichten und beschriebenen Beispiele, wie die Erfindung gemacht und benutzt werden kann, beschränkend zu verstehen. Weitere Merkmale und Vorteile werden aus der folgenden und genaueren Beschreibung der Erfindung ersichtlich werden, wie in den beigefügten Zeichnungen veranschaulicht, wobei:
1 ein Blockdiagramm ist, das Komponenten eines Host-Systems gemäß einer Ausgestaltung veranschaulicht, welches ein Targetgerät eingebettet haben kann;
2 Softwarekomponenten, die gemäß einer Ausgestaltung benutzt werden können, schematisch veranschaulicht;
3 eine Anordnung gemäß einer weiteren Ausgestaltung veranschaulicht, welche in der Host-Software eine Intra-Modem-Verbindungs-Socketschnittstelle („intramodem link socket interface") enthält;
4 Schnittstellen-Protokollsequenzen veranschaulicht, die in den Ausgestaltungen benutzt werden können;
5 ein Flussdiagramm ist, das die Intra-Modem-Verbindungs-Socket-Softwareinteraktion in der Ausgestaltung der 3 veranschaulicht; und
6 ein Zustandsdiagramm ist, das einen Überblick über die Host-Socket-Zustandsinteraktionen gibt, welche in den Ausgestaltungen auftreten können.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Die veranschaulichenden Ausgestaltungen der vorliegenden Erfindung werden unter Bezugnahme auf die Zeichnungen beschrieben werden, wobei ähnliche Elemente und Strukturen durch ähnliche Bezugszeichen angegeben sind.
Wenn man sich zuerst auf 1 bezieht, so ist ein Host-System gemäß einer Ausgestaltung abgebildet, welches als ein Softwareentwicklungssystem benutzt werden kann. Wie man aus der Figur sehen kann, gibt es eine zentrale Verarbeitungseinheit 100, die mit einem Speicher 110 verbunden ist. Der Speicher des Host-Systems kann ein RAM- (Speicher mit wahlfreiem Zugriff; „Random Access Memory") Gerät sein, kann aber auch EEPROM- (elektrisch löschbarer, programmierbarer Nur-Lese-Speicher; „Electrically Eraseable Programmable Read Only Memory") oder andere Flash-Speicher oder Plattenlaufwerke enthalten.
Der Speicher 110 kann ein Betriebssystem 115 und andere Software enthalten.
Ferner hat das Host-System der 1 eine Netzkommunikationsschnittstelle 140, die es dem Host erlauben kann, sich mit externen Geräten über eine Netzverbindung wie Ethernet zu verbinden.
Wie man aus 1 sehen kann, kann das Host-System ein Targetgerät 17 eingebettet haben. Das Targetgerät 170 kann ein integrierter Schaltkreischip, ein Chipmodul, das mehr als einen Chip hat, oder eine Leiterplatte oder eine beliebige andere Hardwareein heit sein, die dem Host-System Funktionalität hinzufügen kann. In der vorliegenden Ausgestaltung ist das Targetgerät 170 ein EGPRS-Modemgerät.
Die Schnittstelle des Host-Systems mit dem eingebetteten Targetgerät 170 der vorliegenden Erfindung ist in eine SRAM- (statischer Speicher mit wahlfreiem Zugriff; „Static Random Access Memory") Busschnittstelle 170 und eine Interrupt- (Unterbrechung; „interrupt") Schnittstelle 150 aufgespalten. Die SRAM-Busschnittstelle 160 ist eine Host-System-Hardwareeinheit, die es dem Host-System erlaubt, das eingebettete Targetsystem zu steuern, indem es Speicherzugriffsbefehle über einen SRAM-Schnittstellenbus an das Targetsystem 170 ausgibt. Der Speicherzugriff kann Registerlese- und/oder -schreibbefehle enthalten.
Die Interrupt-Schnittstelle 150 erlaubt es dem eingebetteten Targetgerät 170, Interrupt-Bedingungen für das Host-System zu generieren. In einer weiteren Ausgestaltung kann die Interrupt-Schnittstelle 150 bidirektional sein, wodurch sie sowohl dem Host-System als auch dem Targetsystem 170 erlaubt, Interrupts für das jeweils andere System zu generieren.
Um einem Benutzer des Host-Systems zu erlauben, den Targetgerätetreiber 120, d. h. eine Host-System-Software zum Steuern des Targetsystems 170 zu entwickeln und zu testen, selbst in Situationen, in denen die entsprechende Hardware nicht verfügbar ist, benutzt die Ausgestaltung ein virtuelles Gerät 125. In einer Ausgestaltung simuliert das virtuelle Gerät 125 die SRAM-Busschnittstelle 160 für den Gerätetreiber 120 anstelle der realen Hardware-SRAM-Busschnittstelle 160. In anderen Worten, wenn es kein Targetgerät 170 in dem Host-System eingebettet gibt, benutzt das Host-System im Softwareentwicklungsprozess nicht die SRAM-Busschnittstelle 160, sondern vielmehr das virtuelle Gerät 125. Das virtuelle Gerät 125 kann deshalb als virtuelle SRAM-Schnittstelle gedacht werden.
Wenn es das virtuelle Gerät 125 als Simulation der SRAM-Busschnittstelle 160 benutzt, generiert das Host-System eine Targetsystem-Registerkarte 130 in dem Host-Speicher 110. Wenn das virtuelle Gerät 125 aktiv ist, werden alle Speicherzugriffe durch den Ge rätetreiber 120 an die SRAM-Busschnittstelle 160 umgeleitet an die Target-Registerkarte 130, die die Targetsystemregister darstellt.
Wie man ferner aus 1 sehen kann, benutzt die Ausgestaltung eine Kommunikations- und Register-Handhabungssoftware („register handling software") 135. Diese Software 135 kann die in 2 gezeigten Einheiten 220 und 230 umfassen und hat den Zweck, die simulierten Targetregister 130 mit Daten aus der Richtung des simulierten Targetsystems 240 zu speisen.
Wenn man auf 2 Bezug nimmt, so ist die Target-Registerkarte 130 in dem Host-System gezeigt, das sowohl mit dem virtuellen Gerät 125 als auch dem virtuellen Register-Handhabungsmodul 220 verbunden werden soll. Das virtuelle Gerät 125 greift auf die Target-Registerkarte 130 zu, so dass es dem SRAM-Gerätetreiber 120 den Eindruck vermittelt, es wirke über die Hardware-SRAM-Busschnittstelle 160 auf ein eingebettetes Targetgerät 170 ein. Die Daten in der Target-Registerkarte 130 kommen zumindest teilweise von dem virtuellen Register-Handhabungsmodul 220.
Die Kommunikations- und Register-Handhabungssoftware 135, 220, 230 kann ferner sicherstellen, dass das Host-System mit notwendigen, geeigneten oder möglichen Interrupt-Nachrichten oder -Sequenzen so beliefert wird, als ob Interupts von einem eingebetteten Targetsystem 170 generiert würden. In der Ausgestaltung kann die Kommunikations- und Register-Handhabungssoftware ferner für die entsprechende Interupt-Statusregisteraktualisierung („interrupt status register update") Sorge tragen, wenn solche Interrupts generiert oder geliefert werden.
Wie man aus 2 sehen kann, kann die Kommunikations- und Register-Handhabungssoftware eine TCP/IP-Socketverbindung mit einem simulierten Targetsystem benutzen, welches zu diesem Zweck eine TCP/IP-Register-Kommunikationsprotokolleinheit haben kann. Das simulierte Targetsystem kann vollständig in Software ausgestaltet sein, kann aber auch Hardwarekomponenten benutzen. Ferner kann das simulierte Targetsystem auf einem externen Computergerät 240 lokalisiert sein, das mit der Netzkommunikationsschnittstelle 140 des Host-Systems verbunden sein kann.
Im Falle, dass die virtuelle SRAM-Schnittstelle einer Ausgestaltung nicht den Datendurchsatz erreicht, welchen das Hardwaretarget auf Basis der SRAM-Busschnittstelle 140 zu erreichen in der Lage wäre, kann die Virtualisierungssoftware der Ausgestaltungen dazu eingerichtet sein, einem Register- und Interrupt-Handshake-Protokoll (Einigungsprotokoll; „handshake protocol") zu genügen, um den Host-Registerzugriff auf virtuelle Targetregister zu synchronisieren. Das Register- und Interrupt-Handshake-Protokoll kann auf einer Systemwarteschlange („system wait queue") basieren.
Wie aus den oben beschriebenen Ausgestaltungen ersichtlich, besteht aus Sicht der Host-Treibersoftware bezüglich der logischen Targetsystem-Handhabung kein Unterschied, ob der Target-Registerzugriff auf die virtuelle oder die Hardware-basierte SRAM-Geräteschnittstelle erfolgt. Somit werden Host-Treiberentwicklung und -testen, welche Hardwareressourcen wie die SRAM-Busschnittstelle für einen Registerzugriff auf die eingebettete Targetlösung auf Simulationsbasis erfordern, ermöglicht, selbst wenn ein Targetsystem 170 noch nicht verfügbar ist.
Es wird angemerkt, dass in den Ausgestaltungen die Virtualisierung in einer Weise implementiert sein kann, dass sie Software selektiv erlaubt, diese Funktionalität zu aktivieren oder deaktivieren. Das heißt, die Ausgestaltungen können Software erlauben, das virtuelle Gerät 125 zu aktivieren, so dass alle Speicherzugriffe auf die SRAM-Busschnittstelle 160 auf das virtuelle Gerät 125 umgeleitet werden. In einer Ausgestaltung wird die Virtualisierung immer aktiviert, wenn das Host-System detektiert, dass kein Targetsystem 170 verfügbar ist. Ferner kann das Host-System ein virtuelles Gerät 125 automatisch deaktivieren, sobald ein eingebettetes Targetgerät 170 verfügbar wird. In einer weiteren Ausgestaltung ist die Aktivierung oder Deaktivierung des virtuellen Geräts 125 unabhängig von dem Vorhandensein eines Targetsystems 170, so dass es dann möglich ist, ein virtuelles Gerät 125 zu benutzen, selbst wenn ein Hardware-Targetgerät 170 angeschlossen („plugged in") ist. Dies kann sinnvoll sein, um das richtige Funktionieren des simulierten Targetsystems 240 zu überprüfen.
Wenn man nun zu 3 übergeht, so ist eine weitere Ausgestaltung gezeigt. In der Software ist eine OS- (Betriebssystem; „Operating System") Hülle 300 bereitgestellt, die einen Kernel-Schnittstellenken (Kern-Schnittstellenkern; „kernel interface core") 350 und eine Anzahl von Softwaremodulen haben kann, welche den Kernel-Schnittstellenkern 350 dazu befähigen, mit einem Betriebssystem 115 zu kommunizieren. Diese Softwaremodule können Module 310 bis 325 enthalten, um Threads, Timer, Warteschlangen und Speicherressourcen zu behandeln.
Ferner kann es Softwaremodule gegen, um mit der Target-Hardwareschnittstelle 370 zu kommunizieren. Diese Module können ein SRAM-Modul 355, eine CF- („Compact Flash") Schnittstelle, ein SDIO- (sichere digitale Ein- und Ausgabe; „Secure Digital Input Output") Modul 335 und ein SPI- (serieller Datenbus; „Serial Peripheral Interface") Modul 340 enthalten.
Ferner zeigt 3, dass in dieser Ausgestaltung die OS-Hülle („OS wrapper") 300 ein virtuelles Gerät 125, einen Target-Registerspeicher 130 und eine virtuelle Targetschnittstelle 220 eingebaut haben kann, die im Wesentlichen wie die entsprechenden bezüglich der 2 diskutierten Module arbeiten können. Das heißt, die virtuelle Targetschnittstelle 220 stellt eine virtuelle Intra-Modem-Verbindungsschnittstelle bereit, die wie oben beschrieben zur Kommunikations- und Registerhandhabung benutzt werden kann.
In der vorliegenden Ausgestaltung wird ein Intra-Modem-Verbindungs-Socketschnittstellenprotokoll benutzt, um den Intra-Modem-Verbindungsregistersatz („intra-modem link register set") 130 auf transparente Weise über eine TCP/IP-Verbindung auf das Modem abzubilden. Es kann eine entsprechende Protokollimplementierung benutzt werden, um die Implementierungsanstrengungen zu reduzieren, indem das Intra-Modem-Verbindungs-Socketschnittstellenprotokoll auf eine UART- (universeller asynchroner Sender/Empfänger; „Universal Asynchronous Receiver Transmitter") Schnittstelle basiert wird.
In der Ausgestaltung werden Daten über die Verbindungen übertragen, indem ein einfaches Handshake-Protokoll benutzt wird. Eine Übertragung kann aus den folgenden Feldern zusammengesetzt werden: einem Übertragungsindexfeld, einem Nutzlastlängenfeld, einem Übertragungstypenfeld und einem Nutzlastfeld. Der Handshake kann dann unter Benutzung des Übertragungstypenfeldes implementiert werden. Dieses Feld kann Informtation darüber enthalten, ob die Übertragung ein Befehl oder eine Antwort auf einen Befehl war. Befehle können indiziert werden, indem das Übertragungsindexfeld benutzt wird, so dass eine Antwort mit einem Befehl abgestimmt (abgeglichen, angepasst; „matched") werden kann.
In einer Ausgestaltung kann die Targetsystem-Virtualisierungssoftware, welche alle der oben diskutierten Einheiten 125, 130, 220 bis 250 enthalten kann, einen Intra-Modem-Verbindungsschnittstellentunnel zwischen dem Anwendungsprozessor, d. h. den Anwendungsverarbeitungsmodulen in dem Host-System, und dem Targetsystem 170, welches ein EGPRS-Modemgerät sein kann, implementieren. Dieser Schnittstellentunnel kann einen CONFIG- (Konfigunerungs-) Befehl benutzen, der einen von mehreren Betriebsmodi bezüglich der Module 355, 330, 335 und 340 angeben kann und der auch ein Interrupt-Aktivierungsbit (Interrupt-Befähigungsbit; „interrupt enable bit") enthalten kann. Der CONFIG-Befehl kann auch als eine Initialnachricht vom Target an den Host benutzt werden, um anzugeben, dass der Host läuft. Der CONFIG-Befehl kann die aktuelle Hardwareschnittstellenkonfiguration in dem Nutzlastfeld liefern.
Ferner kann es READ- (Lese-) und WRITE- (Schreib-) Befehle geben, um das Lesen oder Schreiben eines Registers anzufordern.
Des Weiteren kann es DEVICE_RESET- (Geräterücksetz-) und CONNECTION_RESET(Verbindungsrücksetz-) Befehle geben, welche nicht Daten enthalten, sondern die Geltendmachung (Zusicherung; „assertion") des Geräterücksetzpins verursachen und die Verbindung zurücksetzen können.
Ein INTERRUPT:_POLL- (Interrupt-Abfrage-) Befehl kann verursachen, dass eine Interrupt-Nachricht gesandt wird. Dieser Befehl enthält keine Daten.
Des Weiteren kann es optionale RAW_DATA- (Rohdaten-) und RAW_DATA_POLL- (Rohdatenabfrage-) Befehle geben, um Rohdaten weiterzuleiten oder das Lesen von Daten anzufordern.
Jeder der obigen Befehle kann durch eine MESSAGE_ACK- (Nachricht-ACK-, Nachrichtenbestätigungs-) Antwort mit einem transportierten Nachrichtenidentifikator bestätigt werden. 4 ist ein Ablaufdiagramm, das die oben beschriebenen Socketverbindungsprotokollabläufe gemäß einer Ausgestaltung veranschaulicht.
Wenn man nun zu 5 übergeht, so ist die Softwarestruktur des Intra-Modem-Verbindungssockets gezeigt, um die Softwareinteraktion zwischen der OS-Hülle und der Host-Socketanwendung zu veranschaulichen.
In 5 ist der TCP/IP-Socketübertragungs-/-empfangsprozess gemäß einer Ausgestaltung gezeigt, wonach er Schritte 510 des Sendens eines Target-Registerübertragungsbehälters („target register transmission container"), wenn durch einen Nutzer angefordert und wenn der Socketstatus inaktiv (stilliegend, ungenutzt, nicht in Betrieb; „idle") ist, Schritt 515 des Empfangens eines Target-Registerübertragungscontainers, wenn der TCP/IP-Socket Daten verfügbar hat, und Schritt 520 des Sendens eines Target-Registerübertragungscontainers, wenn durch den Treiber angefordert und wenn der Socketstatus inaktiv ist, hat. Der Benutzerschnittstellenprozess 500 ist in erster Linie dazu gedacht, Testnachrichten zu initiieren, die von Hand für Entwicklungszwecke zusammengesetzt wurden. Schritt 510 kann einen Puffer 505 mit einem Benutzerschnittstellenprozess 500 teilen, welcher eine Target-Registerkonfiguration, Lese- und Schreibbefehle enthalten kann. In Schritt von 515 kann eingetreten werden, wenn von dem Target über den TCP/IP-Socket eine Intra-Modem-Verbindungsregisterantwort empfangen wird. Schritte 510 und 520 können zu Intra-Modem-Verbindungsregisterzugriffen auf das Target über den TCP/IP-Socket führen.
Wenn von dem Target in Schritt 515 eine Antwort empfangen wird, gelangen die Daten in Schritt 525 in das OS-I/O-Steuermodul 305 der OS-Hülle 300, in Schritt 530 in die virtuelle Targetschnittstelle 220 und in Block 535 in den Target-Registerspeicher 130. Auf Basis dieser Daten greift das virtuelle Gerät 125 in Schritt 540 auf das Register 130 zu und übermittelt in Schritt 545 die Daten an eine Hardwareabstraktionsschicht des Kernel-Schnittstellenkerns 350. Der Prozess wird dann mit Schritt 550 des Durchführens des Targetregisterzugriffs, des Interrupts und der Ressourcenhandhabungs-Testsoftware fortgesetzt.
In der anderen Richtung kann die Testsoftware einen Registerzugriff in Schritt 550 initiieren, und die Schritte 545, 540, 535, 530 und 525 werden dann in umgekehrter Reihenfolge durchgeführt. Schritt 520 sendet schließlich den Target-Registerübertragungscontainer, um einen Intra-Modem-Verbindungsregisterzugriff auf das Target über den TCP/IP-Socket durchzuführen.
Wenn man nun zu 6 übergeht, so ist ein Zustandsdiagramm gemäß einer Ausgestaltung abgebildet. Der INITIAL STATE (Anfangszustand) 600 ist der Zustand, in den nach dem Systemstart eingetreten wird. Zustand 610 ist der Zustand, in den nach einer Benutzereingabe eingetreten wird. Wie in 6 gezeigt, kann der Übergang vom Zustand 600 zum Zustand 610 auch auftreten, wenn ein CONFIG-Befehl auftritt.
In Schritt 620 wird immer dann eingetreten, wenn das System inaktiv ist. Das heißt, das System ist in diesem Zustand, wenn alle ausstehenden Antwort- und Bestätigungsnachrichten empfangen wurden.
Der DRIVER COMMAND STATE (Treibersteuerzustand) 630 ist der Zustand, in den eingetreten wird, wenn der Treiber eine Befehlsnachricht an den Targetsocket, z. B. eine Lese-, Schreib- oder Konfigurationsnachricht gesandt hat.
Der INTERRUPT POLL STATE (Interrupt-Abfragezustand) 650 ist der Zustand, in den eingetreten wird, wenn eine Interrupt-Abfragenachricht gesandt werden soll. Schließlich wird in den READ INTERRUPT FLAG STATE (Lese-Interrupt-Flag-Zustand) 640 eingetreten, nachdem eine Interrupt-Anhängig-Nachricht zum Lesen des Interrupt-Flags empfangen wurde.
Während die Erfindung mit Bezug auf die physikalischen Ausgestaltungen beschrieben wurde, die in Übereinstimmung mit ihr konstruiert worden sind, wird es Fachleuten klar sein, dass vielfache Modifikationen, Variationen und Verbesserungen der vorliegenden Erfindung im Lichte der obigen Lehren und innerhalb des Umfangs der beigefügten Ansprüche gemacht werden können, ohne vom Gedanken und beabsichtigten Umfang der Erfindung abzuweichen.
Während beispielsweise Ausgestaltungen im Kontext einer SRAM-Schnittstelle beschrieben wurden, können sich andere Ausgestaltungen auf andere speicherabgebildete („memory mapped") Schnittstellen wie CF-, SD- (sichere digitale; „Secure Digital") Karte, MMC- (MuItiMedia-) Karte, SPI oder Ähnliches beziehen.
Darüber hinaus wurden Bereiche, in denen davon ausgegangen wird, dass sich Fachleute auskennen, hierin nicht beschrieben, um die hierin beschriebene Erfindung nicht unnötig zu verschleiern. Dementsprechend ist zu verstehen, dass die Erfindung nicht durch die spezifischen veranschaulichenden Ausgestaltungen beschränkt werden soll, sondern nur durch den Umfang der beigefügten Ansprüche.

Claims

Computerlesbares Speichermedium, welches Befehle speichert, die, wenn sie durch einen Prozessor eines Host-Systems ausgeführt werden, den Prozessor dazu veranlassen, eine Speicherschnittstelle (160) zu simulieren, mit der ein Targetsystem (170) verbunden werden kann, indem ein Softwaremodul eine virtuelle Speicherschnittstelleneinrichtung (125) implementiert, wobei die virtuelle Speicherschnittstelleneinrichtung eine Targetsystem-Registerkarte (130) in einem Speicher (110) des Host-Systems generiert und wobei die Targetsystem-Registerkarte durch das Host-System adressierbar ist, wenn kein Targetsystem mit der Speicherschnittstelle verbunden ist.
Computerlesbares Speichermedium nach Anspruch 1, weiterhin umfassend Befehle zum Aktivieren oder Deaktivieren der virtuellen Speicherschnittstelleneinrichtung, wobei durch das Host-System generierte Speicherzugriffsanforderungen an die Speicherschnittstelle gerichtet werden, wenn die virtuelle Speicherschnittstelleneinrichtung deaktiviert ist, und an die Targetsystem-Registerkarte umgeleitet werden, wenn die virtuelle Speicherschnittstelleneinrichtung aktiviert ist.
Computerlesbares Speichermedium nach Anspruch 2, wobei die virtuelle Speicherschnittstelleneinrichtung aktiviert ist, wenn kein Targetsystem mit der Speicherschnittstelle verbunden ist.
Computerlesbares Speichermedium nach Anspruch 1, weiterhin umfassend Befehle zum Implementieren eines Registerhandhabungs-Softwaremoduls (220, 230), das zum Schreiben von Daten an die Targetsystem-Registerkarte konfiguriert ist, wobei die Daten dazu geeignet sind, von dem Host-System als Registerdaten eines Targetsystems akzeptiert zu werden.
Computerlesbares Speichermedium nach Anspruch 4, wobei die virtuelle Speicherschnittstelleneinrichtung und das Registerhandhabungs-Softwaremodul dazu konfiguriert sind, einem Handshake-Protokoll zu genügen, um mit Speicherzugriffen durch das Host-System auf die Targetsystem-Registerkarte synchronisiert zu werden.
Computerlesbares Speichermedium nach Anspruch 4, wobei das Registerhandhabungs-Softwaremodul eine TCP/IP-Socketschnittstelle (230) umfasst, die benutzt wird, um die Daten bereitzustellen.
Computerlesbares Speichermedium nach Anspruch 4, weiterhin umfassend Befehle zum Implementieren eines Kommunikations-Softwaremoduls (230, 250), das dazu konfiguriert ist, Interrupts zu generieren und sie an das Host-System zu liefern, wobei die Interrupts dazu geeignet sind, durch das Host-System als Interrupts eines Targetsystems akzeptiert zu werden.
Computerlesbares Speichermedium nach Anspruch 1, weiterhin umfassend Befehle zum Implementieren eines Kommunikations-Softwaremoduls (230, 250), das dazu konfiguriert ist, Interrupts zu generieren und sie an das Host-System zu liefem, wobei die Interrupts dazu geeignet sind, durch das Host-System als Interrupts eines Targetsystems akzeptiert zu werden.
Computerlesbares Speichermedium nach Anspruch 8, wobei das Kommunikations-Softwaremodul ferner dazu konfiguriert ist, eine Aktualisierung eines geeigneten Registers unter mehreren Interrupt-Statusregistern des Host-Systems zu verursachen, wenn es einen Interrupt an das Host-System liefert oder geliefert hat.
Computerlesbares Speichermedium nach Anspruch 8, wobei das Kommunikations-Softwaremodul eine TCP/IP-Socketschnittstelle (230, 250) umfasst, die dazu benutzt wird, die Interrupts zu generieren.
Computerlesbares Speichermedium nach Anspruch 8, wobei die virtuelle Speicherschnittstelleneinrichtung und das Kommunikations-Softwaremodul dazu konfiguriert sind, einem Handshake-Protokoll zu genügen, um die Interrupts mit dem Host-System zu synchronisieren.
Computerlesbares Speichermedium nach Anspruch 1, wobei das Targetsystem ein EGPRS- (verbesserter allgemeiner paketorientierter Funkdienst; "Enhanced General Packet Radio Service") Modem ist.
Verfahren zum Testen eines Targetgerätetreibers (120), der auf einem Host-System läuft, an das ein Targetsystem (170) gekoppelt werden kann, wobei der Targetgerätetreiber dazu konfiguriert ist, Speicherlese- und/oder -schreibbefehle an eine Speicherschnittstelleneinheit (160) des Host-Systems auszugeben, um auf das Targetsystem zuzugreifen, wenn es an das Host-System gekoppelt ist, wobei das Verfahren folgende Schritte umfasst, wenn das Targetsystem nicht an das Host-System gekoppelt ist: Ausführen mindestens eines ersten Teils (125, 130, 220, 230) einer Targetsystem-Virtualisierungssoftware (125, 130, 220 bis 250) auf dem Host-System, die das Verhalten des Targetsystems simuliert; und Veranlassen des Targetgerätetreibers, Speicherlese- und/oder -schreibbefehle statt an die Speicherschnittstelleneinheit an die Targetsystem-Virtualisierungssoftware auszugeben.
Verfahren nach Anspruch 13, wobei die Targetsystem-Virtualisierungssoftware in der Lage ist, durch Software aktiviert oder deaktiviert zu werden, wobei die Aktivierung der Targetsystem-Virtualisierungssoftware dazu führt, dass Speicherlese- und/oder -schreibbefehle, die durch den Targetgerätetreiber ausgegeben wurden, statt an die Speicherschnittstelleneinheit an die Targetsystem-Virtualisierungssoftware umgeleitet werden.
Verfahren nach Anspruch 14, wobei die Targetsystem-Virtualisierungssoftware aktiviert wird, wenn kein Targetsystem an das Host-System gekoppelt ist.
Verfahren nach Anspruch 13, wobei die Targetsystem-Virtualisierungssoftware einen Satz von Targetsystemregistern (130) in einem Speicher (110) des Host-Systems generiert, wobei die an die Targetsystem-Virtualisierungssoftware ausge gebenen Speicherlese- und/oder -schreibbefehle umgeleitet werden, um auf den Satz von Targetsystemregistern zuzugreifen.
Verfahren nach Anspruch 16, weiterhin umfassend: Ausführen von Registerhandhabungssoftware (220, 230) auf dem Host-System, die dazu konfiguriert ist, Daten in dem Satz von Targetsystemregistern zu speichern, wobei die Daten dazu geeignet sind, durch das Host-System als Registerdaten eines Targetsystems akzeptiert zu werden.
Verfahren nach Anspruch 17, wobei die Targetsystem-Virtualisierungssoftware und die Registerhandhabungssoftware dazu konfiguriert sind, einem Handshake-Protokoll zu genügen, um mit Speicherzugriffen auf den Satz von Targetsystemregistern durch das Host-System synchronisiert zu werden.
Verfahren nach Anspruch 17, wobei die Registerhandhabungssoftware eine TCP/IP-Socketschnittstelle (230) umfasst, die dazu benutzt wird, die Daten bereitzustellen.
Verfahren nach Anspruch 17, weiterhin umfassend: Ausführen von Kommunikationssoftware (230) auf dem Host-System, die dazu konfiguriert ist, Interrupts zu generieren und sie an das Host-System zu liefern, wobei die Interrupts dazu geeignet sind, durch das Host-System als Interrupts eines Targetsystems akzeptiert zu werden.
Verfahren nach Anspruch 13, weiterhin umfassend: Ausführen von Kommunikationssoftware (230) auf dem Host-System, die dazu konfiguriert ist, Interrupts zu generieren und sie an das Host-System zu liefern, wobei die Interrupts dazu geeignet sind, durch das Host-System als Interrupts eines Targetsystems akzeptiert zu werden.
Verfahren nach Anspruch 21, weiterhin umfassend: Verursachen einer Aktualisierung eines Interrupt-Statusregisters des Host-Systems durch die Kommunikationssoftware, wenn sie einen Interrupt an das Host-System liefert oder geliefert hat.
Verfahren nach Anspruch 21, wobei die Kommunikationssoftware eine TCP/IP-Socketschnittstelle (230) umfasst, die dazu benutzt wird, die Interrupts zu generieren.
Verfahren nach Anspruch 21, wobei die Targetsystem-Virtualisierungssoftware und die Kommunikationssoftware dazu konfiguriert sind, einem Handshake-Protokoll zu genügen, um die Interrupts mit dem Host-System zu synchronisieren.
Verfahren nach Anspruch 13, weiterhin umfassend: Ausführen eines zweiten Teils (240, 250) der Targetsystem-Virtualisierungssoftware zum Simulieren des Verhaltens des Targetsystems auf einem bezüglich des Host-Systems externen Computersystem, wobei das externe Computersystem und das Host-System gekoppelt sind, um miteinander unter Benutzung einer TCP/IP-Verbindung zu kommunizieren.
Verfahren nach Anspruch 13, wobei die Speicherschnittstelleneinheit eine SRAM- (statischer Speicher mit wahlfreiem Zugriff; „Static Random Access Memory") Busschnittstelleneinheit ist.
Verfahren nach Anspruch 13, wobei das Targetsystem ein EGPRS- (verbesserter allgemeiner paketorientierter Funkdienst; „Enhanced General Packet Radio Service") Modem ist.
Softwareentwicklungssystem, das in der Lage ist, einem Benutzer zu erlauben, einen EGPRS- (verbesserter allgemeiner paketorentierter Funkdienst; „Enhanced General Packet Radio Service") Modemgerätetreiber (120) zu entwickeln und zu testen, selbst wenn ein EGPRS-Modemgerät (170) nicht verfügbar ist, wobei das Softwareentwicklungssystem in der Lage ist, ein virtuelles EGPRS-Modem (125) zu implementieren und Speicherzugriffe, die durch den EGPRS-Modemgerätetreiber vorgenommen werden, an das virtuelle EGPRS-Modem umzuleiten, wobei das virtuelle EGPRS-Modem in der Lage ist, auf die Speicherzugriffe in einer Weise zu antworten, die es dem EGPRS-Modemgerätetreiber erlaubt, zu arbeiten, als ob die Speicherzugriffe durch ein existierendes EGPRS-Modemgerät vorgenommen würden.
Softwareentwicklungssystem nach Anspruch 28, das dazu angepasst ist, das virtuelle EGPRS-Modem zu aktivieren oder zu deaktivieren, wobei die Aktivierung des virtuellen EGPRS-Modems zu Speicherzugriffen an das virtuelle EGPRS-Modem führt, die durch den EGPRS-Modemgerätetreiber vorgenommen wurden.
Softwareentwicklungssystem nach Anspruch 29, das dazu angepasst ist, das virtuelle EGPRS-Modem zu aktivieren, wenn dem Host-System ein EGPRS-Modemgerät nicht verfügbar ist.
Softwareentwicklungssystem nach Anspruch 28, wobei das virtuelle EGPRS-Modem einen Satz von Targetsystemregistern (130) in einem Speicher des Softwareentwicklungssystems generiert, wobei die durch den EGPRS-Modemgerätetreiber an das virtuelle EGPRS-Modem vorgenommenen Speicherzugriffe umgeleitet werden, um auf den Satz von Targetsystemspeichern zuzugreifen.
Softwareentwicklungssystem nach Anspruch 31, das Registerhandhabungssoftware (220-250) ausführt, die dazu konfigurert ist, Daten in dem Satz von Targetsystemregistern zu speichern, wobei die Daten dazu geeignet sind, als Registerdaten eines EGPRS-Modemgeräts akzeptiert zu werden.
Softwareentwicklungssystem nach Anspruch 32, wobei das virtuelle EGPRS-Modem und die Registerhandhabungssoftware dazu konfiguriert sind, einem Handshake-Protokoll zugenügen, um mit Speicherzugriffen auf den Satz von Targetsystemregistern synchronisiert zu werden.
Softwareentwicklungssystem nach Anspruch 32, wobei die Registerhandhabungssoftware eine TCP/IP-Socketschnittstelle (230, 250) umfasst, die dazu benutzt wird, die Daten bereitzustellen.
Softwareentwicklungssystem nach Anspruch 32, das Kommunikationssoftware (230, 250) ausführt, die dazu konfigurier ist, Interrupts zu generieren, wobei die Interrupts dazu geeignet sind, als Interrupts eines EGPRS-Modemgeräts akzeptiert zu werden.
Softwareentwicklungssystem nach Anspruch 28, das Kommunikationssoftware (230, 250) ausführt, die dazu konfiguriert ist, Interrupts zu generieren, wobei die Interrupts dazu geeignet sind, als Interrupts eines EGPRS-Modemgeräts akzeptiert zu werden.
Softwareentwicklungssystem nach Anspruch 36, wobei die Kommunikationssoftware in der Lage ist, eine Aktualisierung eines Interrupt-Statusregisters zu verursachen, wenn sie einen Interrupt generiert oder generiert hat.
Softwareentwicklungssystem nach Anspruch 36, wobei Kommunikationssoftware eine TCP/IP-Socketschnittstelle (230, 250) umfasst, die dazu benutzt wird, die Interrupts zu generieren.
Softwareentwicklungssystem nach Anspruch 38, wobei das virtuelle EGPRS-Modem und die Kommunikationssoftware dazu konfiguriert sind, einem Handshake-Protokoll zu genügen, um die Interrupts zu synchronisieren.
Softwareentwicklungssystem nach Anspruch 28, das in der Lage ist, mit externer EGPRS-Modem-Virtualisierungssoftware (240) zu kommunizieren, die dazu geeignet ist, das Verhalten des EGPRS-Modemgeräts zu simulieren, wobei die externe EGPRS-Modem-Virtualisierungssoftware und das Softwareentwicklungssystem gekoppelt sind, um miteinander unter Benutzung einer TCP/IP-Verbindung zu kommunizieren.
Softwareentwicklungssystem nach Anspruch 28, wobei die Speicherzugriffe, die durch den EGPRS-Modemgerätetreiber vorgenommen werden, Zugriffe auf einen SRAM- (statischer Speicher mit wahlfreiem Zugriff; „Static Random Access Memory") Bus sind.