DE69838540T2

DE69838540T2 - Mobilkommunikationssystem

Info

Publication number: DE69838540T2
Application number: DE69838540T
Authority: DE
Inventors: Matthew A. Plano Woolsey; Marion C. Dallas Lineberry; Jihong Kim (nmi), Buk-gu
Original assignee: Texas Instruments Inc
Current assignee: Texas Instruments Inc
Priority date: 1997-12-22
Filing date: 1998-12-16
Publication date: 2008-07-10
Anticipated expiration: 2018-12-17
Also published as: US6029000A; EP0924612A3; EP0924612B1; EP0924612A2; DE69838540D1

Description

QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
Diese Anmeldung bezieht sich auf lfd. US-Nr. 08/995.606 mit dem Titel "Mobile Information Services Platform" (Aktenzeichen des Anwalts Nr. 26421) an McMahon u. a., lfd. US-Nr. 08/995.597 mit dem Titel "Method and Apparatus for Providing Downloadable Functionality to an Embedded Coprocessor" (Aktenzeichen des Anwalts Nr. 26440) an Brewer und lfd. US-Nr. 08/995.603 mit dem Titel "Method and Apparatus for Extending Security Model to Native Code" (Aktenzeichen des Anwalts Nr. 26439) an Brewer, von denen Kopien mit dieser Anmeldung und zum Datum der Einreichung dieser Anmeldung beigebracht worden sind, damit sie in der Akte des europäischen Patentamts für diese Anmeldung untergebracht werden, wobei sie für die öffentliche Einsichtnahme zu und ab dem Datum der Veröffentlichung dieser Anmeldung verfügbar gemacht werden.
HINTERGRUND DER ERFINDUNG
1. TECHNISCHES GEBIET
Diese Erfindung bezieht sich im Allgemeinen auf mobile elektronische Vorrichtungen und insbesondere, aber nicht ausschließlich auf eine Hardware- und Software-Plattform für mobile elektronische Vorrichtungen.
2. BESCHREIBUNG DES STANDES DER TECHNIK
Tragbare Hand-Vorrichtungen gewinnen mit zunehmender Leistung und folglich der Funktionalität der Vorrichtungen an Popularität, Persönliche digitale Assistenten (PDAs) befinden sich gegenwärtig in weitverbreiteter Verwendung, wobei erwartet wird, dass Smartphones, die einige der Fähigkeiten eines Zellulartelephons und eines PDA kombinieren, einen signifikanten Einfluss auf die Kommunikation in der nahen Zukunft haben werden.
Einige Vorrichtungen enthalten gegenwärtig einen oder mehrere DSPs (digitale Signalprozessoren) oder andere Coprozessoren, um bestimmte diskrete Merkmale, wie z. B. Spracherkennung, bereitzustellen, und einen Mehrzweckprozessor für die anderen Datenverarbeitungsfunktionen. Der Code für den DSP und der Code für den Mehrzweckprozessor ist im Allgemeinen in ROMs oder anderen nichtflüchtigen Speichern gespeichert, die nicht leicht modifiziert werden. Wie Verbesserungen und neue Merkmale verfügbar werden, ist es folglich oft nicht möglich, die Fähigkeiten der Vorrichtung hochzurüsten. Insbesondere ist es nicht möglich, den Nutzen der DSPs oder des anderen Coprozessors zu maximieren, die in der Vorrichtung vorhanden sein können.
Deshalb gibt es einen Bedarf an einer Datenverarbeitungsarchitektur, die hochgerüstet werden kann und die die Verwendung mehrerer Prozessoren und Coprozessoren optimiert.
EP 0455 345 beschreibt einen programmierbaren Controller, der einen Hauptprozessor enthält, der mit E/A- und Peripherievorrichtungen für ihre sequentielle Steuerung in einer programmierten Weise verbunden ist. Dem Hauptprozessor ist ein Systemspeicher zugeordnet, der sowohl ein Betriebssystem für den Hauptprozessor speichert als auch einen bei seinem Betrieb verwendeten Arbeitsbereich bereitstellt. Ein Quellbefehlsspeicher ist vorgesehen, um ein Quellprogramm für die Steuerung der E/A- und Peripherievorrichtungen zu speichern. Das Quellprogramm wird durch den Hauptprozessor in ein Programm kompiliert, das die entsprechenden verringerten Befehle enthält, und in einem Befehlsspeicher des Coprozessors gespeichert. Es ist ein Coprozessor enthalten, um die Befehle vom Befehlsspeicher des Coprozessors wiederzugewinnen, um die Befehle in einer Pipeline-Betriebsart und parallel mit der Ausführung des Hauptprozessors auszuführen. Es ist ein Datenspeicher für die Befehlsausführung des Coprozessors vorgesehen. Der Hauptprozessor und die Coprozessoren sind mittels eines Peripherie-Controllers betriebsfähig verbunden, der Adressen- und Datenbusse besitzt, die entsprechend dem Hauptprozessor und dem Coprozessor zugeordnet sind. Der Peripherie-Controller ist so konfiguriert, dass er die Daten direkt zwischen dem Systemspeicher und dem Datenspeicher durch einen Speicherdirektzugriff [DMA] vor dem Beginn der Parallelverarbeitung überträgt und dass er bei Abschluss der DMA-Datenübertragung die Busse mit dem Hauptprozessor von jenen mit dem Coprozessor trennt, um die Parallelverarbeitung im Hauptprozessor und im Coprozessor zu ermöglichen.
Das Dokument "Practical Multiprocessor and Realtime Programming in the Fifth Programming Environment" von F. Mayer-Lindenberg, veröffentlicht in Microprocessing and Microprogramming, Bd. 24 (1988) Aug., Nrn. 1–5, Amsterdam, NL, beschreibt eine Studie bezüglich moderner eingebetteter Mikroprozessor-Systeme, die oft mehrerer Prozessoren mit verschiedenen Hardware-Typen enthalten. In dem Dokument wird ein PC-gestütztes interaktives Programmierwerkzeug erörtert, das die Echtzeit-Programmierung für derartige Multiprozessorsysteme unterstützt. Der fünfte Kompilierer enthält mehrere Code-Generatoren, unter denen die Auswahl innerhalb eines einzigen Programms ausgeführt werden kann. Die verschiedenen Prozessoren innerhalb des Zielsystems können mittels wechselseitiger Funktionsaufrufe kommunizieren. Die interaktive Kreuzkompilierung erfolgt mittels wechselseitiger Funktionsaufrufe. Die innerhalb des fünften Systems verwendete interaktive Kreuzkompilierung beseitigt den Bedarf an Hardware-Emulatoren und macht es selbst für Einzelprozessorziele zu einer funktionalen Alternative zum universellen Entwicklungssystem. Als ein Beispiel wird die Anwendung der Fünften auf die Programmierung eines kleinen Transputer-Netzes, das mit einem Paar von Standard-Mikroprozessoren verbunden ist, betrachtet.
KURZZUSAMMENFASSUNG DER ERFINDUNG
Die Aspekte der Erfindung sind in den beigefügten Ansprüchen definiert.
In den Ausführungsformen gemäß der vorliegenden Erfindung umfasst eine mobile elektronische Vorrichtung einen oder mehrere Coprozessoren und ein Host-Prozessorsystem. Das Host-Prozessorsystem führt einen Kreuzkompilierer, um einen Quellcode zu empfangen und den Quellcode in eine Maschinencode-Routine für einen aus dem einen oder den mehreren Coprozessoren ausgewählten Ziel-Coprozessor zu kompilieren, und einen Kreuzlinker, um Adressen in der Maschinencode-Routine aufzulösen und die Maschinencode-Routine zu dem Ziel-Coprozessor herunterzuladen, aus. Es ist eine Schaltungsanordnung für die Kommunikation zwischen dem Host-Prozessorsystem und den Coprozessoren vorgesehen.
Die Ausführungsformen der vorliegenden Erfindung schaffen signifikante Vorteile gegenüber dem Stand der Technik. Portabler Code kann kompiliert und in einem Zielprozessor ausgeführt werden, wobei dadurch die Geschwindigkeit vergrößert wird, mit der der Code ausgeführt wird. Die Entscheidungen, den Code in einem Coprozessor oder in einem von mehreren Coprozessoren auszuführen, kann dynamisch getroffen werden. Im Gegensatz zur statischen Funktio nalität gegenwärtiger DSPs, die in mobilen Vorrichtungen verwendet werden, ist die Funktionalität des (der) DSP(s), der (die) in der vorliegenden Erfindung verwendet wird (werden), dynamisch, weil die durch den DSP ausgeführten Tasks durch den Host-Prozessor während des Betriebs einer Vorrichtung, die die Plattform enthält, geändert werden können.
KURZBESCHREIBUNG DER MEHREREN ANSICHTEN DER ZEICHNUNG
Eine ausführlichere Beschreibung der Ausführungsformen der Erfindung folgt nun lediglich beispielhaft und unter Bezugnahme auf die beigefügte Zeichnung, worin:
1 einen Blockschaltplan einer Plattform-Architektur veranschaulicht, die für die allgemeine drahtlose Datenverarbeitung besonders geeignet ist;
2 einen funktionalen Blockschaltplan der Plattform nach 1 veranschaulicht;
3 einen funktionalen Blockschaltplan der Funktionen der dynamischen Kreuzkompilierung und des dynamischen Kreuzlinkens veranschaulicht;
4 eine Ausführungsform des Maschinencodes für die Ausführung in einem Prozessor veranschaulicht, der in einer JAVA-Bohnen-Hülle zum Herunterladen zu einer Vorrichtung eingekapselt ist;
5 die Operation des Übertragens des eingekapselten Maschinencodes von einer JAVA-Bohne, die sich in einem entfernten Server befindet, zu einem Prozessor in einer Vorrichtung veranschaulicht; und
6 ein Ablaufplan veranschaulicht, der die der Operation nach 5 zugeordneten Sicherheitsmerkmale beschreibt.
AUSFÜHRLICHERE BESCHREIBUNG DER ERFINDUNG
Die Ausführungsformen der vorliegenden Erfindung können in Bezug auf die 1–6 der Zeichnung verstanden werden, wobei gleiche Bezugszeichen für gleiche Elemente in den verschiedenen Zeichnungen verwendet werden.
1 veranschaulicht eine bevorzugte Ausführungsform einer allgemeinen drahtlosen Datenplattform-Architektur, die z. B. bei der Implementierung eines Smartphones oder eines PDA verwendet werden könnte. Die drahtlose Datenplattform 10 enthält einen Mehrzweckprozessor (Host-Prozessor) 12, der an die Busstruktur 14 gekoppelt ist, die den Datenbus 14a, den Adressenbus 14b und den Steuerbus 14c enthält. Ein oder mehrere DSPs (oder andere Coprozessoren) 16, die den Kernprozessor 16a und die Peripherieschnittstelle 16b enthalten, sind an den Bus 14 und an den Speicher- und Verkehrs-Controller 18 gekoppelt, der einen DSP-Cache-Speicher 18a, einen CPU-Cache 18b und eine MMU (Speichermanagementeinheit) 18c enthält. Eine Hardware-Beschleunigerschaltung 20 (um eine portable Sprache, wie z. B. JAVA, zu beschleunigen) und ein Video- und LCD-Controller 22 sind außerdem an den Speicher- und Verkehrs-Controller 18 gekoppelt. Der Ausgang des Video- und LCD-Controllers ist an eine LCD- oder Videoanzeige 24 gekoppelt.
Der Speicher- u. Verkehrs-Controller 18 ist an den Bus 14 und den Hauptspeicher 26, der als ein SDRAM (synchroner dynamischer Schreib-Lese-Speicher) gezeigt ist, gekoppelt. Der Bus 14 ist außerdem mit dem E/A-Controller 28, der Schnittstelle 30 und dem RAM/ROM 32 verbunden. Mehrere Vorrichtungen könnten an die drahtlose Datenplattform 10 gekoppelt sein, wie z. B. eine Chip-Karte 34, eine Tastatur 36, eine Maus 38 oder ein oder mehrere serielle Anschlüsse 40, wie z. B. ein USB-Anschluss (Anschluss eines universellen seriellen Busses) oder ein serieller RS232-Anschluss. Die Schnittstelle 30 kann an eine Flash-Speicher-Karte 42 und/oder eine DRAM-Karte 44 gekoppelt sein. Die Peripherieschnittstelle 16b kann den DSP 16 an einen DAC (Digital-Analog-Umsetzer) 46, eine Netzschnittstelle 48 oder andere Vorrichtungen koppeln.
Die drahtlose Datenplattform 10 nach 1 verwendet sowohl einen Mehrzweckprozessor 12 als auch einen DSP 16. Ungleich aktueller Vorrichtungen, in denen der DSP 16 für spezifische feste Funktionen zweckgebunden ist, kann der DSP 16 nach 1 für irgendeine Anzahl von Funktionen verwendet werden. Dies erlaubt dem Anwender, den vollen Nutzen des DSP 16 zu erlangen.
Ein Hauptbereich, in dem der DSP 16 verwendet werden kann, steht im Zusammenhang mit der Mensch-Maschine-Schnittstelle (MMI). Wichtige Funktionen, wie die Spracherkennung, die Bild- und Video-Komprimierung und -Dekomprimierung, die Datenverschlüsselung, die Text-Sprache-Umsetzung usw. können unter Verwendung des DSP 16 viel effizienter ausgeführt werden.
Die vorliegende Architektur erlaubt, das neue Funktionen und Verbesserungen leicht zur drahtlosen Datenplattform 10 hinzugefügt werden.
Es sollte angegeben werden, dass die drahtlose Datenplattform 10 ein allgemeiner Blockschaltplan ist und dass viele Modifikationen ausgeführt werden könnten. 1 veranschaulicht z. B. separate DSP- und Prozessor-Caches 18a und 18b. Wie einem Fachmann auf dem Gebiet bekannt sein würde, könnte außerdem ein vereinigter Cache verwendet werden. Außerdem ist die Hardware-Beschleunigungsschaltung 20 ein optionales Element. Derartige Vorrichtungen beschleunigen die Ausführung von Sprachen, wie z. B. JAVA; die Schaltung ist jedoch für den Betrieb der Vorrichtung nicht notwendig. Obwohl die veranschaulichte Ausführungsform einen einzigen DSP zeigt, könnten ferner mehrere DSPs (oder andere Coprozessoren) an die Busse gekoppelt sein.
2 veranschaulicht eine funktionale Software-Architektur für die drahtlose Datenplattform 10. Dieser Blockschaltplan setzt die Verwendung von JAVA voraus; es sollte angegeben werden, dass andere Sprachen als JAVA ebenso verwendet werden könnten. Funktional ist die Software in zwei Gruppen unterteilt, die Host-Prozessor-Software und die DSP-Software. Die Host-Software enthält ein oder mehrere Applets 40. Die DSP-API-Klasse 42 ist ein JAVA-API-Paket für Java-Anwendungen oder -Applets, um auf die Funktionalität der DSP-API 50 und der Host-DSP-Schnittstellenschicht 52 zuzugreifen. Eine virtuelle JAVA-Maschine (VM) 44 interpretiert die Applets. Die Java-Maschinenschnittstelle 46 ist das Verfahren, mit dem die JAVA-VM den für den Host-Prozessor oder die Plattform spezifischen Code ausführt. Die Maschinen-Tasks 48 sind nicht in JAVA geschriebene Programme, die durch den Host-Prozessor 12 ausgeführt werden können, ohne die JAVA-Maschinenschnittstelle zu verwenden. Die DSP-API 50, die im Folgenden ausführlicher beschrieben ist, ist eine API (Anwendungsprogrammschnittstelle), die im Host 12 für den Aufruf verwendet wird, um von den Fähigkeiten des DSP 16 Gebrauch zu machen. Die Host-DSP-Schnittstellenschicht 52 schafft eine API für den Host 12 und den DSP 16, damit sie miteinander, mit anderen Tasks oder anderer Hardware unter Verwendung von Kanälen über das Host-DSP-Kommunikationsprotokoll kommunizieren. Der DSP-Vorrichtungstreiber 54 ist der host-gestützte Vorrichtungstreiber für das Host-RTOS 56 (Host-Echtzeit-Betriebssystem), um mit dem DSP 16 zu kommunizieren. Das Host-RTOS 56 ist ein Betriebssystem, wie z. B. NUCLEUS PLUS von Accelera ted Technology Incorporated. Alternative Nichtechtzeit-Betriebssysteme, wie z. B. Windows CE von der Microsoft Corporation, könnten verwendet werden. Die DSP-Bibliothek 58 enthält Programme, die für die Ausführung im DSP 16 gespeichert sind.
Auf der DSP-Seite können ein oder mehrere Tasks 60 im Speicher für die Ausführung durch den DSP 16 gespeichert sein. Wie im Folgenden beschrieben ist, können die Tasks auf Wunsch in den und aus dem Speicher bewegt werden, so dass die Funktionalität des DSP anstatt statisch dynamisch ist. Die Host-DSP-Schnittstellenschicht 62 auf der DSP-Seite führt die gleiche Funktion wie die Host-DSP-Schnittstellenschicht 52 auf der Host-Seite aus, sie erlaubt nämlich dem Host 12 und dem DSP 16, zu kommunizieren. Das DSP-RTOS 64 ist das Betriebssystem für den DSP-Prozessor. Der Host-Vorrichtungstreiber 66 ist ein DSP-gestützter Vorrichtungstreiber für das DSP-RTOS 64, um mit dem Host 12 zu kommunizieren. Die Host-DSP-Schnittstelle 70 gekoppelt den DSP 16 und den Host 12.
In Betrieb verwendet die in 2 gezeigte Software-Architektur den DSP 16 anstatt als eine Vorrichtung mit festen Funktionen wie im Stand der Technik als eine Vorrichtung mit variablen Funktionen. Demzufolge können die DSP-Funktionen zur mobilen Vorrichtung, die die Architektur nach 2 enthält, heruntergeladen werden, um den DSP 16 zu erlauben, verschiedene Signalverarbeitungsfunktionen für den Host 12 auszuführen.
Die DSP-API
Die DSP-API schafft eine vorrichtungsunabhängige Schnittstelle vom Host 12 zum DSP 16. Die Funktionen versehen den Host 12 mit der Fähigkeit, Tasks im DSP 16 zu laden und zu planen und diese Tasks zu steuern und mit diesen Tasks zu kommunizieren. Die API-Funktionen enthalten Aufrufe, um: die verfügbaren Betriebsmittel des DSP zu bestimmen, Tasks des Host 12 und des DSP zu erzeugen und zu steuern, Datenkanäle zwischen den Tasks des Host 12 und des DSP zu erzeugen und zu steuern und mit den Tasks zu kommunizieren. Diese Funktionen sind im Folgenden beschrieben. Jede Funktion schickt ein BOOLEsches Ergebnis zurück, das SUCCESS für eine erfolgreiche Operation oder FAI-LURE ist. Falls das Ergebnis FAILURE lautet, sollte der errcode überprüft werden, um zu bestimmen, welcher Fehler aufgetreten ist.
DSP_Get_MIPS

