Spricht eine oder mehrere Schnittstellen über DOS-Gerätenamen an
Funktioniert der Treiber auch unter Windows?
Bei Windows 3.1 bzw. 3.11 müssen Sie in der Datei SYSTEM.INI für die von
V24.SYS benutzte serielle Schnittstelle den Interrupt auf -1 setzen, z.B. bei
COM2:
COM2Irq = -1
Damit wird verhindert, dass Windows die Schnittstelle dem Treiber "wegnimmt".
Bitte beachten Sie, dass die erreichbare Baudrate unter Windows 3.1 geringer ist
als unter reinem DOS, da Windows Ports und Interrupts virtualisiert, was
zusätzliche Rechenzeit kostet. Im Prinzip können auch Windows-Programme den
Treiber benutzen, allerdings ist die Nutzung der in Windows eingebauten COMx-API
meist sinnvoller.
Unter Windows 95 sollten Sie V24.SYS nicht einsetzen. Windows 95 stellt wie Windows NT eine eigene Programmier-Schnittstelle für COM-Ports zur Verfügung, die im Microsoft System Development Kit (SDK) beschrieben ist.
Bei Windows NT können Sie V24.SYS in der für die jeweilige DOS-Box lokal gültigen Config.sys-Datei laden. Der Treiber lässt sich dann in dieser DOS-Box - jedoch nur in dieser! - von einer DOS-Applikation benutzen.
Gibt es eine Version von V.24-OEM für Windows?
Nein, und das ist auch gar nicht nötig. Bereits unter Windows 3.1 enthielt die 16-Bit-API von Windows Aufrufe für die eingebauten Treiber (VXD, COMMDRV). Informationen darüber enthält das Win3-SDK.
Unter Windows 95, 98 und NT wurden diese 16-Bit-Aufrufe durch eine neue 32-Bit-API ergänzt, die sich ähnlich wie beim Lesen oder Schreiben einer Datei mit Handles ansprechen lässt. Sie finden Informationen darüber in der Win32-API-Beschreibung von Microsoft, die bei allen üblichen Compilern mitgeliefert wird, soweit sie diese Plattform unterstützen.
V.24-OEM wurde für DOS entwickelt, weil DOS im Gegensatz zu Windows keine eingebauten gepufferten Schnittstellen-Routinen enthält: Die in DOS und BIOS vorhandenen AUX- und COM-Funktionen arbeiten rein polling-basierend ohne Interrupts und eignen sich deshalb nur zur seriellen Ausgabe, nicht zum Empfang von Daten.
Kann man V.24-OEM mit einem Protected-Mode-Programm einsetzen?
Ja, ohne Probleme. Compiler bzw. Linker, die Teile eines DOS-Anwenderprogramms im Protected Mode ausführen, schalten bei jedem Interrupt (wie er von DOS und Treibern wie V.24-OEM benutzt wird) vorübergehend in den Real Mode zurück, so dass keine Probleme entstehen.
Die Umschaltung zwischen Real Mode und Protected Mode kostet allerdings merklich CPU-Zeit, so dass in einer solchen Umgebung die erzielbaren Baudaraten oft geringer als beim reinen Real Mode sind. Dies gilt insbesondere bei der Verwendung von älteren Schnittstellen-Chips ohne FIFO-Puffer.
Was ist bei ROM-DOS zu beachten?
Das bei Steuerungs-Rechnern oft zu findende ROM-DOS ist weitgehend MS-DOS-kompatibel, einige Versionen haben aber einen Bug, der es verhindert, dass ein einzelner Treiber mehr als einen Gerätenamen bei DOS anmeldet. Obwohl V24.SYS z.B. bei COM2 die Namen "RS2" und "RS2X" anmeldet, können Sie unter einer solchen Version von ROM-DOS nur auf "RS2" und nicht auf "RS2X" zugreifen.
Da "RS2X" jedoch nur dann wirklich benötigt wird, wenn Sie einen Compiler benutzen, der einen Dateinamen nicht gleichzeitig zum Lesen und Schreiben öffnen kann, ist das Problem unter Programmiersprachen wie Pascal, C oder Assembler leicht zu umgehen: Sie brauchen nur "RS2" als Read/Write-Handle zu öffnen, "RS2X" wird überhaupt nicht benötigt.
Was tun, wenn der Compiler weder IOCTL-Befehle noch Int-21-Aufrufe ermöglicht?
Wenn vor dem Auslesen von Zeichen aus dem Empfangspuffer nicht über IOCTL-Funktionen ermittelt werden kann, ob überhaupt etwas empfangen wurde (z.B. in Visual Basic), ist die einfachste Lösung, den Treiber beim Aufruf so zu konfigurieren, dass er sofort mit einem Timeout-Zeichen zurückkehrt, wenn man versucht, etwas zu lesen, ohne dass etwas empfangen wurde. Das Timeout kann auf Null gestellt werden, und als Timeout-Zeichen wählt man eines, was im normalen Text nicht vorkommen wird (z.B. hex 03 = EOT).
Das Setzen der Schnittstellen-Parameter ist ebenfalls möglich, ohne dafür IOCTL-Funktionen zu benutzen. Dazu braucht man nur gleich nach dem Öffnen des Ports, bevor Nutzdaten gesendet werden, die gewünschten IOCTL-Parameter (siehe V.24-OEM-Handbuch) in spitze Anführungszeichen einzuschließen und an den Treiber auszugeben, in Basic beispielsweise so:
Print#1,"«I5C»";
In den DOS-Codepages 437 und 850 sind die dezimalen Codes für die spitzen Anführungszeichen 174 und 175.
Empfangene oder gesendete Zeichen werden erst ab einer bestimmten Anzahl übergeben. Was ist die Ursache?
Viele Compiler benutzen einen internen Zwischenpuffer beim Lesen und Schreiben von Dateien und leider auch Gerätetreibern.
Lösung für C und C++: Setzen Sie mit der Funktion setbuf (f, NULL) die interne Pufferlänge des Compilers für das Treiber-File f auf den Wert Null. Ein Beispiel dafür finden Sie im Programm CMTERM.C auf der V.24-OEM-Diskette.
Lösung für Turbo-Pascal ab 4.0: Setzen Sie den compiler-internen File-Buffer (also NICHT den Empfangspuffer des Schnittstellen-Treibers) auf eine Länge von 1, indem Sie eine Variable Buffer als Typ CHAR definieren und dann die Compiler-Prozedur SetTextBuf (Comnr, Buffer) nach Assign und vor Reset aufrufen. (Bei der früheren Turbo-Pascal-Version 3.0 war das nicht erforderlich.)
Bei GWBasic, QBasic und Quickbasic von Microsoft tritt das Problem nicht auf. Bei Turbo-Basic tritt es auf, der Compiler versucht schon bei OPEN 128 Zeichen zu lesen und hängt dadurch scheinbar; es gibt aber mangels einer Anweisung zum Setzen der compiler-internen Pufferlänge leider keine Möglichkeit, es zu umgehen. Sie sollten deshalb Turbo-Basic nicht für Applikationen benutzen, die auf V.24-OEM zugreifen.
Der Empfang eines Ctrl-Z-Zeichens (hex 1A) macht Probleme.
Sie müssen dem Betriebssystem bei Gerätetreibern erst explizit mitteilen, dass es Steuerzeichen wie EOF = Ctrl-Z transparent durchreichen soll.
Lösung für C und C++: Wenn f das von fopen stammende File ist, genügt die folgende Anweisungsfolge, um DOS für dieses File binär-transparent zu machen.
regs.x.ax=0x4401; regs.x.bx=fileno(f); regs.x.dx=0xe0; intdos(®s,®s);
Lösung für Turbo-Pascal: Wenn "comnr" die von Assign stammende Variable ist, muss daraus zunächst das DOS-Handle ermittelt werden. Dazu dient die folgende Funktion getbx:
function getbx (var handle: text): integer;
var ad, sg: integer;
begin
ad:=ofs (handle); sg:=seg (handle);
getbx:=mem [sg:ad] + 256*mem; [sg:ad+1];
end;
Dann lässt sich DOS unter Pascal wie folgt für das File-Handle transparent
machen:
regs.bx:=getbx(comnr); regs.ax:=$4401; regs.dx:=$00e0; msdos(regs);
Bei GWBasic, QBasic und Quickbasic von Microsoft sind diese Schritte nicht erforderlich, da diese Interpreter bzw. Compiler den nötigen DOS-Aufruf automatisch durchführen.
Können mehrere COM-Ports denselben IRQ benutzen?
Grundsätzlich unterstützt der Treiber V24.SYS ein IRQ-Sharing mehrerer COM-Ports: Wenn ein bestimmter Interrupt auftritt, werden alle zugehörigen Port-Adressen abgesucht, um herauszufinden, welche Schnittstelle ihn auslöste. Das Hauptproblem ist allerdings, dass das von den meisten Adapterkarten aus Hardware-Gründen nicht unterstützt wird. Prinzipiell ist eine gemeinsame Nutzung eines Interrupts beim ISA-Bus ohnehin nur innerhalb einer Karte möglich, nie zwischen mehreren, da sich andernfalls die Interrupt-Ausgänge der einzelnen Karten gegenseitig kurzschließen.
Um ein IRQ-Sharing zu ermöglichen, müssen die Interrupt-Ausgänge der UART-Bausteine (8250, 16450, 16550) logisch "Oder"-verknüpft sein. Das ist aber leider bei den meisten Karten nicht der Fall. Wenn Sie eine Vierfach- oder Achtfach-COM-Karte besorgen, lassen Sie sich vom Hersteller vorher versichern, dass die Karte schaltungstechnisch wirklich für ein IRQ-Sharing ausgelegt wurde. (Wegen der oft nur sehr kurzlebigen Typenbezeichnungen solcher Karten kann Ihnen Shamrock Software leider keine Auskunft geben, ob eine bestimmte Karte für ein IRQ-Sharing geeignet ist.)