Kithara »Hardware Toolkit«
Das »Hardware Toolkit« erübrigt die aufwändige Entwicklung eines eigenen Kernel-Treibers und bietet alles, was man zur Treiber-Entwicklung braucht.
Das »Hardware Toolkit« stellt Funktionen für verzögerungsfreie Zugriffe auf die I/O-Register und den physischen Speicher der PC-Hardware bereit. Zusätzlich ist auch die Behandlung von Hardware-Interrupts auf der Anwendungs- oder Kernel-Ebene möglich. Außerdem können Sie die PCI-Konfigurationsdaten und Schnittstellen-Ressourcen ermitteln.
Damit stehen alle erforderlichen Mechanismen zur schnellen Entwicklung von Hardware-Treibern - insbesondere für PCI-Karten - bereit.
Die gesamte Entwicklung erfolgt aus Ihrer gewohnten Programmierumgebung heraus, so dass Sie sich nicht in die Kernel-Entwicklung einarbeiten müssen.
- Zugriff auf alle I/O-Register des PCs aus Anwendung oder DLL
- I/O-Port-Zugriffe: 8 Bit, 16 Bit und 32 Bit
- Einblenden von externem physischen Speicher (Dual-Port-RAM)
- Interner Speicher für Zugriff von PC-Einsteckkarten (DMA Memory)
- Ermittlung der PCI-Konfigurationsdaten und Ressourcen
- Leistungsfähige Mechanismen zur Interrupt-Programmierung
- Interrupt-Behandlung sowohl auf Kernel- als auch auf Anwendungsebene
- Mehrere Handler pro IRQ installierbar
- Unterstützung von PIC- und APIC-Hardware, Multiprozessor-PCs
- Generischer WDM-Treiber für Plug&Play-Installation enthalten
- Nutzung der Kernel-Ebene unterstützt C/C++ oder Delphi (Win32 native)
- Unterstützt die folgenden Betriebssysteme: Windows 7, Vista, Server 2003, XP, 2000 und NT
- Beschreibung
- Eigenschaften
- Beispiele
- FAQ
- Hardware
Das Base Module ist die Grundlage der gesamten »RealTime Suite«.
Erzeugen Sie alle benötigten Ressourcen, die zum Beispiel für die Kommunikation zwischen Anwendung und Kernel-Ebene sorgen!
Das Base Module stellt Funktionen zur Verwaltung des Kernel-Treibers bereit. Die »RealTime Suite« kann dabei von mehreren Programmen gleichzeitig verwendet werden.
Das Base Module enthält Funktionen zur Erzeugung und Verwaltung folgender Ressourcen:
- Shared Memory
- Daten- und Message-Pipes für schnellen Datenaustausch
- Event-Objekte
- CallBack-Funktionen
- Threads
- Quick-Mutexe
Im Base Module befinden sich mehrere Funktionen, die dem Absetzen von Meldungen an den »Kernel Tracer« dienen. Das erleichtert die Fehlersuche und ist auch für Profiling-Aufgaben einsetzbar.
Beachten Sie auch das Kernel Module, das weitere allgemein gültige Funktionen bereitstellt und für den Zugang zur Kernel-Ebene unverzichtbar ist.
Das Base Module ist immer erforderlich.
- Allgemeine Funktionen
- Öffnen/Schließen des Kernels
- Versionskontrolle, Treiber-Konfiguration
- Threads
- Erzeugen von Threads
- Ermitteln/Setzen beliebiger Stufen der absoluten Thread-Priorität
- Shared Memory
- Shared Memory speziell für Datenaustausch
- geschützt vor Festplatten-Auslagerung (fest im Speicher)
- mehrere Bereiche mit jeweils bis zu über 60 MByte
- Pipes
- Lock-freie und schnelle Daten- und Message-Pipes
- ermöglicht komfortablen und synchronisierten Datenaustausch in beliebiger Richtung zwischen Kernel und Anwendung
- keine weitere Synchronisation benötigt (auch auf Multi-Core-CPUs)
- Signalisierung
- Event-Objekte: Setzen, Rücksetzen und Pulsen aktiviert Anwendungs-Thread
- Callback-Ausführung von Anwendercode auf Kernel- oder Anwendungsebene
- Versenden von Windows-Messages
- Quick-Mutexe
- Schnelle Synchronisation ("Mutex" = Mutual Exclusion)
- Multiprozessortauglich
- Device-Information
- Ermittlung der Geräteinformationen von PCI-, USB-, COM-, HID-Devices etc.
- Debug-Unterstützung
- Absetzen formatierter Text-Meldungen von der Kernel-Ebene aus
- Kompatibel zum »Kernel Tracer« für Profiling und Fehlersuche
Das Base Module stellt vielfältige Werkzeuge bereit, z.B. Shared Memory für den Datenaustausch zwischen Anwendung und Kernel:
err = KS_createSharedMem(
&pAppPtr, // Application-Adresse
&pSysPtr, // Systemadresse des Speichers
"MySharedMem", // Global gültiger Name
40 * MegaBytes, // Länge in Bytes
0); // Flags, hier 0
Zur Vereinfachung für regelmäßigen Datenaustausch ist eine Daten-Pipe ideal, die intern ebenfalls auf Shared Memory basiert:
err = KS_createPipe(
&hPipe, // Adresse des Pipe-Handles
"MyValuePipe", // Name der Pipe
2, // Datengröße (z.B. Messwerte)
1000000, // max. Anzahl Datenelemente
NULL, // reserviert
0); // Flags, hier 0
Nun kann z.B. der Kernel ermittelte Messwerte in der Pipe ablegen:
err = KS_putPipe(
hPipe, // Pipe-Handle
valueBuffer, // Zeiger auf Datenpuffer
valueCount, // Anzahl der Messwerte
NULL, // hier nicht benutzt
0); // Flags, hier 0
Die Anwendung kann nun die Messwerte aus der Pipe lesen:
err = KS_getPipe(
hPipe, // Pipe-Handle
buffer, // Zeiger auf Datenpuffer
bufferSize, // max. Größe des Puffers
&filledSize, // wieviel Werte gelesen?
0); // Flags, hier 0
Daten mit variabler Länge (z.B. Messages) lassen sich optimal mit einer Message-Pipe verarbeiten. Diese ist sehr ähnlich zu verwenden.
- Welche Voraussetzungen müssen allgemein erfüllt sein?
- Unterstützung von Single- oder Dual-Core-, Multi-Core-CPUs, Hyperthreading, SMP etc.
- Unterstützung von Standard-PIC oder APIC, ACPI
- optimal ist ein moderner Dual-/Quad-Core-PC (mit APIC + ACPI)
- Unterstützung von Windows 2000, Windows XP (Embedded), Windows Server 2003, Windows Vista (x86)
- Programmierung der Kernel-Ebene in C/C++ und Delphi (Win32)
- Welche Besonderheiten ergeben sich beim Umgang mit Shared Memory?
- wird nicht auf die Festplatte ausgelagert und ist daher immer verfügbar (auch innerhalb der RealTime-Umgebung)
- ist sowohl von der Anwendungsebene als auch vom Kernel aus ansprechbar
- ist nur einmalig vorhanden und kann daher auch dem Datenaustausch zwischen verschiedenen Anwendungen dienen (es ist jedoch in jedem Programm einmal KS_createSharedMem zu rufen)
- ist anfangs mit 0 initialisiert – durch einen Zähler lässt sich ermitteln, ob der Speicher bereits zuvor von anderen Programmen verwendet wurde
- Zugriffe auf den Speicher sind nicht automatisch synchronisiert (für synchronisierten Zugriff empfehlen wir Daten- und Message-Pipes)
- 32-Bit-CPU
- max. 8 logische Prozessoren (Chips * Kerne * Threads), darüber auf Anfrage
Echtzeitfähigkeit wird nur auf der Kernel-Ebene erzielt.
Bringen Sie Ihren Anwendercode auf die Kernel-Ebene und schaffen Sie sich dadurch den Zutritt zur Echtzeit-Welt unter Windows!
Benötigt werden hierzu C/C++-Compiler oder das Entwicklungstool Delphi (Win32), um nativen x86-Code erzeugen zu können. Beachten Sie jedoch, dass z.B. auch die .NET-Umgebung mit C# unterstützt wird, indem eine native C++- oder Delphi-DLL für den Kernel-Zugang sorgt. Entsprechende sofort compilierbare Projekte befinden sich in jeder Software-Lieferung.
Es gibt zwei verschiedene Wege, um Ihren Anwendercode auf die Kernel-Ebene zu bringen:
- Befehlsweise Relozierung einer Callback-Funktion und ihrer Subroutinen in den Kernel-Adressraum
- Laden einer DLL direkt auf die Kernel-Ebene
Während die erste Methode für kleinere Projekte durchaus Vorteile besitzt, bietet die zweite Variante wesentlich mehr Möglichkeiten und erlaubt z.B. auch die einfachere Erzeugung von Debug-Meldungen, die sich im »Kernel Tracer« für Fehlersuche und Optimierung auswerten lassen.
Außerdem realisieren Sie damit komplexe Steuerungsanwendungen, deren grafische Oberfläche z.B. mit Java oder C#.NET erstellt wird, während nur die zeitkritischen Code-Teile der DLL im Kernel-Modus laufen.
Das Kernel Module ist Voraussetzung, um Anwendercode auf der Kernel-Ebene ausführen zu können.
- Relokation von Callback-Funktionen und deren Subroutinen
- Direktes Laden einer DLL in den Kernel
- DLL zu erstellen mit C/C++ oder Delphi (Win32)
- Callback-Funktionen werden direkt in Interrupt Service Routine (ISR) oder im Echtzeit-Timer-Kontext ausgeführt
- Alle wichtigen Funktionen der »RealTime Suite« auch von der Kernel-Ebene aus aufrufbar, z.B.:
- I/O-Port-Zugriffe
- Zugriffe auf physischen Speicher
- Zeitmessung, genaue Kurzzeitverzögerung
- Senden und Empfangen bei Daten- und Message-Pipes
- Senden und Empfangen bei seriellen Schnittstellen
- Senden und Empfangen bei Ethernet-Controllern
- EtherCAT-Datenaustausch
- Setzen, Rücksetzen, Pulsen von Events
- Ereignisse von Kernel-Ebene: Events und Windows-Messages
- Schneller Datenaustausch zwischen Anwendung und Kernel über Shared Memory oder lock-freie Daten- und Message-Pipes
Angenommen, Ihre Callback-Funktion für den Echtzeit-Timer sieht so aus:
int __stdcall myTimerCallback(
void* pArgs, // Adresse der Referenzdaten
void* pContext); // Adresse der Kontextdaten
Es gibt nun zwei Wege, um den Anwendercode auf die Kernel-Ebene zu bekommen:
err = KS_createCallBack(
&hCallBack, // Adresse des Handles
myTimerCallback, // Adresse der Funktion
pSysAddrOfMyData, // Referenzparameter
KSF_KERNEL_EXEC, // auf der Kernel-Ebene!
0); // Anwendungspriorität, hier 0
Auf diese Weise wird die Funktion in den Kernel-Speicher geladen.
Alternativ lässt sich eine ganze DLL in den Kernel laden:
err = KS_loadKernel(
&hKernel, // Adresse des Handles
"mykernel.dll", // Dateiname der Kernel-DLL
"myInitFunction", // Name der Init-Routine
pArgs, // Referenzparameter
KSF_KERNEL_EXEC); // Flags, in Kernel laden
Einmal in den Kernel geladen, kann nun ganz ähnlich ein Kernel-Callback erzeugt werden:
err = KS_createKernelCallBack(
&hCallBack, // Adresse des Handles
hKernel, // Kernel-Handle
"myTimerCallback", // Name der Funktion
pSysAddrOfMyData, // Referenzparameter
KSF_KERNEL_EXEC, // auf der Kernel-Ebene!
0); // Anwendungspriorität, hier 0
Die Callback-Handles lassen sich nun als Timer oder Interrupt-Handler anmelden oder z.B. zur Echtzeit-Signalisierung bei eintreffenden Ethernet-Frames.
Hinweis: Vollständige Projekte, die eine Rahmenanwendung in einer der Sprachen C++, C# oder Delphi sowie eine in den Kernel geladene DLL in C++ oder Delphi enthalten, sind Bestandteil jeder Software-Lieferung.
- Wie kann der Kernel mit der Anwendung kommunizieren?
- Shared-Memory-Bereiche für nicht synchronisierten Datenaustausch
- Daten- und Message-Pipes basierend auf Shared Memory (Lock-frei, daher sind die lesende und die schreibende Seite gegeneinander synchronisiert)
- Kernel kann Event-Objekte setzen, um Anwendungs-Threads zu aktivieren
- Anwendungsebene kann die Ausführung von Funktionen im Kernel auslösen
- Windows-Messages
- Wie lässt sich Code für die Kernel-Ebene debuggen?
- Anwendercode lässt sich innerhalb der Entwicklungsumgebung debuggen:
- Callback-Funktion wird durch spezielles Flag auf der Anwendungsebene ausgeführt
- Kernel-DLL wird durch spezielles Flag auf die Anwendungsebene geladen
- Shared Memory, Events, Zugriffe auf I/O-Ports und physischen Speicher etc. sind in beiden Kontexten verwendbar
Keine speziellen Hardware-Anforderungen
Das IoPort Module ermöglicht den Zugriff auf I/O-Register des Computers.
Greifen Sie mit dem IoPort Module auf die I/O-Ports des Computers direkt aus der Anwendung heraus zu!
Sowohl bei eingebauten Hardware-Baugruppen als auch Mezzanin- und PC-Einsteckkarten erfolgt die Ansteuerung in den meisten Fällen mittels Zugriffen auf die I/O-Register von Controllern. Hierfür stehen Funktionen für 8-, 16- und 32-Bit-Zugriffe zur Verfügung.
Das IoPort Module ist auch erforderlich, um die Hardware-Ressourcen (z.B. Speicheradressen oder Interrupt-Leitungen) zu ermitteln, die vom Plug&Play-Manager von Windows dynamisch zugewiesen wurden.
Mit dem Begriff "I/O-Ports" sind hier übrigens nicht COM-Ports oder LPT-Ports gemeint, sondern die insgesamt 65536 über I/O-Maschinenbefehle ansprechbaren I/O-Adressen des Systems. Damit lassen sich natürlich auch die I/O-Register der COM- und LPT-Controller ansprechen.
Ergänzen Sie Ihren Custom Driver um das Memory Module, wenn die Hardware, die Sie ansprechen wollen, einen Speicherzugriff bietet.
- I/O-Port-Zugriffe
- Freigabe des Direktzugriffs auf I/O-Ports möglich
- I/O-Zugriffe aus Anwendungsprogramm ohne Kontextwechsel möglich
- Zugriffsschutz des Betriebssystems auf andere als die freigegebenen Adressen weiterhin intakt und aktiv
- Nur eigene Anwendung erhält Zugriff auf Adressen
- Keine Beeinträchtigung des Systems
- Funktionen für direkten und indirekten I/O-Zugriff
- 8-, 16- und 32-Bit-Zugriffe, lesend oder schreibend
- Funktionen kompatibel zu (unter DOS) bekannten C-Makros
- Ressourcen-Ermittlung
- Ermittlung der vom Plug&Play-Manager zugewiesenen Ressourcen (Basisadressen, IRQs)
- Lesen und Schreiben des PCI-Konfigurationsblockes
Wenn der direkte I/O-Port-Zugriff genutzt werden soll, ist zunächst der I/O-Bereich für den Direktzugriff freizuschalten:
err = KS_enableIoRange(
myBaseAddress, // Basisadresse der Hardware
8, // Anzahl der I/O-Register
KSF_SIZE_8_BIT); // Flags, hier byte-weise
Nun können die freigegebenen Hardware-Register direkt adressiert werden:
byte value = KS_inpb(
myBaseAddress + 2); // Adresse, 1 Byte lesen
... // Byte auswerten
KS_outpb(
myBaseAddress + 4, // Adresse, 1 Byte schreiben
value); // Byte schreiben
Wenn die I/O-Basisadresse einer PCI-Karte vom Plug&Play-Manager dynamisch vergeben wurde, kann diese ganz leicht ermittelt werden, indem entweder alle PCI-Baugruppen durchsucht werden, bis die gewünschte (anhand Vendor- und Device-ID) gefunden wird:
err = KS_getBusData(
&pciData, // Adresse der PCI-Struktur
busNumber, // Bus-Nummer
slotNumber, // Gerätenummer und Funktion
0); // Flags, hier 0
if (pciData.vendorID == XXXX && pciData.deviceID == YYYY)
...
Oder es wird sofort die gewünschte ID-Kombination gesucht:
err = KS_getRessourceInfo(
"PCI\\VENxxxx&DEVyyyy", // ID-Kombination
&resourceInfo); // Adresse der Resourcen-Info
Die erhaltenen Datenstrukturen enthalten nun die benötigten Angaben über Interrupt-Leitung und benutzte I/O- oder Speicher-Basisadressen.
- Wie können die vom PCI-Plug&Play dynamisch zugewiesenen Ressourcen ermittelt werden?
- entweder mit 'KS_getBusData': Iterieren über alle im System befindlichen PCI-Geräte, bis anhand der Parameter (Vendor-Id, Device-Id, etc.) das gesuchte Gerät gefunden wurde
- oder mit 'KS_getResourceInfoEx': Übergabe der Parameter des gesuchten Gerätes und Auswertung der beschreibende Datenstruktur
- mit 'KS_getResourceInfo' lassen sich auch die Daten anderer Schnittstellen ermitteln, z.B. serielle ("COM") oder parallele ("LPT") Schnittstellen, Netzwerkkarten ("NET") für das Packet Module sowie USB-Geräte ("USB")
Keine speziellen Hardware-Anforderungen
Das Memory Module dient dem Zugriff auf physischen Speicher.
Greifen Sie auf externen Speicher von Einsteckkarten zu oder stellen Sie internen RAM für den Hardware-Zugriff zur Verfügung!
Das Memory Module ermöglicht die Verwendung von physischem Speicher sowohl von Ihrer Anwendung, als auch von externer Hardware aus. Dafür gibt es zwei verschiedene Arten von Speicherbereichen:
- externe Speicherbereiche von Einsteckkarten (sogenannter Dual-Port-RAM) sollen auch von der Anwendung aus adressierbar sein
- Speicherbereiche aus dem internen Hauptspeicher sollen der externen Hardware zur Verfügung gestellt werden (sogenanntes DMA-Memory)
Das Ergebnis ist in beiden Fällen gleich: Sowohl die Anwendung (und auch die Kernel-Ebene) als auch die externe Hardware (z.B. auf dem PCI-Bus) haben Zugriff auf den Speicher. Dieser wird in den Adressraum der Anwendung eingeblendet – auf diese Weise finden keinerlei unnötige Kopieroperationen statt, was die Eignung für zeitkritische Anwendungen begründet.
Dies kann für bestimmte Applikationen entscheidend sein, da Zugriffe über I/O-Ports in der Regel künstlich stark ausgebremst werden, um Kompatibilität zu älteren Hardware-Komponenten zu wahren (teilweise ? 1 µs!). Bevorzugte Anwendungen sind daher: Messwerterfassung, Kommunikation, Framegrabber für die Bildverarbeitung etc., also alle Applikationen, bei denen große Datenmengen schnell transportiert werden müssen.
Das Memory Module beschränkt sich auf reine Speicherzugriffe. Für die Adressierung von I/O-Ports beachten Sie bitte auch das IoPort Module.
- Externer Speicher
- Einblenden von externem Dual-Port-RAM in den Adressraum der Anwendung
- Getrennte Adressen für Anwendung und Kernel-Ebene
- Direkter Zugriff – keine Software-Emulation oder Kopieroperation
- Interner Speicher
- Bereitstellen von internem Hauptspeicher für externe Hardware auf ISA- oder PCI-Bus
- Physikalisch zusammenhängender Speicher
- Physikalische Adresse kann der externen Hardware auf geeignete Weise übermittelt werden
- Zur Erhöhung allokierbarer Blockgrößen ist Anforderung des Speichers bereits zum Bootzeitpunkt möglich
Das Einblenden externer Speicherbereiche (Dual-Port-RAM) einer PCI-Karte in den Adressraum der Anwendung und des Kernels erfolgt so:
err = KS_mapPhysMem(
&pAppPtr, // Application-Adresse
&pSysPtr, // Systemadresse des Speichers
externalPhysAddr, // physikalische Adresse
externalSize, // Länge des Speicherbereichs
KSF_PCI_BUS); // Flags, hier PCI-Bus
Das Allokieren interner Speicherbereiche des PC-RAM für Zugriffe durch die externe Hardware (sogenanntes "Bus-Master-DMA") einer PCI-Karte erfolgt so:
err = KS_allocPhysMem(
&pAppPtr, // Application-Adresse
&pSysPtr, // Systemadresse des Speichers
&externalPhysAddr, // physikalische Adresse
externalSize, // Länge des Speicherbereichs
KSF_PCI_BUS); // Flags, hier PCI-Bus
Die physikalische Adresse kann nun auf geeignete Weise an die Hardware übermittelt werden, damit diese über den PCI-Bus auf den Speicher zugreifen kann.
Beide Methoden führen dazu, dass sowohl die Anwendung, der Kernel und die externe Hardware direkt (ohne Emulation oder Kopieroperationen) auf den selben Speicher zugreifen können.
- Wie groß ist der maximal zu mappende Bereich externen Speichers?
- im Prinzip so groß wie der externe Speicher ist; es sollte keine Beschränkung geben
- Wie groß ist der maximal zu allokierende Bereich internen Speichers?
- Speicher muss physisch zusammenhängend sein, daher umso geringer, je länger das System läuft. Es sollte daher so früh wie möglich nach dem Boot-Vorgang der Speicher angefordert werden. Der Systemspeicher wird vom Betriebssystem sehr schnell "zerstückelt".
- Memory Module enthält Mechanismen zur Allokation von Speicherbereichen bereits zum Boot-Zeitpunkt, die später von der Anwendung abgefordert werden können
- Außerdem können eher mehrere kleinere statt eines größeren Bereichs allokiert werden. Es bietet sich daher eine sogenannte "Scatter/Gather"-Verwaltung des Speichers an.
Keine speziellen Hardware-Anforderungen
Das Interrupt Module ermöglicht die Behandlung von Hardware-Interrupts.
Realisieren Sie Handler für Hardware-Interrupts von ISA- und PCI-Bus-Baugruppen unmittelbar in der Anwendungs-Programmierumgebung!
Bei der hardwarenahen Programmierung, beispielsweise der Entwicklung von Gerätetreibern, sind häufig auch Ereignisse der Hardware-Baugruppe in Form von Interrupts auszuwerten. Das Interrupt Module erlaubt die Anmeldung von Interrupt-Handlern für Einsteckkarten am ISA- und PCI-Bus sowie für interne Baugruppen.
Die Interrupt-Behandlung kann im Kernel oder auf der Anwendungsebene erfolgen. PCI-Interrupts sind allerdings bereits auf der Kernel-Ebene zu quittieren. Dafür können auch mehr als ein Handler für einen Interrupt registriert werden – beispielsweise eine kleinere Funktion für die Quittierung des IRQs auf der Kernel-Ebene und zusätzlich eine weitere Funktion auf der Anwendungsebene für die eigentliche Auswertung des Interrupts.
Zum Ansprechen von USB-Hardware beachten Sie bitte auch das USB Module.
Erfordert das Kernel Module.
- Anmeldung von Interrupt-Handlern für ISA- und PCI-Interrupts
- Behandlung auf Anwendungs- oder Kernel-Ebene (Quittierung von PCI-IRQs im Kernel)
- Unterstützung aller PCI-Bustypen einschließlich PCIexpress
- Aufruf der Kernel-Funktionen unmittelbar im Kontext der Interrupt Service Routine (ISR)
- Unterstützung von ACPI-, PIC-, APIC- und Multiprozessor-Computern (Dual-Core, Quad-Core etc.)
- Vorübergehende Sperrung der Interrupt-Behandlung möglich
- Kernel-Treiber der »RealTime Suite« kann selbst als WDM-Treiber für PCI-Plug&Play konfiguriert werden.
Angenommen, es soll folgende Callback-Funktion als Interrupt-Handler fungieren:
int __stdcall myInterruptHandler(
void* pArgs, // Adresse der Referenzdaten
void* pContext); // Adresse der Kontextdaten
Hiermit erstellen Sie ein Callback-Objekt (siehe Kernel Module) mit dem Flag KSF_DIRECT_EXEC.
Zur Anmeldung des Interrupt-Handlers sind zunächst die Ressourcen-Informationen zu ermitteln:
KSResourceInfoEx info;
err = KS_getResourceInfoEx(
"PCI\\VEN_10ec&DEV_8139",// Hardware-ID der PCI-Karte
&info); // Zu füllende Info-Struktur
Damit lässt sich nun der Interrupt-Handler anmelden:
err = KS_createDeviceInterrupt(
&hInterrupt, // Adresse des Handles
&info, // Info-Struktur
hCallBack, // Callback-Handle
KSF_ACCEPT_PENDING |
KSF_PCI_INTERRUPT); // Flags, hier PCI
Es lassen sich auch mehrere Handler beim selben IRQ anmelden, z.B. eine Callback-Funktion für die Kernel-Ebene und eine weitere innerhalb des Anwendungskontexts.
- Wie erfolgt die Unterstützung von Plug&Play-Mechanismen?
- Der jeweilige Treiber der »RealTime Suite« lässt sich selbst als Plug&Play-Treiber verwenden. Hierzu ist die mitgelieferte Installations-Textdatei (*.INF) lediglich um einen Eintrag mit der Spezifikation der PCI-Karte oder des UDB-Gerätes zu erweitern.
- Wie lässt sich ermitteln, welche Interrupt-Leitung verwendet wird (Plug&Play)?
- Die vom PCI-Plug&Play-Manager dynamisch zugeordneten Ressource-Informationen lassen sich einfach ermitteln. Siehe IoPort Module.
Keine speziellen Hardware-Anforderungen
Plattformen
Echtzeitfähigkeit wird nur auf der Kernel-Ebene erzielt. Dazu werden C/C++ oder Delphi (Win32) benötigt. Dennoch unterstützt die »RealTime Suite« verschiedene Plattformen, wie z.B. auch die .NET-Umgebung:
- C++Builder (Borland/CodeGear) mit VCL-Oberfläche
- Microsoft Visual C++ 6 mit MFC-Oberfläche
- Visual Studio 2005/2008 C++ mit MFC-Oberfläche
- Delphi (Object Pascal) Win32 mit VCL-Oberfläche
- Visual Studio 2005 C# mit WPF-Oberfläche
Die Lösung besteht darin, den zeitkritischen Code in eine DLL zu verlagern, die mit den Funktionen der »RealTime Suite« direkt auf die Kernel-Ebene geladen wird und dadurch in den Echtzeit-Kontext gelangt.
Sofort verwendbare Programmgerüste für die genannten Plattformen befinden sich in jeder Software-Lieferung.
Systemvoraussetzungen
Die Produkte der »RealTime Suite« unterstützen eine breite Palette von Hardware- und Software-Kombinationen:
- CPU: AMD (ab Athlon) oder Intel (ab Pentium 2)
- Single- oder Multi-Core, Hyperthreading, SMP mit insgesamt bis zu 8 CPU-Kernen (darüber auf Anfrage)
- ACPI (Advanced Control and Power Interface) unterstützt, (A)PIC (Advanced Programmable Interrupt Controller) unterstützt (einige Funktionen erfordern APIC-PC)
- Betriebssystem: Windows 2000 (bis SP4), Windows XP (bis SP3), Windows Server 2003 (bis SP1), Windows Vista (SP1), Betrieb bei neueren Service Packs ohne Gewähr
- Compiler für Kernel-Ebene: Microsoft: Visual C++/Visual Studio, CodeGear (Borland): C++Builder, Delphi Win32
Bei Fragen zur Systemunterstützung kontaktieren Sie uns bitte!