BOOL DSP_Get_MIPS(T_DeviceID DevID, U32 *mips, U16 *errcode);

Diese Funktion schickt die aktuellen MIPS zurück, die im DSP verfügbar sind. Dies besteht aus der MIPS-Fähigkeit des DSP 16 minus einen Basis-MIPS-Wert (der MIPS-Wert ohne zusätzliche dynamische Tasks, d. h. der Kernel plus der API-Code plus die Treiber) minus der Summe der MIPS-Nennwerte für alle geladenen dynamische Tasks. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_Get_Memory_Available

BOOL DSP_Get_Memory_Available(T_DeviceID DevID, T_Size *progmem, T_Size *datamem, U16 *errcode);

Diese Funktion fragt den durch den DevID spezifizierten DSP 16 nach den Mengen des verfügbaren Speichers sowohl für den Programmspeicher als auch den Datenspeicher ab. Die resultierenden Werte werden in den progmem- und datamem-Parametern zurückgeschickt. Die Größen sind in T_DSP_Words spezifiziert. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_Alloc_Mem

BOOL DSP_Alloc_Mem(T_DeviceID DevID, U16 mempage, T_Size size, T_DSP Word **memptr, U16 *errcode);

Diese Funktion ordnet einen Block des Speichers in einem DSP 16 zu. Der DevID spezifiziert die Vorrichtung, in der der Speicher zuzuordnen ist. Der mempage ist 0 für Programmraum und 1 für Datenraum. Der size-Parameter spezifi ziert die Speicherblockgröße in T_DSP_Words. Der zurückgeschickte memptr ist ein Zeiger auf den Speicherblock im DSP 16 oder NULL bei einem Ausfall.
Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_INVALID_MEMPAGE
DSP_NOT_ENOUGH_MEMORY
DSP_Free_Mem

BOOL DSP_Free_Mem(T_DeviceID DevID, U16 mempage, T_DSP_Word *memptr, U16 *errcode);

Diese Funktion gibt einen Block des Speichers in einem DSP frei, der mit der DSP_Alloc_Mem-Funktionen zugeordnet worden ist. Der DevID spezifiziert, in welcher Vorrichtung der Speicher liegt. Der mempage ist 0 für Programmraum und 1 für Datenraum. Der memptr-Parameter ist der Zeiger auf den Speicherblock. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_INVALID_MEMPAGE
DSP_MEMBLOCK_NOT_FOUND
DSP_Get_Code_Info

BOOL DSP_Get_Code_Info(char *Name, T_CodeHdr *codehdr, U16 *errcode);

Diese Funktion greift auf die DSP-Bibliothekstabelle zu und schickt den Codekopf für den durch den Name-Parameter spezifizierten DSP-Funktionscode zurück. Beim Rücksprung enthält der Ort, auf den durch den codehdr-Parameter gezeigt wird, die Codekopfinformationen. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_NAMED_FUNC_NOT_FOUND
DSP_Link_Code

BOOL DSP_Link_Code(T_DeviceID DevID, T_CodeHdr *codehdr, T_TaskCreate *tcs, U16 *errcode);

Diese Funktion linkt den DSP-Funktionscode, so dass er bei einer spezifizierten Adresse im durch den DevID spezifizierten DSP abläuft. Der codehdr-Parameter zeigt auf den Codekopf für die Funktion. Der dynamische Kreuzlinker linkt den Code anhand der Informationen im Codekopf und im Code (in der COFF-Datei). Der dynamische Kreuzlinker ordnet den Speicher zu, wie er notwendig ist, wobei er den Code linkt und in den DSP 16 lädt. Der tcs-Parameter ist ein Zeiger auf die Task-Erzeugungsstruktur, die in der DSP_Create_Task-Funktion notwendig ist. Der DSP_Link_Code füllt die Codeeinsprungpunkt-, priority- und quantum-Felder der vorbereiteten Struktur zum Erzeugen eines Tasks aus. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_NOT_ENOUGH_PROG_MEMORY
DSP_NOT_ENOUGH_DATA_MEMORY
DSP_COULD_NOT_LOAD_CODE
DSP_Put_BLOB

BOOL DSP_Put_BLOB(T_DeviceID DevID, T_HostPtr srcaddr, T_DSP_Ptr destaddr, U16 mempage, T_Size size, U16 *errcode);

Diese Funktion kopiert ein spezifiziertes binäres großes Objekt (BLOB) in den DSP 16. Der DevID spezifiziert, in welchen DSP 16 das Objekt zu kopieren ist. Der scraddr-Parameter ist ein Zeiger auf das Objekt im Host-Speicher. Der destaddr ist ein Zeiger auf den Ort, an den das Objekt im DSP 16 zu kopieren ist. Der mempage ist 0 für Programmraum und 1 für Datenraum. Der size-Parameter spezifiziert die Größe des Objekts in T_DSP_Words. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_INVALID_MEMPAGE
DSP_Create_Task

BOOL DSP_Create_Task(T_DeviceID DevID, T_TaskCreate *tcs, T_TaskID *TaskID, U16 *errcode);

DSP_Create_Task fordert den DSP 16 auf, einen Task unter Voraussetzung der Task-Parameter und der Codeorte im Programmraum des DSP zu erzeugen.

Die Task-Erzeugungsstruktur ist in der Tabelle 1 gezeigt: Tabelle 1. Die Task-Erzeugungsstruktur.

Datentyp	Feldname	Beschreibung
T_DSP_Name	Name	Der benutzerdefinierte Name für den Task.
U32	MIPS	Die durch den Task benutzten MIPS.
T_ChanID	ChanIn	Die für die Task-Eingabe verwendete Kanal-ID.
T_ChanID	ChanOut	Die für die Task-Ausgabe verwendete Kanal-ID.
T_StrmID	StrmIn	Die für die Task-Eingabe verwendete Strom-ID.
T_StrmID	StrmOut	Die für die Task-Ausgabe verwendete Strom-ID.
U16	Priority	Die Priorität des Tasks.
U32	Quantum	Die Zeitscheibe des Tasks in System-Ticks.
T_Size	StackReq	Die Menge des erforderlichen Stapels.
T_DSP_Ptr	MsgHandler	Der Zeiger auf den Code, um die Nachrichten für den Task abzuwickeln.
T_HOST_Ptr	CallBack	Der Zeiger auf den Host-Code, um die Nachrichten von dem Task abzuwickeln.
T_DSP_Ptr	Create	Der Zeiger auf den auszuführenden Code, wenn der Task erzeugt wird.
T_DSP_Ptr	Start	Der Zeiger auf den auszuführenden Code, wenn der Task gestartet wird.
T_DSP_Ptr	Suspend	Der Zeiger auf den auszuführenden Code, wenn der Task angehalten wird.
T_DSP_Ptr	Resume	Der Zeiger auf den auszuführenden Code, wenn der Task wiederaufgenommen wird.
T_DSP_Ptr	Stop	Der Zeiger auf den auszuführenden Code, wenn der Task gestoppt wird.

Sobald der Task erzeugt ist, wird der Erzeuge-den-Einsprungpunkt aufgerufen, der dem Task die Gelegenheit gibt, irgendwelche notwendige vorbereitende Initialisierung auszuführen. Die Create-, Suspend-, Resume- und Stop-Einsprungpunkte können NULL sein. Der resultierende TaskID enthält sowohl die Vorrichtungs-ID (DevID) als auch die Task-ID des DSP. Falls der TaskID NULL ist, ist das Erzeugen misslungen. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_INVALID_PRIORITY
DSP_CHANNEL_NOT_FOUND
DSP_ALLOCATION_ERROR
DSP_Start_Task

BOOL DSP_Start_Task(T_TaskID TaskID, U16 *errcode);

Diese Funktion startet einen durch den TaskID spezifizierten DSP-Task. Die Ausführung beginnt am Start-Einsprungpunkt des Tasks. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_TASK_NOT_FOUND
DSP_Suspend_Task

BOOL DSP_Suspend_Task(T_TaskID TaskID, U16 *errcode);

Diese Funktion hält einen durch den TaskID spezifizierten DSP-Task an. Bevor der Task angehalten wird, wird der Suspend-Einsprungpunkt des Tasks aufgerufen, um dem Task eine Chance zu geben, irgendwelche notwendige Systemverwaltung auszuführen. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_TASK_NOT_FOUND
DSP_Resume_Task

BOOL DSP_Resume_Task(T_TaskID TaskID, U16 *errcode);

Diese Funktion nimmt einen DSP-Task wieder auf, der durch DSP_Suspend_Task angehalten worden ist. Bevor der Task wiederaufgenom men wird, wird der Resume-Einsprungpunkt des Tasks aufgerufen, um dem Task eine Chance zu geben, irgendwelche notwendige Systemverwaltung auszuführen. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_TASK_NOT_FOUND
DSP_TASK_NOT_SUSPENDED
DSP_Delete_Task

BOOL DSP_Delete_Task(T_TaskID TaskID, U16 *errcode);

Diese Funktion löscht einen durch den TaskID spezifizierten DSP-Task. Vor dem Löschen wird der Stop-Einsprungpunkt des Tasks aufgerufen, um dem Task eine Chance zu geben, irgendwelche notwendige Reinigung auszuführen. Dies sollte das Freigeben irgendwelchen Speichers, der dem Task zugeordnet worden ist, und das Zurückgeben der durch den Task erworbenen Betriebsmittel enthalten. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_TASK_NOT_FOUND
DSP_Change_Task_Priority

BOOL DSP_Change_Task_Priority(T_TaskID TaskID, U16 newpriority, U16 *oldpriority, U16 *errcode);

Diese Funktion ändert die Priorität eines durch den TaskID spezifizierten Tasks. Die Priorität wird in den newpriority geändert. Die möglichen Werte des newpriority hängen vom RTOS ab. Beim Rücksprung wird der oldpriority-Para meter auf die vorhergehende Priorität des Tasks gesetzt. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_TASK_NOT_FOUND
DSP_INVALID_PRIORITY
DSP_Get_Task_Status

BOOL DSP_Get_Task_Status(T_TaskID TaskID, U16 *status, U16 *priority, T_ChanID *Input, T_ChanID *Output, U16 *errcode);

Diese Funktion schickt den Status für einen durch den TaskID spezifizierten Task zurück. Der status ist einer der folgenden Werte:
DSP_TASK_RUNNING
DSP_TASK_SUSPENDED
DSP_TASK_WAITFOR_SEM
DSP_TASK_WAITFOR_QUEUE
DPS_TASK_WAITFOR_MSG
Der priority-Parameter enthält die Priorität des Tasks, während die Input- und Output-Parameter die Eingangs- bzw. Ausgangs-Kanal-IDs des Tasks enthalten. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_TASK_NOT_FOUND
DSP_Get_ID_From_Name

BOOL DSP_Get_ID_From_Name(T_DeviceID DevID, T_DSP_Name Name, T_DSP_ID *ID, U16 *errcode);

Diese Funktion schickt den ID für ein benanntes Objekt im DSP 16 zurück. Das benannte Objekt kann ein Kanal, ein Task, ein Speicherblock oder irgendein anderes unterstütztes benanntes DSP-Objekt sein. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_NAME_NOT_FOUND
DSP_Dbg_Read_Mem

BOOL DSP_Dbg_Read_Mem(DEVICE_ID DevID, U8 mempage, DSP_PTR addr, U32 count, DSP_WORD *buf, U16 *errcode);

Diese Funktion fordert einen Block des Speichers an. Der mempage spezifiziert Programmspeicher (0) oder Datenspeicher (1). Der addr-Parameter spezifiziert die Speicherstartadresse, während der count angibt, wie viele T_DSP_Words zu lesen sind. Der buf-Parameter ist ein Zeiger auf einen vom Aufrufer bereitgestellten Puffer, in den der Speicher kopiert werden sollte. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_INVALID_MEMPAGE
DSP_Dbg_Write_Mem

BOOL DSP_Dbg_Write_Mem(T_DeviceID DevID, U16 mempage, T-DSP-Ptr addr, T-Count count, T_DSP_Word *buf, U16 *errcode);

Diese Funktion schreibt einen Block des Speichers. Der mempage spezifiziert Programmspeicher (0) oder Datenspeicher (1). Der addr-Parameter spezifiziert die Speicherstartadresse, während der count spezifiziert, wie viele T_DSP_Words zu schreiben sind. Der buf-Parameter ist ein Zeiger auf den Puffer, der den zu schreibenden Speicher enthält. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_INVALID_MEMPAGE
DSP_Dbg_Read_Reg

BOOL DSP_Dbg_Read_Reg(T_DeviceID DevID, U16 RegID, T_DSP_Word *regvalue, U16 *errcode);

Diese Funktion liest ein DSP-Register und schickt den Wert in regvalue zurück. Der RegID-Parameter spezifiziert, welches Register zurückzuschicken ist. Wenn der RegID –1 ist, dann werden alle Registerwerte zurückgeschickt. Der regvalue-Parameter, der ein Zeiger auf einen vom Aufrufer bereitgestellten Puffer ist, sollte auf ausreichend Speicher zeigen, um alle Werte zu halten. Die Register-IDs sind DSP-spezifisch und hängen von der speziellen Implementierung ab. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_INVALID_REGISTER
DSP_Dbg_Write_Reg

BOOL DSP_Dbg_Write_Reg(T_DeviceID DevID, U16 RegID, T_DSP_Word regvalue, U16 *errcode);

Diese Funktion schreibt ein DSP Register. Der RegID-Parameter spezifiziert, welches Register zu modifizieren ist. Der regvalue enthält den zu schreibenden neuen Wert. Die Register-IDs sind DSP-spezifisch und hängen von der speziellen Implementierung ab. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_INVALID_REGISTER
DSP_Dbg_Set_Break

BOOL DSP_Dbg_Set_Break(T_DeviceID DevID, DSP_Ptr addr, U16 *errcode);

Diese Funktion setzt einen Unterbrechungspunkt bei der gegebenen Codeadresse (addr). Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_Dgb_Clr_Break

BOOL DSP_Dbg_Clr_Break(T_DeviceID DevID, T_DSP_Ptr addr, U16 *errcode);

Diese Funktion löscht einen Unterbrechungspunkt, der vorher durch DSP_Dbg_Set_Break gesetzt worden ist, bei der gegebenen Codeadresse (addr). Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING DSP_BP_DID_NOT_EXIST
DER DSP-VORRICHTUNGSTREIBER
Der DSP-Vorrichtungstreiber 54 wickelt die Kommunikationen vom Host 12 zum DSP 16 ab. Die Treiberfunktionen nehmen die Kommunikationsanforderungen, wie sie im Host-DSP-Kommunikationsprotokoll spezifiziert sind, und wickeln die Übertragung der Informationen über die verfügbare Hardware-Schnittstelle ab. Der Vorrichtungstreiber ist RTOS-abhängig und von der Kommunikations-Hardware abhängig.
DIE DSP-BIBLIOTHEK

Die DSP-Bibliothek 58 enthält die Blöcke des Codes, die für die Ausführung in den DSP 16 heruntergeladen werden können. Jeder Block des Codes ist vorher nicht gelingt oder als eine Bibliothek verschieblich gelingt, so dass der dynamische Kreuzlinker alle Adressenbezüge auflösen kann. Jeder Codeblock enthält außerdem Informationen für die Anforderungen des Blocks an DSP-MIPS (Millionen von Befehlen pro Sekunde), die Priorität, die Zeitscheiben-Menge und den Speicher. Das Format für den Codeblockkopf ist in der Tabelle 2 gezeigt. Die Größen des Programmspeichers und des Datenspeichers sind Approximationen, um dem Host 12 eine schnelle Überprüfung zu geben, ob der DSP die Speicheranforderungen des Tasks unterstützen kann. Wenn es erscheint, dass es ausreichend Raum gibt, kann der dynamische Kreuzlinker dann versuchen, den Code zu linken und zu laden. Es sollte angegeben werden, dass der dynamische Kreuzlinker, zurückzuführen auf die Seitenausrichtung und die Zusammenhangsanforderungen, immer noch scheitern kann. In der bevorzugten Ausführungsform liegt der Code in einem COFF-Dateiformat der Version 2 vor. Tabelle 2. Der Codeblockkopf.

Datentyp	Feldname	Beschreibung
U16	Processor	Der Zielprozessortyp.
T_DSP_Name	Name	Der Name des Tasks.
U32	MIPS	Der schlechteste Fall der durch den Task benötigten MIPS.
T_Size	ProgSize	Die notwendige Gesamtgröße des Programmspeichers.
T_Size	DataSize	Die notwendige Gesamtgröße des Datenspeichers.
T_Size	InFrameSize	Die Größe eines Rahmens im Eingangskanal des Tasks.
T_Size	OutFrameSize	Die Größe eines Rahmens im Ausgangskanal des Tasks.
T_Size	InStrmSize	Die Größe des Eingangsstrom-FIFO des Tasks.
T_Size	OutStrmSize	Die Größe des Ausgangsstrom-FIFO des Tasks.
U16	Priority	Die Priorität des Tasks.
U32	Quantum	Die Menge der Zeitscheiben (Anzahl der System-Ticks) des Tasks.
T_Size	StackReq	Der erforderliche Stapel.
T_Size	CoffSize	Die Gesamtgröße der COFF-Datei.
T_DSP_Ptr	MsgHandler	Der Versatz zu einem Einsprungpunkt in die Nachrichten-Behandlungseinrichtung für den Task.
T_DSP_Ptr	Create	Der Versatz zu einem Create-Einsprungpunkt, der aufgerufen wird, wenn der Task erzeugt wird.
T_DSP_Ptr	Start	Der Versatz zum Start des Codes des Tasks.
T_DSP_Ptr	Suspend	Der Versatz zu einem Suspend-Einsprungpunkt, der aufgerufen wird, bevor der Task angehalten wird.
T_DSP_Ptr	Resume	Der Versatz zu einem Resume-Einsprungpunkt, der aufgerufen wird, bevor der Task wiederaufgenommen wird.
T_DSP_Ptr	Stop	Der Versatz zu einem Stop-Einsprungpunkt, der aufgerufen wird, bevor der Task gelöscht wird.
T_Host_Ptr	CoffPtr	Der Zeiger auf den Ort der COFF-Daten in der DSP-Bibliothek.

DIE UMSETZUNG DES PORTABLEN CODES IN DEN GELINKTEN ZIEL-CODE
Eine Prozedur zum Umsetzen von portablem (prozessorunabhängigem) Code, wie z. B. JAVA-Code, in gelinkten Zielcode ist in 3 gezeigt. Die Prozedur verwendet zwei Funktionen, einen dynamischen Kreuzkompilierer 80 und einen dynamischen Kreuzlinker 82. Jede Funktion ist im Host-Prozessor 12 implementiert. Der dynamische Kreuzlinker ist in der bevorzugten Ausführungsform Teil der DSP-API. Der Kreuzkompilierer kann außerdem Teil der DSP-API sein.
Der dynamische Kreuzkompilierer 80 setzt den portablen Code in nicht gelinkten ausführbaren Zielprozessorcode um. Der dynamische Kreuzlinker 82 setzt den nicht gelinkten ausführbaren Zielprozessorcode in gelinkten ausführbaren Zielprozessorcode um. Um dies zu tun, muss er vor dem Laden in den DSP 16 die Adressen innerhalb eines Blocks des Codes auflösen. Der dynamische Kreuzlinker 82 linkt die Codesegmente und die Datensegmente der Funktion, ordnet den Speicher im DSP 16 zu und lädt den Code und die konstanten Daten in den DSP 16. Die Funktionen werden als "Kreuz"-Kompilieren und "Kreuz"-Linken bezeichnet, weil die Funktionen (das Kompilieren und das Linken) in einem vom Zielprozessor, der den Code ausführt, (d. h. dem DSP 16) verschiedenen Prozessor (d. h. dem Host-Prozessor 12) auftreten.
Der dynamische Kreuzkompilierer 80 akzeptiert vorher nicht gelinkten Code, der auf Anforderung durch einen Benutzer oder einen Benutzeragenten (wie z. B. einen Browser) geladen wird. Der Code wird verarbeitet, um entweder (1) "etikettierte" Abschnitte des Codes zu identifizieren oder (2) nicht etikettierte Codesegmente auf die Eignung der Ausführung im DSP 16 zu analysieren. Ein etikettierter Abschnitt des Quellcodes könnte eine Quelle, auf die durch einen DSP gezielt werden kann, durch vorgegebene Markierungen, wie z. B. "<start DSP code>" und <end DSP code>", die in den Quellcode eingebettet sind, beschreiben. Falls ein etikettierter Abschnitt entweder direkt oder durch Analyse identifiziert wird, wird eine Entscheidung, ob er zu kreuzkompilieren ist oder nicht, anhand des aktuellen Verarbeitungszustands des DSP 16 getroffen. Falls eine Entscheidung, zu kompilieren, getroffen wird, wird der Abschnitt des Codes durch Kompilierungs-Software, die nicht gelinkten ausführbaren Zielprozessorcode ausgibt, unter Verwendung wohlbekannter Kompilierungsverfahren verarbeitet. Eine Entscheidung, nicht zu kompilieren, könnte getroffen werden, falls z. B. der DSP, zurückzuführen auf andere Tasks, die durch den DSP 16 ausgeführt werden, ungenügend verfügbare Verarbeitungskapazität (die im Allgemeinen als verfügbare MIPS – Millionen von Befehlen pro Sekunde – dargelegt wird) oder ungenügend verfügbaren Speicher besitzt. Der kompilierte Code kann für die unmittelbare Verwendung im DSP 16 zum dynamischen Kreuzlinker 82 weitergeleitet werden oder könnte in der DSP-Bibliothek 58 gesichert werden.
Der dynamische Kreuzlinker 82 akzeptiert vorher nicht gelinkten Code, der entweder (1) im Zusammenhang mit dem Host-Prozessor 12 statisch gespeichert ist oder (2) über eine Netzverbindung (einschließlich über globale Netze, wie z. B. das Internet) dynamisch zum Host-Prozessor 12 heruntergeladen wird oder (3) durch den dynamischen Kreuzkompilierer 80 dynamisch erzeugt wird. Der dynamische Kreuzlinker 82 linkt den Eingangscode für eine Speicherstartadresse des DSP 16, die zur Laufzeit bestimmt wird. Die Speicherstartadresse kann aus einer Speicherabbildung oder einer Speichertabelle bestimmt werden, die entweder im Host-Prozessor 12 oder im DSP 16 gespeichert ist und durch den Host-Prozessor 12 oder den DSP 16 gemanagt wird. Der dynamische Kreuzlinker 82 setzt die Speicherstellen im Code, auf die Bezug genommen wird, in tatsächliche Speicherstellen im DSP um. Diese Speicherstellen könnten z. B. Verzweigungsadressen im Code oder Bezugnahmen auf Orte der Daten im Code enthalten.
In der bevorzugten Ausführungsform liegt der portable Code in einem COFF (gemeinsamen Objektdateiformat) vor, das alle Informationen über den Code enthält, einschließlich dessen, ob er gelinkt oder nicht gelinkt ist. Falls er nicht gelinkt ist, definieren Symboltabellen die Adressen, die geändert werden müssen, um den Code zu linken.
Der oben beschriebene Umsetzungsprozess besitzt gegenüber dem Stand der Technik mehrere signifikante Vorteile. Zuerst erlaubt der dynamische Kreuzkompilierer 80, dass Laufzeitentscheidungen darüber getroffen werden, wo der heruntergeladene portable Code auszuführen ist. In einem System mit mehreren Zielprozessoren (wie z. B. zwei DSPs 16) könnte der dynamische Kreuzkompilierer 80 z. B. den portablen Code anhand der verfügbaren Betriebsmittel oder Fähigkeiten für irgendeinen der Zielprozessoren kompilieren. Der dynamische Kreuzlinker 82 sorgt für das Linken des Codes, damit er in einem Zielprozessor abläuft, der keinen verschieblichen Code unterstützt. Weil der Code zur Laufzeit gelinkt wird, müssen die Speicherstellen im DSP 16 (oder dem anderen Zielprozessor) nicht reserviert sein, was einen optimalen Wirkungsgrad der Verwendung aller Computer-Betriebsmittel in der Vorrichtung erlaubt. Weil das Kompilieren mit der Kenntnis der Architektur der Plattform 10 ausgeführt wird, kann das Kompilieren die spezifischen Merkmale des Prozessors und der Plattform, wie z. B. intelligente Cache-Architekturen in einem oder beiden Prozessoren, ausnutzen.
Folglich kann der DSP 16 verschiedene Funktionen besitzen, die dynamisch geändert werden, um seine Verarbeitungsfähigkeiten vollständig zu verwenden. Der Benutzer kann z. B. wünschen, eine Benutzerschnittstelle zu laden, die die Spracherkennung enthält. Zu diesem Zeitpunkt könnte der Host-Prozessor die Software herunterladen und die Spracherkennungs-Software für die Ausführung im DSP 16 dynamisch kreuzkompilieren und kreuzlinken. Alternativ könnte vorher kompilierte Software in der DSP-Bibliothek 58 anhand des aktuellen Status des DSP 16 für die Ausführung dynamisch kreuzgelinkt werden.
DER HOST-VORRICHTUNGSTREIBER
Der Host-Vorrichtungstreiber wickelt die Kommunikationen vom DSP 16 zum Host 12 ab. Die Treiberfunktionen nehmen die Kommunikationsanforderungen, wie sie im Host-DSP-Kommunikationsprotokoll spezifiziert sind, und wickeln die Übertragung der Informationen über die verfügbare Hardware-Schnittstelle ab. Der Vorrichtungstreiber ist RTOS-abhängig und von der Kommunikations-Hardware abhängig.
DAS HOST-DSP-KOMMUNIKATIONSPROTOKOLL (DIE HOST-DSP-SCHNITTSTELLENSCHICHT)
Das Host-DSP-Kommunikationsprotokoll steuert die Übermittlungen von Befehlen und Daten zwischen dem Host 12 und dem DSP 16. Die Übermittlungen umfassen mehrere Wege: Nachrichten, Datenkanäle und Ströme. Die Nachrichten werden verwendet, um Initialisierungsparameter und Befehle an die Tasks zu senden. Die Datenkanäle übertragen große Mengen von Daten in der Form von Datenrahmens zwischen den Tasks und zwischen dem DSP 16 und dem Host 12. Die Ströme werden verwendet, um geströmte Daten zwischen den Tasks und zwischen dem DSP 16 und dem Host 12 weiterzuleiten.
Die Nachrichten
Jeder Task besitzt einen Einsprungpunkt in eine Nachrichten-Behandlungseinrichtung, die die Nachrichten abwickelt. Die Nachrichten sind benutzerdefiniert und enthalten Initialisierungsparameter für die Funktion des Tasks und Befehle zum Steuern des Tasks. Die Tasks senden über den Rückruf, der spezifiziert wird, wenn der Task erzeugt wird, Nachrichten zum Host 12. Der Prototyp für die Nachrichten-Behandlungseinrichtung des Tasks und der Prototyp für den Rückruf des Hosts sind hier gezeigt:

void TaskMsgHandler(T_ReplyRef replyref; T_MsgID MsgID, T_Count count, T_DSP_Word *buf);
void HostCallBack(T_ReplyRef replyref, T_MsgID MsgID, T_Count count, T_DSP Word *buf);

Der replyref-Parameter bezieht sich auf einen von der Implementierung abhängigen Bezugswert, der verwendet wird, um die Antwort zurück zum Sender zu leiten. Für jeden Send_Message-Aufruf muss der Empfänger unter Verwendung des replyref Parameters Reply_Message aufrufen. Die tatsächlichen Nachrichten können wie folgt erscheinen:

Sendenachricht: MsgPktFlag taskid replyref msgid count buf[...]

Antwortnachricht MsgPktFlag –1 replyref msgid count buf[...]
Die Mehrwort-Daten werden mit dem niedrigstwertigen Wort zuerst gesendet.
Ein TaskID von 0 in der Send_Message-Funktion zeigt eine Systemebenen-Nachricht an. Die Systemebenen-Nachrichten werden verwendet, um die DSP-API-Funktionen zu implementieren.
Das Folgende sind die Nachrichtenfunktionen:
Send_Message

BOOL Send_Message(T_TaskID TaskID, T_MsgID MsgID, T_Count count, T_DSP_Word *msgbuf, T_DSP_Word *replybuf, T_Size replybufsize, T_Count replycount, U16 *errcode);

Diese Funktion sendet eine benutzerdefinierte Nachricht an einen durch den TaskID spezifizierten Task. Der MsgID definiert die Nachricht, während der msgbuf die tatsächlichen Nachrichtendaten enthält. Die Nachrichtengröße beträgt count T_DSP_Words. Die Antwort auf die Nachricht ist im replybuf-Parameter enthalten, der auf einen Puffer der Größe replybufsize zeigt, der durch den Aufrufer bereitgestellt wird. Er sollte eine ausreichend Größe besitzen, um die Antwort auf die spezielle Nachricht abzuwickeln. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_TASK_NOT_FOUND
Reply_Message

BOOL Reply_Message(T_ReplyRef replyref, T_Count count, T_DSP_Word *buf, U16 *errcode);

Diese Funktion wird verwendet, um auf Nachrichten zu antworten. Der replyref-Parameter ist eine Bezugnahme, die verwendet wird, um die Antwort zurück zum Sender der ursprünglichen Nachricht zu leiten, wobei er implementierungsspezifisch ist. Die Antwort ist im buf-Parameter enthalten, wobei ihre Größe count T_DSP_Words beträgt. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
DSP_SUCCESS
DSP_DEVID_NOT_FOUND
DSP_DEVID_NOT_RESPONDING
DSP_BAD_REPLY_REF
Die Kanäle
Das Konzept der Kanäle wird verwendet, um rahmengestützte Daten von einem Prozessor zu einem weiteren oder zwischen den Tasks im selben Prozessor zu übertragen. Wenn ein Kanal erzeugt wird, ordnet er eine spezifizierte Anzahl und Größe von Rahmen zu, die die Daten enthalten. Anfangs enthält der Kanal eine Liste leerer Rahmen. Die Tasks, die die Daten erzeugen, fordern leere Rahmen an, in die die Daten zu setzen sind, wobei dann der Rahmen, sobald er gefüllt ist, zum Kanal zurückgeschickt wird. Die Tasks, die Daten verbrauchen, fordern volle Rahmen vom Kanal an, wobei der Rahmen, sobald er geleert ist, zum Kanal zurückgeschickt wird. Dieses Anfordern und Zurückschicken von Rahmenpuffern erlaubt, dass sich die Daten mit einem Minimum des Kopierens umherbewegen.
Jeder Task besitzt einen spezifizierten Eingangs- und Ausgangskanal. Sobald ein Kanal erzeugt ist, sollte er als der Eingang in einen Task und der Ausgang aus einem weiteren Task bezeichnet werden. Die ID eines Kanals enthält eine Vorrichtungs-ID, deshalb können die Kanäle Daten zwischen den Prozessoren weiterleiten. Der Kanaldatenfluss durch die Host-DSP-Schnittstelle kann wie folgt erscheinen:

ChanPktFlag Kanal-ID Count Daten[...]
Das Folgende sind die Kanalfunktionen:
Create_Channel

BOOL Create_Channel(T_DeviceID DevID, T_Size framesize, T_Count numframes, T_ChanID *ChannelID, U16 *errcode);

Diese Funktion erzeugt einen datenrahmengestützten Kommunikationskanal. Dies erzeugt eine Kanalsteuerstruktur, die die Steuerung der Menge von Rahmenpuffern aufrechterhält, deren Anzahl und Größe in den numframes bzw. framesize-Parametern spezifiziert sind. Wenn der Kanal erzeugt wird, ordnet er die Datenrahmen zu und fügt sie zu seiner Liste der leeren Rahmen hinzu. Der ChannelID schickt die ID des neuen Kanals zurück. Falls der DevID nicht der des aufrufenden Prozessors ist, wird eine Kanalsteuerstruktur sowohl im aufrufenden Prozessor als auch im DevID-Prozessor erzeugt, um die durch die Kommunikationsschnittstelle fließenden Daten zu steuern. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
CHAN_SUCCESS
CHAN_DEVID_NOT_FOUND
CHAN_DEVID_NOT_RESPONDING
CHAN_ALLOCATION_ERROR
Delete_Channel

BOOL Delete_Channel(T_ChanID ChannelID, U16 *errcode);

Diese Funktion löscht einen durch den ChannelID spezifizierten vorhandenen Kanal. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
CHAN_SUCCESS
CHAN_DEVID_NOT_FOUND
CHAN_DEVID_NOT_RESPONDING
CHAN_CHANNEL_NOT_FOUND
Request_Empty_Frame

BOOL Request_Empty_Frame(T_LocalChanID Chn, T_DSP_Word **bufptr, BOOL WaitFlag, U16 *errcode);

Diese Funktion fordert einen leeren Rahmen von der spezifizierten lokalen Kanal-ID an. Wenn der Chn NULL ist, dann wird der Ausgangskanal des Tasks verwendet. Beim Rücksprung enthält der bufptr-Parameter den Zeiger auf den Rahmenpuffer. Falls der WaitFlag WAHR ist und es keinen verfügbaren Rahmenpuffer gibt, wird der Aufrufer angehalten, bis ein Puffer verfügbar wird. Falls der WaitFlag FALSCH ist, springt die Funktion dennoch zurück. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
CHAN_SUCCESS
CHAN_CHANNEL_NOT_FOUND
CHAN_BUFFER_UNAVAILABLE
Return_Full_Frame

BOOL Return_Full_Frame(T_LocalChanID Chn, T_DSP_Word *bufprt, U16 *errcode);

Sobald ein Task einen Rahmenpuffer gefüllt hat, schickt er ihn unter Verwendung dieser Funktion zum Kanal zurück. Der Puffer, auf den durch bufptr gezeigt wird, wird zur spezifizierten Kanal-ID zurückgeschickt. Wenn der Chn NULL ist, dann wird der Ausgangskanal des Tasks verwendet. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
CHAN_SUCCESS
CHAN_CHANNEL_NOT_FOUND
CHAN_BUFFER_CTRL_ERROR
Request_Full_Frame

BOOL Request_Full_Frame(T_LocalChanID Chn, T_DSP_Word **bufptr, BOOL WaitFiag, U16 *errode);

Diese Funktion fordert einen vollen Rahmen der Daten von der spezifizierten lokalen Kanal-ID an. Wenn der Chn NULL ist, dann wird der Eingangskanal des Tasks verwendet. Beim Rücksprung enthält der bufptr-Parameter den Zeiger auf den Rahmenpuffer. Falls der WaitFlag WAHR ist und es keinen verfügbaren vollen Rahmenpuffer gibt, wird der Aufrufer angehalten, bis ein Puffer verfügbar wird. Falls der WaitFlag FALSCH ist, springt die Funktion dennoch zurück. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
CHAN_SUCCESS
CHAN_CHANNEL_NOT_FOUND
CHAN_BUFFER_UNAVAILABLE
Return_Empty_Frame

BOOL Return_Empty_Frame(T_LocalChanID Chn, T_DSP_Word *bufprt, U16 *errcode);

Sobald ein Task die Daten von einem Rahmenpuffer verwendet hat, sollte er den Puffer unter Verwendung dieser Funktion zum Kanal zurückschicken. Der Puffer, auf den durch den bufptr gezeigt wird, wird zur spezifizierten Kanal-ID zurückgeschickt. Wenn der Chn NULL ist, dann wird der Eingangskanal des Tasks verwendet. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
CHAN_SUCCESS
CHAN_CHANNEL_NOT_FOUND
CHAN_BUFFER_CTRL_ERROR
Set_Task_Input_Channel

BOOL Set_Task_Input_Channel(T_Task *TaskID, T_ChanID ChanID, U16 *errcode);

Diese Funktion setzt den Eingangskanal eines Tasks auf die spezifizierte Kanal-ID. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
CHAN_SUCCESS
CHAN_DEVID_NOT_FOUND
CHAN_DEVID_NOT_RESPONDING
CHAN_TASK_NOT_FOUND
CHAN_CHANNEL_NOT_FOUND
Set_Task_Output_Channel

BOOL Set_Task_Output_Channel(T_Task *TaskID, T_ChanID ChanID, U16 *errcode);

Diese Funktion setzt den Ausgangskanal eines Tasks auf die spezifizierte Kanal-ID. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
CHAN_SUCCESS
CHAN_DEVID_NOT_FOUND
CHAN_DEVID_NOT_RESPONDING
CHAN_TASK_NOT_FOUND
CHAN_CHANNEL_NOT_FOUND
Die Ströme
Die Ströme werden für Daten verwendet, die nicht in Rahmen aufgebrochen werden können, sondern die kontinuierlich in einen und aus einem Task fließen. Ein Strom umfasst einen Ringpuffer (FIFO) mit zugeordneten Kopf- und Endzeigern, um die Daten zu verfolgen, wie sie ein- und ausfließen. Jeder Task kann einen bezeichneten Eingangs- und Ausgangstrom besitzen. Der Stromdatenfluss durch die Host-DSP-Schnittstelle kann wie folgt erscheinen:

StrmPktFlag Strom-ID Count Daten[...]
Das Folgende sind die Stromfunktionen:
Create_Stream
BOOL Create_Stream(T_DeviceID DevID, T_Size FIFOsize, T_StrmID, *StreamID, U16 *errcode);
Diese Funktion erzeugt einen FIFO-gestützten Kommunikationsstrom. Dies erzeugt eine Stromsteuerstruktur, die die Steuerung eines FIFO mit der Größe FIFOsize aufrechterhält. Wenn der Strom erzeugt wird, ordnet er einen leeren FIFO zu und initialisiert die Kopf- und Endzeiger, um den Datenfluss in den und aus dem Strom abzuwickeln. Der StreamID schickt die ID des neuen Stroms zurück. Falls der DevID nicht der des aufrufenden Prozessors ist, wird eine Stromsteuerstruktur sowohl im aufrufenden Prozessor als auch im DevID-Prozessor erzeugt, um die durch die Kommunikationsschnittstelle fließenden Daten zu steuern. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
STRM_SUCCESS
STRM_DEVID_NOT_FOUND
STRM_DEVID_NOT_RESPONDING
STRM_ALLOCATION_ERROR
Delete_Channel

BOOL Delete_Stream(T_StrmID StreamID, U16 *errcode);

Diese Funktion löscht einen durch den StreamID spezifizierten vorhandenen Strom. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
STRM_SUCCESS
STRM_DEVID_NOT_FOUND
STRM_DEVID_NOT_RESPONDING
STRM_STREAM_NOT_FOUND
Get_Stream_Count

BOOL Get_Stream_Count(T_LocalStrmID StrmID, T_Count *count, U16 *errcode);

Diese Funktion fordert die Anzahl der T_DSP_Words an, die sich gegenwärtig im durch den StrmID spezifizierten Strom-FIFO befinden. Der count-Parameter enthält beim Rücksprung die Anzahl. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
STRM_SUCCESS
STRM_STREAM_NOT_FOUND
Write_Stream

BOOL Write_Stream(T_LocalStrmID Strm, T_DSP_Word *bufptr, T_Count count, T_Count *countwritten, U16 *errcode);

Diese Funktion schreibt die count-Anzahl von T_DSP_Words in den durch den Strm spezifizierten Strom. Falls der Strm NULL ist, wird der Ausgangstrom des Tasks verwendet. Auf die Daten wird durch den bufptr-Parameter gezeigt. Beim Rücksprung enthält der countwritten die Anzahl der tatsächlich geschriebenen T_DSP_Words. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
STRM_SUCCESS
STRM_DEVID_NOT_FOUND
STRM_DEVID_NOT_RESPONDING
STRM_STREAM_NOT_FOUND
STRM_STREAM_OVERFLOW
Read_Stream

BOOL Read_Stream(T_LocalStrmID Strm, T_DSP_Word *bufptr, T_Count maxcount, BOOL WaitFlag, T_Count *countread, U16 *errcode);

Diese Funktion liest die Daten aus dem durch den Strm spezifizierten Strom. Falls der Strm NULL ist, wird der Eingangstrom des Tasks verwendet. Die Daten werden in dem Puffer gespeichert, auf den durch den bufptr gezeigt wird. Bis zu maxcount T_DSP_Words werden aus dem Strom gelesen. Der countread-Parameter enthält die tatsächliche Anzahl der gelesenen Daten. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
STRM_SUCCESS
STRM_DEVID_NOT_FOUND
STRM_DEVID_NOT_RESPONDING
STRM_STREAM_NOT_ FOUND
Set_Task_Input_Stream

BOOL Set_Task_Input_Stream(T_Task *TaskID, T_StrmID StrmID, U16 *errcode);

Diese Funktion setzt den Eingangsstrom eines Tasks auf die spezifizierte Strom-ID. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
STRM_SUCCESS
STRM_DEVID_NOT_ FOUND
STRM_DEVID_NOT_RESPONDING
STRM_TASK_NOT_FOUND
STRM_STREAM_NOT_ FOUND
Set_Task_Output_Stream

BOOL Set_Task_Output_Stream(T_Task *TaskID, T_StrmID StrmID, U16 *errcode);

Diese Funktion setzt den Ausgangsstrom eines Tasks auf die spezifizierte Strom-ID. Der errcode-Parameter enthält die folgenden möglichen Ergebnisse:
STRM_SUCCESS
STRM_DEVID_NOT_FOUND
STRM_DEVID_NOT_RESPONDING
STRM_TASK_NOT_FOUND
STRM_STREAM_NOT_FOUND
DIE DATENTYPEN

Die hierin verwendeten Datentypen sind in der Tabelle 3 definiert: Tabelle 3

Symbol	Beschreibung
S8	vorzeichenbehaftete ganze 8-Bit-Zahl
U8	vorzeichenlose ganze 8-Bit-Zahl
S16	vorzeichenbehaftete ganze 16-Bit-Zahl
U16	vorzeichenlose ganze 16-Bit-Zahl
S32	vorzeichenbehaftete ganze 32-Bit-Zahl
U32	vorzeichenlose ganze 32-Bit-Zahl
T_HostWord	Ein Wort im Host-Prozessor.
T_DSP Word	Ein Wort im DSP-Prozessor.
BOOL	Boolescher Wert (WAHR oder FALSCH)
T_Hostprt	Ein Zeiger im Host-Prozessor.
T_DSP_Ptr	Ein Zeiger im DSP-Prozessor.
T_DeviceID	Die Vorrichtungs-ID des Prozessors.
T_TaskID	Eine Struktur, die Felder für eine Vorrichtungs-ID und eine lokale Task-ID des Prozessors enthält.
T_ChanID	Eine Struktur, die Felder für eine Vorrichtungs-ID und eine lokale Kanal-ID des Prozessors enthält.
T_MsgID	Die Nachrichten-ID.
T_DSP_ID	Eine Objekt-ID im DSP.
T_Count	Der Datentyp für eine Anzahl.
T_Size	Der Datentyp für eine Größe.
T_HostCallBack	Der verwendete Wert, wenn Tasks eine Nachricht zurück zum Host senden.
T_ReplyRef	Die Nachrichtenantwort-Bezugnahme.
T_LocalTaskID	Die lokale Task-ID.
T_LocalChanID	Die lokale Kanal-ID.
T_DSP_Name	Der Name für DSP-Objekte (RTOS-abhängig).
T_CodeHdr	Die Codekopfstruktur für einen DSP-Bibliothekseintrag.
T_TaskCreate	Die Task-Erzeugungsstruktur.

DIE SYSTEMNACHRICHTEN

Diese Tabellen definieren die Nachrichten, die zwischen den Vorrichtungen (d. h. vom Host zum DSP 16) weitergeleitet werden. Die Vorrichtungs-IDs, die als Parameter in den entsprechenden Funktionsaufrufen vorhanden sind, werden nicht in die Nachrichten aufgenommen, weil sie verwendet werden, um die Nachricht tatsächlich zu der Vorrichtung zu leiten. Ähnlich enthalten die Task-IDs, die eine Vorrichtungs-ID als ihre obere Hälfte für den Funktionsaufruf enthalten, nicht die Vorrichtungs-ID in der Nachricht, sondern nur den Abschnitt der lokalen Task-ID des DSP. Tabelle 4. Die DSP-API-Nachrichten

Nachricht	Sendeparameter	Antwortparameter	Richtung Host ⇔ DSP
GET_MIPS	keine	U32 mips	→
GET_MEM_AVAIL		T_Size progmem T_Size datamem	→
ALLOC_MEM	U16 mempage T_Size size	T_DSP_Word *memptr U16 errcode	→
FREE_MEM	U16 mempage T_DSP_Word *mempage	U16 errcode	→
PUT_BLOB	T_DSP_Ptr destaddr U16 mempage T_Size size T_DSP_Word BLOB[size]	U16 errcode	→
CREATE_TASK	T_TaskCreate tcs	T_TaskID TaskID U16 errcode	→
START_TASK	T_TaskID TaskID	U16 errcode	→
SUSPEND_TASK	T TaskID TaskID	U16 errcode	→
RESUME_TASK	T_TaskID TaskID	U16 errcode	→
DELETE_TASK	T_TaskID TaskID	U16 errcode	→
CHANGE_PRIORITY	T_TaskID TaskID U16 newpriority	U16 oldpriority U16 errcode	→
GET_TASK_STATUS	T_TaskID TaskID	U16 status U16 priority T_ChanID Input T_ChanID Output U16 errcode	→
GET_ID	T_DSP_Name Name	T_DSP_ID ID U16 errcode	→

Tabelle 5. Die Nachrichten der DSP-Schnittstellenschicht/Kanal-Schnittstellenschicht

Nachricht	Sendeparameter	Antwortparameter	Richtung Host ⇔ DSP
CREATE_CHANNEL	T_Size framesize T_Count numframes	T_ChanID ChannelID U16 errcode	→
DELETE_CHANNEL	T_ChanID ChannelID	U16 errcode	→
CREATE_STREAM	T_Size FIFOsize	T_StrmID StreamID U16 errcode	→
DELETE_STREAM	T_StrmID StreamID	U16 errcode	→

Tabelle 6. Die Austestnachrichten

Nachricht	Sendeparameter	Antwortparameter	Richtung Host ⇔ DSP
READ_MEM	U16 mempage T_DSP_Ptr addr T_Count count	T_DSP_Word mem[count] U16 errcode	→
WRITE_MEM	U16 mempage T_DSP_Ptr addr T_Count count T_DSP_Word mem[count]	U16 errcode	→
READ_REG	U16 RegID	DSP_WORD regvalue U16 errcode	→
WRITE_REG	U16 RegID DSP_WORD regvalue	U16 errcode	→
SET_BREAK	T_DSP_Ptr addr	U16 errcode	→
CLR_BREAK	T_DSP_Ptr addr	U16 errcode	→
BREAK_HIT	T_DSP_Ptr addr	U16 ACK

DAS HERUNTERLADEN DES MASCHINENCODES
Die 4-6 veranschaulichen eine Ausführungsform zum Herunterladen des Maschinencodes zu einem Zielprozessor (d. h. dem Host 12 oder dem DSP 16) in einer sicheren und effizienten Weise. Diese Ausführungsform zum Herunterladen des Codes könnte z. B. beim Herunterladen von Code aus dem Internet oder einem anderen globalen Netz, aus einem lokalen oder weiträumigen Netz oder von einer Peripherievorrichtung, wie z. B. einer PC-Karte oder Chip-Karte, verwendet werden.
In 4 ist eine Ausführungsform einer JAVA-Bohne 90 gezeigt, wobei die Bohne 90 als eine Hülle für den Maschinencode 92 wirkt. Die Bohne enthält ferner mehrere Attribute 94, die als ein Codetyp-Attribut 94a, ein Codegrößen-Attribut 94b und ein Attribut der erforderlichen MIPS 94c aufgelistet sind. Die Bohne 90 besitzt mehrere Prozesse 96, einschließlich eines Laden-des-Codes-Prozesses 96a, eines Laden-der-Parameter-Prozesses 96b und eines Ausführungsparameters 96c.
In Betrieb wird der Laden-des-Codes-Prozess 96a verwendet, um externen Maschinencode (Maschinencode für den Zielprozessor) in die Bohne zu laden. Weil die JAVA-Bohnen Persistenz besitzen, kann die Bohne 90 ihren internen Zustand, einschließlich des Maschinencodes 92 und der Attribute 94, speichern. Der Laden-der-Parameter-Prozess 96b gewinnt die Parameter aus dem Maschinencode 92 (z. B. unter Verwendung des oben beschriebenen COFF-Dateiformats) wieder und speichert die Parameter als die Attribute 94a–c. Der Ausführungsprozess 96c führt die im DSP 16 installierten Tasks aus.
5 veranschaulicht die Verwendung der Bohne 90, um den Code zum Zielprozessor herunterzuladen. In diesem Beispiel wird angenommen, dass der Zielprozessor der DSP 16 (oder einer von mehreren DSPs 16) ist, obwohl sie ebenso verwendet werden könnte, um den Maschinencode zum Host-Prozessor 12 herunterzuladen. Ferner wird angenommen, dass die gewünschte Bohne 90 in einem Netz-Server, wie z. B. einem LAN-Server oder einem Internet-Server, steht, obwohl die Bohne in jeder Vorrichtung stehen könnte, die mit der Plattform 10 in Verbindung steht, wie z. B. in einer Chip-Karte. Für eine drahtlose Datenplattform 10 ist die Verbindung zum Netz-Server 100 oft drahtlos.
In 5 ist die Plattform 10 an einen Netz Server 100 gekoppelt. Der Host-Prozessor 12, der in 2 ausführlicher gezeigt ist, kann ein oder mehrere JAVA-Applets 40 durch eine virtuelle JAVA-Maschine 44 ausführen. Um neuen Code herunterzuladen, lädt der Host 12 ein Applet, das die Bohne 90 enthält, vom Netz-Server 100, oder die Bohne kann, ohne das Applet zu enthalten, vom Server 100 heruntergeladen werden. Sobald die Hüllen-Bohne 90 wiedergewonnen worden ist, kann sie nach der Größe des Maschinencodes, den Codetyp (für welchen Prozessor der Code vorgesehen ist) und den erforderlichen MIPS abgefragt werden. Falls der vorgesehene Prozessor ausreichend Betriebsmittel besitzt, um den Code 92 auszuführen, kann der Code 92 installiert werden, um im vorgesehenen Prozessor ausgeführt zu werden, entweder im Host-Prozessor 12 oder im DSP 16 in den 5 gezeigten Architektur. Typischerweise ist der Maschinencode 92 nicht gelinkter kompilierter Code. Folglich linkt der Kreuzlinker 82 der DSP-API 50 den Code für eine verfügbare Speicherstelle. Die Bohne leitet den binären Maschinencode 92 zum dynamischen Kreuzlinker 82, der den Code installieren und ausführen würde.
Eine typische Weise, in der ein Herunterladen von Maschinencode vorkommen könnte, ist, wenn der Benutzer ein Applet ausführt, in dem eine DSP-Funktion gewünscht ist. Zuerst würde das Applet prüfen, um festzustellen, ob der gewünschte Code als ein Task 60 im DSP installiert worden ist oder in der DSP-Bibliothek 58 verfügbar gewesen ist. Wenn ja, könnte der Task ohne ein Herunterladen ausgeführt werden.
Falls der Task nicht im DSP 16 oder der DSP-Bibliothek 58 gespeichert ist, könnte ein Objekt (das hierin als das "DSPLoader"-Objekt bezeichnet wird) erzeugt werden, um die Bohne 90 zu laden. Falls die DSPLoader-Klasse im Host 12 lokal ist, prüft JAVA, um festzustellen, ob die Bohne ebenso lokal verfügbar ist. In einem ersten Fall kann eine Bohne mit dem Code lokal gespeichert sein. Wenn ja, wird der Code aus der Bohne im DSP (oder in welchem durch den Codetyp spezifizierten Prozessor auch immer) installiert. Falls eine Bohne ohne den Code lokal gespeichert ist, kann die Bohne den Code vom geeigneten Server wiedergewinnen.
Wenn andererseits das DSPLoader-Objekt nicht lokal ist, dann lädt JAVA die Bohne 90 vom Server, der das Applet geschrieben hat. Der Code von der Bohne wird dann so installiert, wie es oben beschrieben worden ist.
Während das Herunterladens des Maschinencodes im Zusammenhang mit der Verwendung einer JAVA-Bohne beschrieben worden ist, könnte es außerdem ausgeführt werden, indem der Code innerhalb einer weiteren Sprache, wie z. B. als ein ActiveX-Applet, eingewickelt wird.
Das Verwenden einer JAVA-Bohne (oder eines anderen Applets) als eine Hülle für den Maschinencode besitzt signifikante Vorteile. Erstens erlaubt es ein einfaches Standardverfahren zum Laden des Codes auf einen von mehreren Prozessoren. Die Bohne wird erzeugt, der Code wird in die Bohne geladen und der Code wird für den geeigneten Prozessor gelinkt. Ohne das Einwickeln des Codes innerhalb der Bohne kann der Prozess mehrere hundert Schritte benötigen. Zweitens erlaubt es, dass mehrere Stücke des Maschinencodes durch ein einziges Applet kombiniert werden, was dafür sorgt, dass komplexe Anwendungen aus mehreren diskreten Routinen unter Verwendung eines einzigen Applets, um die Routinen auf Wunsch zu kombinieren, erzeugt werden. Drittens nutzt es die Sicherheitsmerkmale der Sprache aus und schützt dadurch nicht nur den JAVA-Code in der Bohne 90, sondern ebenso den Maschinencode 92. Andere Sprachen, wie z. B. ActiveX, besitzen ebenso Sicherheitsmerkmale.
DIE SICHERHEIT
Zwei der wichtigsten Sicherheitsmerkmale sind die digitale Signierung und die Verschlüsselung. Eine JAVA-Bohne oder ein ActiveX-Applet können durch die Quelle des Codes signiert werden; wenn die Bohne oder das Applet heruntergeladen wird, wird die Signatur durch die empfangende Anwendung verifiziert, die eine Liste vertrauenswürdiger Quellen besitzt. Falls die Bohne oder das Applet durch eine vertrauenswürdiger Quelle signiert worden ist, kann sie bzw. es unter Verwendung von Standardtechniken entschlüsselt werden. Demzufolge ist der Maschinencode während der Übertragung zusammen mit dem Code der Bohne oder des Applets verschlüsselt, was eine unberechtigte Modifikation des Codes verhindert. Weil der Maschinencode sicher ist und von einer vertrauenswürdigen Quelle kommt, kann den Attributen außerdem als genau vertraut werden.
6 veranschaulicht einen Ablaufplan, der den Prozess des Herunterladens des Maschinencodes für einen Prozessor unter Verwendung einer JAVA-Bohne beschreibt, wobei es selbstverständlich ist, dass der Maschinencode unter Verwendung ähnlicher Techniken in ein Applet einer anderen Sprache eingewickelt sein könnte. Im Schritt 110 wird die verschlüsselte, digital signierte Bohne 90 zu einer Vorrichtung herunterladen, die eine virtuelle JAVA-Maschine ausführt. Im Schritt 112 wird die Signatur verifiziert. Falls sie nicht von einer Quelle kommt, die als eine vertrauenswürdige Quelle aufgelistet ist, wird im Schritt 114 die Aus nahmeverarbeitung freigegeben. In dem Fall, in dem die Bohne von einer vertrauenswürdigen Quelle kommt, kann die Funktion der Ausnahmeverarbeitung dem Benutzer eine Gelegenheit geben, die Bohne zu akzeptieren, falls der Benutzer mit der Quelle sorgenfrei ist. Falls die Signatur ungültig ist, kann die Ausnahmeverarbeitung die Bohne 90 löschen und eine geeignete Fehlernachricht an den Benutzer senden.
Falls die Signatur gültig ist und von einer vertrauenswürdigen Quelle kommt, wird im Schritt 116 die Bohne entschlüsselt. Dieser Schritt entschlüsselt sowohl den JAVA-Code als auch den Maschinencode in der Bohne. Im Schritt 118 werden die Attribute von der Bohne 90 wiedergewonnen, während im Schritt 120 das Applet bestimmt, ob der geeignete Prozessor ausreichend Betriebsmittel besitzt, um den Code auszuführen. Falls nicht, kann es der Schritt 114 der Ausnahmeverarbeitung ablehnen, den Maschinencode zu installieren, oder es können Schritte unternommen werden, um Betriebsmittel freizugeben. Falls es ausreichend Betriebsmittel gibt, wird der Code im Schritt 122 unter Verwendung des Kreuzlinkers gelinkt und im gewünschten Prozessor installiert. Im Schritt 124 wird der Maschinencode ausgeführt.
Ein Beispiel-JAVA-Skript für eine Bohne 90 ist im folgenden bereitgestellt:
Im oben dargelegten Script erzeugt die NativeBean()-Routine die Bohne 90, die den Maschinencode enthält. Die loadCode()-Routine erhält den Maschinencode vom Server. Die getFunctionName()- und getCodeBase()-Routinen gewinnen die Attribute wieder. Die installCode()-Routine ruft den Kreuzlinker auf, um den Maschinencode für den DSP zu linken und den gelinkten Code zu laden. Die loadParameters()-Routine weist die Bohne an, den Maschinencode zu untersuchen und seine Attribute zu bestimmen. Die getCodesize()- und getCodetype()-Routinen übertragen die Attribute zum anfordernden Applet.
Obwohl die ausführliche Beschreibung der Erfindung auf bestimmte beispielhafte Ausführungsformen gerichtet gewesen ist, werden für die Fachleute auf dem Gebiet sowohl verschiedene Modifikationen dieser Ausführungsformen als auch alternative Ausführungsformen naheliegen. Die Erfindung umfasst alle Modifikationen oder alternative Ausführungsformen, die in den Umfang der Ansprüche fallen.

Claims

Mobile elektronische Vorrichtung, mit: einem oder mehreren Coprozessoren (16), wovon jeder eine Funktionalität hat, die dynamisch geändert werden kann; einem Host-Prozessorsystem (12) zum Ausführen: eines dynamischen Kreuzkompilierers (80), um Quellcode zu empfangen und um den Quellcode in eine Maschinencode-Routine für einen aus dem einen oder den mehreren Coprozessoren ausgewählten Ziel-Coprozessor zu kompilieren; und eines dynamischen Kreuzlinkers (82), um Adressen in der Maschinencode-Routine aufzulösen und die Maschinencode-Routine zu dem Ziel-Coprozessor herunterzuladen; und einer Schaltungsanordnung (18) für die Kommunikation zwischen dem Host-Prozessorsystem und den Coprozessoren.
Mobile elektronische Vorrichtung nach Anspruch 1, bei der den Coprozessoren Speicher zum Speichern von Tasks zugewiesen sind.
Mobile elektronische Vorrichtung nach Anspruch 2, bei der der Host-Prozessor einen verfügbaren Ort in dem dem Ziel-Coprozessor zugeordneten Speicher zum Speichern der Maschinencode-Routine bestimmt.
Mobile elektronische Vorrichtung nach einem vorhergehenden Anspruch, bei der der Host-Prozessor den Code in nicht gelinkten Maschinencode für den Ziel-Coprozessor kompiliert.
Mobile elektronische Vorrichtung nach Anspruch 4, wenn abhängig von Anspruch 3, bei der der dynamische Kreuzlinkers Adressen in der Maschinencode-Routine in Reaktion auf den verfügbaren Ort auflöst.
Verfahren zum Steuern einer mobilen elektronischen Vorrichtung, die ein Host-Prozessorsystem (12) und einen oder mehrere Coprozessoren (16) umfasst, wobei jeder Coprozessor eine Funktionalität hat, die dynamisch geändert werden kann, wobei das Verfahren umfasst: in dem Host-Prozessorsystem (12): Ausführen eines dynamischen Kreuzkompilierers (80), um Quellcode zu empfangen und um den Quellcode in eine Maschinencode-Routine für einen Ziel-Coprozessor zu kompilieren; und Ausführen eines dynamischen Kreuzlinkers (82), um Adressen in der Maschinencode-Routine aufzulösen und die Maschinencode-Routine zu dem Ziel-Coprozessor herunterzuladen; Ausführen der Maschinencode-Routine in dem Ziel-Coprozessor; und Kommunizieren zwischen dem Host-Prozessorsystem und dem Ziel-Coprozessor.
Verfahren nach Anspruch 6, das ferner den Schritt des Bestimmens eines verfügbaren Ortes in einem dem Ziel-Coprozessor zugeordneten Speicher zum Speichern der Maschinencode-Routine umfasst.
Verfahren nach Anspruch 6 oder Anspruch 7, bei dem der Schritt des Ausführens des dynamischen Kreuzkompilierers den Schritt des Kompilierens des Quellcodes in nicht gelinkten Maschinencode umfasst.
Verfahren nach Anspruch 8, wenn abhängig von Anspruch 7, bei dem der Schritt des Ausführens eines dynamischen Kreuzlinkers den Schritt des Auflösens von Adressen in dem nicht gelinkten Maschinencode in Reaktion auf den verfügbaren Ort umfasst.
Verfahren nach einem der Ansprüche 6 bis 9, das ferner den Schritt des Auswählens eines von mehreren Coprozessoren als den Ziel-Coprozessor umfasst.