V.24-OEM ======== Schnittstellen-Treiberprogramm fr IBM-kompatible MS-DOS-Computer V.24-OEM ist Freeware. Sie finden Hotline-Tips zu diesem Programm im mitgelieferten Expertensystem XPERT sowie im Internet unter www.shamrock.de. Shamrock bietet fr Freeware-Produkte keine kostenlose telefonische Hotline-Untersttzung an und garantiert nicht die Eignung fr bestimmte Anwendungsf„lle. Dieses Handbuch benutzt den IBM-OEM-Zeichensatz. Umlaute werden in einem Windows-Editor deshalb nicht korrekt dargestellt. V.24-OEM ist ein DOS-Treiber und eignet sich nicht fr Windows 95, 98 und NT, da diese Versionen ihre eigenen Schnittstellen- Treiber mitbringen. (c) Shamrock Software GmbH, 85238 Petershausen, www.shamrock.de Eigenschaften von V.24-OEM V.24-OEM ist ein RAM-resident ladbares Treiberprogramm fr IBM- kompatible PCs und ATs, das bis zu zehn serielle Schnittstellen bedienen kann. Empfangsseitig ist ein Puffer vorhanden (voreingestellt 2048 Byte, maximal 60000), damit Zeichen auch im Hintergrund empfangen werden k”nnen, wenn das aufrufende Anwenderprogramm gerade besch„ftigt ist. Sendeseitig kann ein Puffer von bis zu 255 Zeichen konfiguriert werden. Das Treiberprogramm l„át sich von allen Programmiersprachen mit den logischen Ger„tenamen RS1, RS2, RS3 usw. ansprechen. Dabei lassen sich auch die V.24-Steuerleitungen DTR und RTS setzen, andere Leitungen wie CTS, DSR, CD und RI sowie Parity-Fehler oder Puffer- šberlauf lassen sich ohne direkte Hardware-Adressierung abfragen. Baudrate und šbertragungsparameter lassen sich fr alle Schnittstellen getrennt jederzeit neu setzen. Durch das Konzept, den Treiber als echten MS-DOS-Ger„tetreiber auszufhren, wird die Ein- und Ausgabe von h”heren Programmiersprachen sehr einfach und erfordert keine Assembler- Unterprogrammaufrufe. Vielmehr werden die normalen DOS-Funktionen zur Ein- und Ausgabe genutzt. Wenn der Treiber fr COM3 oder COM4 geladen wird, tr„gt er automatisch die entsprechenden Adressen in die vom BIOS dafr vorgesehenen Speicherzellen ab 0040:0004H ein, so daá COM3 und COM4 auch vom DOS erkannt werden k”nnen. Schnittstellen mit dem Chiptyp 16550, die einen Hardware-FIFO enthalten, werden automatisch erkannt und untersttzt. Das Archiv enth„lt folgende Dateien: README Erg„nzungen und Nachtr„ge zu diesem Handbuch (verwenden Sie COPY README PRN zum Drucken) CONFIG.SYS Beispiel fr die Installation von V24.SYS V24.SYS Treiberprogramm, in CONFIG.SYS konfigurierbar CMTERM.ASM Assembler-Beispielprogramm (Terminalprogramm) CMTERM.COM Lauff„higer Assembler-Objektcode v.CMTERM.ASM CMTERM.C C-Beispiel-Software (Terminalprogramm) CMTERM.BAS GW-Basic-Beispielprogramm (Terminalprogramm) CMTERM.PAS Beispielprogramm fr Turbo-Pascal ab Vers.4.0 WINTERM.MAK Make-Datei fr Visal Basic (fr Windows 3.x) WINTERM.FRM Form-Datei fr Visual Basic (zu WINTERM.MAK) V24_GFA.LST Beispielprogramm fr GFA-Basic (Terminalprg.) COMTEST.EXE Diagnoseprogramm fr Schnittstellen-Hardware XPERT.COM Expertensystem-Programm (Start mit XPERT) XPERT.TXT Hilfsdatei, wird von XPERT.COM nachgeladen V24.HTM Support-Tipps - h„ufige Fragen und Antworten Hardware-Voraussetzungen Im IBM-PC bzw. AT sind nur die Ports COM1 (03F8, IRQ4) und COM2 (02F8, IRQ3) standardisiert, alle weiteren COM-Ports jedoch nicht. Sowohl die Basisadressen als auch die Interrupts der verwendeten Schnittstellen-Hardware lassen sich beim Laden des Treibers deshalb beliebig konfigurieren. Dafr gelten allerdings einige Einschr„nkungen: Es ist nicht zul„ssig, zwei Schnittstellen mit derselben Adresse zu betreiben. Wenn der Rechner bereits eine serielle Schnittstelle besitzt, darf COM1 nicht gleichzeitig auf einer Karte adressiert werden. ! Es ist durchaus m”glich, daá mehrere Ports einen gemeinsamen Interrupt (z.B. IRQ3) verwenden. Allerdings funktioniert das nur dann, wenn alle diese Schnittstellen auf der gleichen Karte sitzen und die Karte vom Hersteller ausdrcklich als intern interrupt- sharing-f„hig deklariert ist. Der PC- bzw. AT-Bus gestattet aus Hardware-Grnden ein Interrupt-Sharing mehrerer Karten nicht. Karten fr COM3 und h”her, die sich nur fr IRQ 4+3 konfigurieren lassen, sind fr alle interrupt-gepufferten Programme (und damit auch fr V.24-OEM) unbrauchbar, da IRQ4+3 bereits von COM1 und COM2 belegt sind. Ferner ist die erreichbare Baudrate umso geringer, je mehr Schnittstellen sich einen Interrupt teilen. Dies gilt insbesondere fr Microsoft-Windows-Anwendungen, da hierbei die vom System pro Sekunde verarbeitbare Zahl von Interrupts erheblich geringer als unter MS-DOS ist. Sollten Sie nicht sicher sein, ob Ihre Schnittstelle(n) korrekt installiert sind, so starten Sie bitte das Programm COMTEST auf der V.24-OEM-Diskette. Es sucht den I/O-Adressenbereich des PC nach seriellen Schnittstellen ab und berprft einzeln die Zuordnung der Interrupts 2 bis 7 (andere IRQs, z. B. 10 oder 11, werden von COMTEST nicht untersttzt, ebenso wird ein Interrupt-Sharing nicht geprft). Besonders ntzlich ist, daá COMTEST auch in der Lage ist, festzustellen, welche Schnittstellen bzw. Interrupts von welchem residenten Programm benutzt werden, z.B. von einem Maustreiber. Wenn Sie COMTEST ohne Option starten, sucht es nur an den Standard- Adressen von COM1 bis COM4. Mit der Option /E wird der gesamte Adreáraum von 100 bis 3FF durchsucht, wobei auf manchen PCs Probleme auftreten k”nnten, da zum Teil allein schon das Lesen von einer Adresse zum Absturz fhren kann. Eine groáe Hilfe bei der Fehlersuche kann das mitgelieferte Programm XPERT sein. Dabei handelt es sich um ein kleines Expertensystem, das Ihnen Fragen stellt, die Sie durch Drcken bestimmter Funktionstasten beantworten sollten. Sie erhalten dann eine Liste m”glicher Problem-Ursachen. Sollten Sie das Problem nicht selbst beheben k”nnen, so kontaktieren Sie bitte den Hardware-H„ndler, von dem Sie die jeweilige Schnittstellen-Karte bzw. den Computer bezogen haben. Laden mit CONFIG.SYS Die V.24-OEM-Routinen k”nnen mit Hilfe der von MS-DOS beim Einschalten des Rechners automatisch geladenen Datei CONFIG.SYS als residente Betriebssystem-Erweiterung eingebunden werden. Es ist zul„ssig, ein und dasselbe Treiberprogramm V24.SYS mehrmals nacheinander zu laden, um mehrere Schnittstellen gleichzeitig bedienen zu k”nnen. Wenn CONFIG.SYS die Zeile DEVICE=V24.SYS (mit Return abgeschlossen) enth„lt und die Datei V24.SYS sich im Hauptverzeichnis des Boot-Laufwerks befindet, wird der Treiber mit seinen Standard-Einstellungen geladen. Diese sind: Schnittstelle: COM1 Baudrate: 4800 Bd Datenformat: 8 Datenbits, keine Parit„t, 1 Stopbit XON/XOFF-Handshake: Ausgeschaltet RTS/CTS-Handshake: Ausgeschaltet Timeout: Ausgeschaltet Selbstverst„ndlich kann man hinter DEVICE= auch einen Pfadnamen angeben, z.B. DEVICE=C:\DOS\V24.SYS, wenn sich der Treiber in einem Unterverzeichnis der Festplatte befindet. Groá- oder Kleinschreibung spielt keine Rolle, weil MS-DOS die Zeilen in CONFIG.SYS automatisch in Groáschreibung umwandelt. Hinter dem Dateinamen V24.SYS (gefolgt von mindestens einem Leerzeichen) k”nnen zahlreiche Parameter angegeben werden, um das Programm anwendungsspezifisch zu konfigurieren. Ein einfaches Beispiel: DEVICE=V24.SYS C3 A02E8 I2 B2 PH Diese Zeile konfiguriert das Treiberprogramm fr die dritte serielle Schnittstelle bei der Adresse 02E8 (hex) und dem Interrupt 2 (Parameter I2) mit 300 Baud (B2) sowie acht Datenbits mit ungerader Parit„t und einem Stopbit (PH). Die Leerr„ume zwischen den Parametern sind optional. Insgesamt untersttzt V.24-OEM folgende Parameter (in alphabetischer Reihenfolge): Axxxx Schnittstellen-Adresse = xxxx (4stellig hex). Wenn diese Angabe fehlt, wird bei COM1 03F8 und bei COM2 02F8 angenommen. Bei COM3 und h”her ist die Angabe von Axxxx stets erforderlich. Bx Es wird die Baudrate x voreingestellt, wobei x eine Ziffer oder ein Zeichen mit folgender Bedeutung ist: 0 75 4 1200 8 19200 1 110 5 2400 9 38400 2 300 6 4800 : 57600 3 600 7 9600 ; 115200 Wenn der Parameter B fehlt, wird eine Geschwindigkeit von 4800 Baud angenommen (entsprechend B6). Cx Der Treiber wird fr die x-te serielle Schnittstelle geladen, wobei fr x eine Ziffer von 1 bis 9, 0 sowie A-Z eingesetzt werden kann. Ohne C wird COM1 angenommen. H Es wird ein RTS-/CTS-Hardware-Handshake aktiviert: Der Treiber wartet mit dem Senden, bis CTS=1 ist, und legt RTS auf 0, solange der interne Puffer voll ist. Ixx Es wird der Interrupt xx verwendet, wobei xx eine ein- oder zweistellige Dezimalzahl von 1 bis 15 sein kann. Diese Nummer muá mit der auf der Schnittstellenkarte eingestellten Interrupt bereinstimmen. O Mit dem Buchstaben O als Parameter wird dem Treiber mitgeteilt, daá beim ™ffnen der Schnittstelle aus dem Anwenderprogramm die internen Sende- und Empfangspuffer nicht gel”scht werden sollen. Ohne den Parameter O werden bei jedem ™ffnen der Schnittstelle die internen Puffer gel”scht. Px Es wird das Datenformat x voreingestellt. Der Buchstabe x hat die folgende Bedeutung: A 8N2 D 7N1 G 8E1 B 8N1 E 7E1 H 8O1 C 7N2 F 7O1 Hierbei bedeutet zum Beispiel "8N1" acht Datenbits, keine Parit„t (N=no=keine, E=even=gerade, O=odd=ungerade) und ein Stopbit. Diese Konfiguration (entsprechend dem Parameter PB) ist auch voreingestellt, wenn der Parameter P nicht verwendet wird. Rxxx Eine nach R angegebene Dezimalzahl xxx (2 bis 60000) stellt die gewnschte Gr”áe des Empfangspuffers ein. Ohne R werden 2048 Byte als Puffergr”áe angenommen. Sxxx Eine nach S angegebene Dezimalzahl xxx (2 bis 255) stellt die gewnschte Gr”áe des Sendepuffers ein. Wenn der Parameter S fehlt, werden 2 Byte als Puffergr”áe angenommen. Bitte beachten Sie, daá ein groáer Sendepuffer das Treiberprogramm bei eingeschaltetem XON/XOFF- oder RTS/CTS-Handshake erst verz”gert auf Handshake- Signale reagieren l„át. Tx:yyy Hiermit kann ein Timeout programmiert werden, das immer dann wirksam wird, wenn Sie versuchen, Zeichen zu empfangen, ohne daá etwas empfangen wurde. Die Dezimalzahl x (1 bis 255) gibt die Anzahl der Sekunden an, die der Treiber maximal wartet, w„hrend yyy fr eine bis zu 15 Zeichen lange Zeichenfolge steht, die Ihrem Programm bei einem Timeout im Empfangspuffer bergeben wird. Beachten Sie bitte, daá DOS in der Datei CONFIG.SYS Kleinbuchstaben in Groáschrift umwandelt und auch keine Steuerzeichen erlaubt. Um trotzdem alle Zeichen programmieren zu k”nnen (auáer 00 hex), k”nnen Sie beliebige zweistellige Hex-Codes nach einem Backslash angeben, zum Beispiel \1A fr ein CTRL-Z-Steuerzeichen. Der Parameter T sollte stets als letzter in einer CONFIG.SYS-Zeile stehen, da nachfolgende Parameter sonst als Bestandteil des Timeout-Strings aufgefaát wrden. Uxx,yy Bei Empfang des Zeichencodes hex xx wird der User-Interrupt mit der Nummer hex yy ausgel”st. xx und yy mssen stets zweistellig angegeben werden. V Wenn nach der Baudraten-Einstellung der Buchstabe V folgt, wird unabh„ngig von der mit B gew„hlten Empfangs-Baudrate mit 75 Bd gesendet. Beispiel: DEVICE=V24.SYS B4V initialisiert den Treiber so, daá entsprechend der V.23-Norm mit 1200 Bd empfangen und mit 75 Bd gesendet wird, z.B. fr ein Bildschirmtext-Modem DBT-03. (Die umgekehrte Kombination ist aus Hardware-Grnden leider nicht m”glich.) X Mit dem Parameter X wird sende- und empfangsseitig das XON/XOFF- Software-Handshake aktiviert. Ohne diesen Parameter werden die Zeichen XON und XOFF nicht ausgewertet, sondern transparent bergeben. Z Dient bei RS485-Schnittstellen zur passenden Steuerung des RTS- Ausgangs: Der RS-485-Sendeteil wird aktiviert, solange Zeichen gesendet werden. Wenn Sie beispielsweise die Schnittstelle COM3 bei Adresse 02E8 und mit dem Interrupt IRQ2 so betreiben wollen, daá nach zehn Sekunden Wartezeit (wenn keine Zeichen empfangen werden) Ihrem Anwenderprogramm das EOF-Steuerzeichen 1AH bergeben wird, ist folgende Zeile in CONFIG.SYS notwendig: DEVICE=V24.SYS C3 A02E8 I2 T10:\1A Alle genannten Parameter mit Ausnahme von C (Schnittstellen-Nummer), A (Adresse) und I (Interrupt) lassen sich auch vom Anwenderprogramm aus setzen und mssen deshalb nicht unbedingt in der Datei CONFIG.SYS stehen (siehe "IOCTL-Funktionen"). Wirklich notwendig sind nur folgende Parameter: þ C (Schnittstellen-Nr.) auáer bei COM1, þ A (Adresse) auáer bei COM1 und COM2, þ I (Interrupt) auáer bei COM1 und COM2. Falls in der Datei CONFIG.SYS hinter dem Dateinamen des Treibers (V24.SYS) falsche Parameter stehen, gibt das Programm beim Laden eine Fehlermeldung aus. Es wird dann zwar in den Speicher geladen, sollte aber nicht verwendet werden, da nur ein Teil der angegebenen Parameter ausgewertet werden konnte. Nach dieser Installation ist die erste Schnittstelle unter den "Datei"-Namen RS1 und RS1X ansprechbar, die zweite mit RS2 und RS2X und so weiter. Da jeder Schnittstelle zwei gleichwertige Namen zugeordnet sind, kann man einen Namen zum ™ffnen einer Datei zum Lesen und den anderen zum ™ffnen einer zweiten Datei zum Schreiben zuweisen, ohne daá z.B. in Basic eine Fehlermeldung wie "File Already Open" auftreten wrde. Nach dem Laden sind die DTR- und RTS-Leitungen der Schnittstelle aktiv (d. h. auf +12 V), falls eine DOS-Version vor 3.0 verwendet wird. Bei sp„teren DOS-Versionen werden RTS und DTR erst bei einer Open-Anweisung aktiviert (bei DOS 2.11 wird Open intern ignoriert!). Ein- und Ausgabe via DOS Da V.24-OEM ein echter, mit Namen ansprechbarer Ger„tetreiber ist, kann man einfache DOS-Anweisungen verwenden, um Daten ber eine serielle Schnittstelle ein- und auszugeben. Die wesentlichen Unterschiede zur "normalen" DOS-Schnittstelle COM1 bzw. COM2 sind: þ Die Ger„tenamen lauten RS1 und RS2 statt COM1 und COM2. Die DOS-Namen COM1 und COM2 sind wie bisher benutzbar. þ Der Treiber bleibt bei nicht angeschlossenen Hardware- Steuerleitungen (CTS, DSR usw.) nicht h„ngen. þ Die Ein- und Ausgabe erfolgt gepuffert, so daá auch bei h”heren Baudraten keine Zeichen verloren gehen. þ Das XON/XOFF-Software-Protokoll wird untersttzt, wenn der Treiber entsprechend konfiguiert wird. þ Es sind auch h”here Baudraten als 9600 Bd (DOS) m”glich. Um z.B. eine Datei ABC.TXT ber die erste Schnittstelle mit Hilfe des Treibers auszugeben, gibt man in DOS folgendes ein: C>COPY ABC.TXT RS1 Um diese Datei auf einem zweiten PC, der ber ein Nullmodem-Kabel mit dem ersten verbunden ist, wiederum zu speichern, máte man vorher (!) folgendes eingeben: C>COPY RS1 ABC.TXT Dieses Beispiel setzt allerdings voraus, daá die bertragene Datei ABC.TXT am Ende ein CTRL-Z-Steuerzeichen (hex 1A, dezimal 26) enth„lt, damit der empfangende PC weiá, wann sie aufh”rt. Ohne dieses CTRL-Z wrde MS-DOS ewig auf weitere Zeichen warten und ist in diesem Zustand auch mit CTRL-C nicht unterbrechbar. Eine L”sung ist das Programmieren von CTRL-Z als Timeout-Zeichen (z.B. DEVICE = V24.SYS T5:\1A in der Datei CONFIG.SYS). Selbstverst„ndlich sind auch andere DOS-Befehle auf den Treiber anwendbar, zum Beispiel TYPE RS1, um empfangene Daten bis zum Auftreten eines CTRL-Z-Steuerzeichens auf dem Bildschirm anzuzeigen. Diese Art der Treiber-Verwendung ist allerdings alles andere als komfortabel. Im n„chsten Kapitel wird deshalb auf das Ansprechen der Schnittstellen aus Anwenderprogrammen eingegangen. Damit ist es auch m”glich, zahlreiche Parameter wie Baudrate, Datenformat und so weiter auch im laufenden Betrieb jederzeit zu „ndern. Programmieren mit V.24-OEM V.24-OEM eignet sich fr alle g„ngigen Programmiersprachen. Obwohl z.B. GW-Basic bereits eine gepufferte Schnittstellen-Behandlung realisiert, bietet demgegenber V.24-OEM auch hier wesentliche Vorteile: + Es sind mehr als nur zwei Schnittstellen m”glich. + Bei Empfangsfehlern steigt das Programm nicht aus. + Die RTS- und DTR-Leitungen lassen sich definiert steuern. + Die CTS-, DSR-, CD- und RI-Leitungen sind einzeln prfbar. + Der Sonderstatus "Break" ist abfragbar und auch erzeugbar. + Die erreichbare Geschwindigkeit ist erheblich gr”áer. + Alle šbertragungsparameter lassen sich jederzeit „ndern. + Jeder Treiber besitzt einen einstellbaren Empfangspuffer. Das Ansprechen des V.24-OEM-Treibers ist in Basic ebenso einfach wie die Verwendung der "eingebauten" COM1- und COM2-Schnittstellen- Routinen, n„mlich mit OPEN und CLOSE. Wie bei diesen ist auch eine Abfrage der Zeichenzahl im Empfangspuffer m”glich; dazu sp„ter. Grunds„tzlich ist es m”glich, schon mit dem folgenden Primitiv-Basic- Programm Daten auf dem Bildschirm anzuzeigen, die ber die erste serielle Schnittstelle empfangen werden: 10 OPEN "I", 1, "RS1" 'Schnittstelle ”ffnen 20 PRINT INPUT$(1,1); 'Empfangene Zeichen anzeigen 30 GOTO 20 'Wieder von vorn In anderen Programmiersprachen wie Pascal, Modula oder C ist grunds„tzlich jede Ein- und Ausgabe ber den Treiber ebenso einfach wie das Lesen und Schreiben einer Datei. Wenn Sie erste Versuche mit V.24-OEM unternehmen, dann ist es eine praktische Sache, Ihr Programm zuerst so zu schreiben, daá es Zeichen nicht von einer Schnittstelle, sondern aus einer sequentiellen Textdatei liest. Wenn das einmal funktioniert, ersetzen Sie den Namen der Textdatei einfach durch RS1 (oder eine andere Schnittstelle), und schon kommen die Zeichen vom seriellen Port. IOCTL-Funktionen MS-DOS stellt mit IOCTL- (I/O-Control-) Funktionen ein brauchbares Mittel zur Steuerung von Treiberprogrammen zur Verfgung. Beispielsweise bergibt die Anweisung IOCTL#1,E$ von Basic aus den Steuerungs-String E$ an das Treiberprogramm mit der Filenummer 1. Einer IOCTL-Anweisung muá stets ein OPEN-Kommando vorausgegangen sein. Wenn ein und dieselbe Schnittstelle gleichzeitig mit zwei Filenummern (fr Ein- und Ausgabe) ge”ffnet wird, ist es gleichgltig, auf welchen der beiden Kan„le die IOCTL-Anweisungen angewendet werden; sie gelten stets fr beide. Andere Programmiersprachen, z.B. das verbreitete Turbo-Pascal, besitzen keine IOCTL-Anweisungen. Die mitgelieferte Diskette enth„lt jedoch zwei Prozeduren, die als Ersatz fr die Basic-Anweisungen IOCTL# und IOCTL$ verwendet werden k”nnen. In Assembler oder C kann der INT-21H-Aufruf AH=44H verwendet werden, um IOCTL-Strings zu bergeben. Alternativ kann unmittelbar nach dem ™ffnen des Treibers (und nur dann!) auch ein IOCTL-String ber den normalen Datenkanal gesendet werden, wenn er in die Sonderzeichen-Codes 174 und 175 eingeschlossen wird; in Basic z.B. so: OPEN"O",2,"RS1X" PRINT #2, CHR$(174); "I5C"; CHR$(175); Der V.24-OEM-Treiber versteht eine Reihe von IOCTL-Kommandos. Sie bestehen aus je einem Zeichen und drfen in beliebiger Reihenfolge bergeben werden (Ausnahme "T"). Andere IOCTL-Zeichen als die im folgenden genannten werden vom Treiberprogramm ignoriert. Sie werden feststellen, daá die meisten IOCTL-Anweisungen jenen Parametern „hneln, die man auch in CONFIG.SYS hinter dem Treibernamen angeben kann. Die Parameterfolge "6BR" (4800 Bd, 8N1) wird beim Start automatisch ausgefhrt; bei DOS-Versionen vor 3.0 werden zus„tzlich die Leitungen DTR und RTS aktiviert. Wenn diese Parameter nicht ver„ndert werden mssen, sind keine IOCTL-Anweisungen im Programm erforderlich (auáer "I" bei MS-DOS 2.11). Baudrate und šbertragungsparameter k”nnen nach einer OPEN-Anweisung beliebig oft mit IOCTL-Kommandos ver„ndert werden. Die OPEN-Anweisung selbst ver„ndert Baudrate und sonstige Parameter nicht. Einstellen der Baudrate: 0...9, :, ;, V 0 = 75 Bd 4 = 1200 Bd 8 = 19200 Bd V = senden 1 = 110 Bd 5 = 2400 Bd 9 = 38400 Bd mit 75 Bd 2 = 300 Bd 6 = 4800 Bd : = 57600 Bd (z.B.4V= 3 = 600 Bd 7 = 9600 Bd ; = 115200 Bd 1200/75) Wenn der Parameter V zum Senden mit 75 Bd verwendet wird, muá er stets nach der gewnschten Empfangs-Baudrate stehen. Die voreingestellte Baudrate ist 4800 Bd. Einstellen der šbertragungsparameter A 8 Datenbits, keine Parit„t, 2 Stopbits B 8 Datenbits, keine Parit„t, 1 Stopbit C 7 Datenbits, keine Parit„t, 2 Stopbits D 7 Datenbits, keine Parit„t, 1 Stopbit E 7 Datenbits, gerade Parit„t, 1 Stopbit F 7 Datenbits, ungerade Parit„t, 1 Stopbit G 8 Datenbits, gerade Parit„t, 1 Stopbit H 8 Datenbits, ungerade Parit„t, 1 Stopbit * Erzwingt zwei Stopbits nach A-H (z.B. "E*" fr 7 Datenbits, gerade Parit„t, 2 Stopbits) (Beim Laden ist "B" voreingestellt.) Sonstige IOCTL-Kommandos + Leitungen DTR und RTS = 1 setzen (+12 V) - Leitungen DTR und RTS = 0 setzen (-12 V) I Treiber initial. (nur bei MS-DOS 2.xx n”tig) M DTR=0 und RTS=1 setzen N DTR=1 und RTS=0 setzen (z.B. fr NET.24) P Sorgt fr das L”schen des Puffers bei OPEN Q Verhindert das L”schen des Puffers bei OPEN R Empfangspuffer l”schen T Timeout-String setzen: "T"+CHR$(sec.)+TS$ X XON/XOFF-Protokoll einschalten (s.u.) Y XON/XOFF-Protokoll ausschalten < Break-Status ein (TxD-Leitung = 0 setzen) > Break-Status aus (Normalzustand, TxD = 1) Beim Laden sind normalerweise "P" und "Y" voreingestellt. MS-DOS 2.11 ignoriert intern einen z.B. von Pascal, C oder Basic veranlaáten OPEN-Befehl. Deshalb ist "I" n”tig, um sicherzustellen, daá vor einer Ein- und Ausgabe die Interrupt-Vektoren und Puffer- Zeiger korrekt gesetzt werden. "I" l”scht gleichzeitig den Empfangspuffer. Bei MS-DOS-Versionen ab 3.0 wird die richtige Initialisierung aber durch eine OPEN-Anweisung automatisch gew„hrleistet. Weder "I" noch OPEN ver„ndern jedoch die eingestellte Baudrate oder die brigen Parameter. Ein OPEN-Kommando (z.B. in Basic) setzt die RTS- und DTR-Leitungen automatisch auf 1, das entspricht einem elektrischen Pegel von +12 V. Der IOCTL-Befehl I hat dieselbe Wirkung. DTR und RTS sind jedoch auch schon nach dem Laden des Treiberprogramms sofort auf 1 gesetzt, damit der Treiber auch von der MS-DOS-Kommandoebene aus eingesetzt werden kann. DTR und RTS k”nnen (stets gleichzeitig) entweder mit dem IOCTL-Kommando "-" oder mit einer CLOSE-Anweisung zurckgesetzt werden. In GW-Basic ist zum Beispiel folgende Anweisungsfolge n”tig, um die Schnittstelle COM1 zur Eingabe der Filenummer 1 und zur Ausgabe der Filenummer 2 zuzuweisen: OPEN"I",1,"RS1" : OPEN"O",2,"RS1X" Dabei sind zun„chst die Baudrate 4800 Bd und die Parameter 8N1 (acht Datenbits, keine Parit„t, ein Stopbit) voreingestellt. (Den Versuch, fr Ein- und Ausgabe jedesmal den Namen "RS1" zu verwenden, wrde Basic mit der Fehlermeldung "File Already open" quittieren, deshalb wird zur Ausgabe der gleichwertige Name RS1X verwendet. Es sollte brigens auch vermieden werden, daá Disk-Files den gleichen Namen, mit oder ohne Extension, z.B. RS1.TXT, verwenden.) Die folgende Anweisung initialisiert den Treiber (I) und setzt die šbertragungsparameter auf 2400 Bd und 7N2: IOCTL#2,"I5C" Zur Datenausgabe lassen sich dann in Basic die Anweisungen PRINT#2 und PRINT USING#2 einsetzen. Zum Empfang von Daten eignen sich die Anweisungen INPUT$(n,1) mit n=zu lesende Zeichenzahl, INPUT#1 sowie LINE INPUT#1 (siehe Basic-Handbuch). Timeout-Programmierung Der IOCTL-Befehl "T" veranlaát das Treiber-Programm, einen von Ihnen definierbaren Timeout-String ber den Empfangspuffer zu bergeben, wenn eine bestimmte Zeitdauer vergebens auf den Empfang von Zeichen gewartet wird. Das ist zum Beispiel dann sinnvoll, wenn die verwendete Programmiersprache die Abfrage von IOCTL-Strings nicht erlaubt und somit nicht feststellen kann, ob berhaupt Zeichen empfangen wurden. Im IOCTL-String gibt das erste Byte nach dem T bin„r die Wartezeit in Sekunden an (maximal 255), die dann folgenden Bytes enthalten den bei einem Timeout zu bergebenden String, der bis zu 15 Zeichen lang sein darf, jedoch kein Null-Byte (00H) enthalten darf. Angenommen, es soll nach fnf Sekunden die Zeichenfolge "Timeout" und ein Return-Zeichen bergeben werden, ist folgender IOCTL-Befehl in Basic erforderlich: IOCTL#2,"T"+CHR$(5)+"Timeout"+CHR$(13) Durch das Auftreten eines Timeouts wird gleichzeitig ein eventueller XOFF-Status auf XON rckgesetzt, damit das System nicht "h„ngt" (siehe Abschnitt "XON/XOFF-Protokoll"). Mit der Anweisung IOCTL#2,"T"+CHR$(0) kann die Timeout-Funktion bei Bedarf jederzeit wieder ausgeschaltet werden. In Pascal kann die in CMTERM.PAS bzw. CMTERM4.PAS enthaltene Prozedur IOCTLOUT zur Programmierung des Timeouts verwendet werden. Beachten Sie bitte, daá die Sekundenanzahl innerhalb des Strings als CHR() bergeben wird, d.h. als bin„res Byte. Handshake-Verfahren XON/XOFF Beim Start ist der Treiber fr alle Codes transparent, d.h. alle Zeichencodes werden unver„ndert durchgelassen. Mit dem IOCTL- Kommando "X" l„át sich ein XON-XOFF-Protokoll einschalten, mit dem man verhindern kann, daá eine Seite die Zeichen schneller sendet, als die andere sie verarbeiten kann. Bei eingeschaltetem XON/XOFF-Protokoll sind die beiden Zeichen XON (CTRL-Q, Code dezimal 17 bzw. hex 11) und XOFF (CTRL-S, dezimal 19 bzw. hex 13) natrlich nicht bertragbar. Eine vollst„ndig transparente šbertragung ist deshalb nur bei ausgeschaltetem XON/XOFF-Protokoll m”glich. Es wird auch empfohlen, das Senden von CTRL-S und CTRL-Q aus dem Anwenderprogramm heraus zu vermeiden, wenn das XON/XOFF-Protokoll eingeschaltet ist, damit keine Konflikte mit der Protokollsteuerung auftreten. Wird ein XOFF-Zeichen empfangen, so wird mit dem Fllen des Sendepuffers solange gewartet, bis ein XON-Zeichen empfangen wird. (Hierbei gibt es kein Timeout, d.h. der Rechner kann beliebig lange warten.) Beachten Sie bitte, daá der Treiber bei einem groáen Sendepuffer u.U. wesentlich langsamer auf ein empfangenes XOFF- Zeichen reagieren kann als in der Standard-Einstellung (Sendepuffergr”áe 2 Zeichen). Durch Abfrage von Bit 0 im dritten Byte des IOCTL$-Strings kann festgestellt werden, ob der Treiber gerade im XOFF-Status ist, so daá im Moment kein Zeichen gesendet werden kann (siehe n„chstes Kapitel). Ein Anwenderprogramm kann dadurch verhindern, daá es "h„ngt", nachdem die Gegenstation ein XOFF-Zeichen gesendet hat. Wenn der Empfangspuffer (normalerweise 2048 Zeichen) halb voll wird, sendet der Treiber ein XOFF-Zeichen, um die Gegenstation anzuhalten. Sobald das Anwenderprogramm den Empfangspuffer soweit geleert hat, daá er nur noch zu einem Viertel gefllt ist, sendet der Treiber ein XON-Zeichen. Das Senden eines XOFF-Zeichens (sobald der Empfangspuffer halb voll wird) erfolgt im Hintergrund, d.h. innerhalb einer Interrupt- Routine, und funktioniert daher auch, wenn das aufrufende Anwenderprogramm gerade anderweitig besch„ftigt ist. Wenn es jedoch gerade selbst Strings ohne Pause zwischen den einzelnen Zeichen sendet, wird kein XOFF-Zeichen ausgegeben, um Konflikte mit dem gesendeten String zu vermeiden. Hardware-Handshake Der Treiber kann ein RTS-/CTS-Hardware-Handshake automatisch durchfhren, wenn er beim Laden mit der Option H passend konfiguriert wurde. Das Puffer-Verhalten entspricht dem bei XON/XOFF. Das Hardware-Handshake ist nicht per IOCTL-Anweisung ein- oder ausschaltbar. Die Option H sollte nicht bei RS485-Karten eingesetzt werden; fr diese ist die Option Z vorgesehen. Ebenso sollte nie XON/XOFF (Option X) und RTS/CTS (Option H) gleichzeitig Zeit aktiviert werden - das w„re auch wenig sinnvoll. Abfrage von Statusangaben Die IOCTL-Parameter-šbergabe funktioniert auch in der anderen Richtung, also vom Treiberprogramm zum aufrufenden Anwenderprogramm, in Basic z.B. so: E$=IOCTL$(1) Diese Anweisung holt vom V.24-OEM-Treiber einen stets vier Byte langen String, der folgendermaáen aufgebaut ist: 1. und 2. Byte: Zahl der Zeichen im Puffer (bin„r, low/high): L=ASC(E$)+256*ASC(MID$(E$,2,1)) oder, etwas schneller: L=CVI(LEFT$(E$,2)) 3. Byte: Status der Schnittstelle (bin„r): Bit 0 = Sender im XOFF-Status (wenn Bit=1) Bit 1 = Parity-Fehler aufgetreten Bit 2 = Framing-Fehler aufgetreten Bit 3 = Break empfangen (d.h. RxD = 0) Bit 4 = CTS (Clear To Send) Bit 5 = DSR (Data Set Ready) Bit 6 = RI (Ring Indicator) Bit 7 = CD (Carrier Detect) Das zur Abfrage (UND-Verknpfung) erforder- liche "Masken-Byte" ist je nach Bit: Bit-Nr. 0 1 2 3 4 5 6 7 UND-Maske 1 2 4 8 16 32 64 128 Zum Beispiel ist eine CTS-Abfrage so m”glich: IF(ASC(MID$(E$,3,1)))AND 16 THEN PRINT"CTS=1" Wenn Bit 0 = 1 ist (XOFF-Status), k”nnen kei- ne Zeichen gesendet werden, bis die Gegensta- tion ein XON-Zeichen sendet oder das XON-/ XOFF-Protokoll ausgeschaltet wird. Ein Test dieser Bedingung ist wie folgt m”glich: IF(ASC(MID$(E$,3,1)))AND 1 THEN PRINT"XOFF!" 4. Byte: Empfangs-Status des Treiberprogramms (ASCII): " " (Leerraum, dez. Code 32) = kein Fehler, "E" = Parity-/Framing-Fehler oder Break "B" = Empfangspuffer-šberlauf Beispiel zum allgemeinen Fehlertest: IF RIGHT$(E$,1)<>" "THEN PRINT"Fehler!!!" Das Lesen des Fehlercodes ist nur einmal m”glich, da jede IOCTL- Leseanweisung den Fehlerstatus automatisch wieder l”scht. Das gilt auch fr die Bits 1 bis 3 im IOCTL-Byte 3. Nach einem Pufferberlauf (Fehlerstatus B) befinden sich jeweils die letzten 2047 Bytes noch im Puffer (bei einer Pufferl„nge von 2048 Zeichen). Der Fehlerstatus E gibt an, daá seit dem letzten Lesen des IOCTL-Strings ein Parit„ts- oder Framing-Error auftrat; es ist jedoch nachtr„glich nicht m”glich, noch festzustellen, welches empfangene Zeichen hierfr die Ursache war. Beispielprogramme Die mitgelieferte Diskette enth„lt Beispielprogramme in GW-Basic, Turbo-Pascal, Microsoft-C und Assembler. Alle drei Programme (CMTERM.BAS, CMTERM.PAS, CMTERM.ASM) eignen sich als einfache Terminal-Emulationen. Steuerzeichen wie z.B. Backspace werden allerdings nicht untersttzt. Voreingestellt ist jeweils die erste serielle Schnittstelle. Verbindet man an ihr die Pins 2 und 3 miteinander, so mssen die an der Tastatur eingegebenen Zeichen sofort wieder auf dem Bildschirm sichtbar werden. GW-Basic: CMTERM.BAS Das folgende Listing zeigt die Basic-Version des Terminalprogramms. (Sie kann auch mit Quickbasic compiliert werden.) 100 ' --- BEISPIELPROGRAMM FšR V.24-OEM [SHAMROCK/FE/88-92] --- 105 ' 110 ' --- Schnittstelle fr I/O ”ffnen (hier fr RS1=COM1) --- 115 ' Parameter zun„chst: 2400 Bd, 8N1 120 OPEN"I",1,"RS1":OPEN"O",2,"RS1X":IOCTL#1,"I5B-" ' DTR noch=0 125 CLS:PRINT"TERMINALPROGRAMM (F10=Ende)":PRINT:KEY 10,"" 130 ' 135 ' --- Parameter evtl. „ndern --- 140 INPUT"1=110,2=300,3=600,4=1200,5=2400,6=4800,7=9600 Bd";E$ 145 IF E$>"0"AND E$<="7"THEN IOCTL#1,E$ 150 INPUT"A=8N2,B=8N1,C=7N2,D=7N1,E=7E1,F=7O1,G=8E1,H=8O1";E$ 155 IF E$>"A"AND E$<="h"THEN IOCTL#1,E$ 160 IOCTL#1,"+":PRINT"Terminal bereit" ' DTR+RTS=1 165 ' 170 ' --- Programm-Hauptschleife --- 175 E$=IOCTL$(1):L=ASC(E$)+256*ASC(MID$(E$,2,1))' Zeichenzahl 180 I$=RIGHT$(E$,1):IF I$="B"THEN PRINT:PRINT"Pufferberlauf!" 185 IF I$<>"E"THEN 210 ELSE E=ASC(MID$(E$,3,1)):BEEP:PRINT 190 IF E AND 2 THEN PRINT"Parity-Fehler!" 195 IF E AND 4 THEN PRINT"Framing-Fehler!" 200 IF E AND 8 THEN PRINT"Break empfangen!" 205 IF L>255 THEN L=255 'Max. Stringl„nge = 255 Zeichen 210 IF L>0 THEN PRINT INPUT$(L,1); ' Pufferinhalt anzeigen 215 E$=INKEY$:IF E$=""THEN 175 ' Taste gedrckt? 220 IF ASC(E$)=0 THEN IF RIGHT$(E$,1)="D"THEN 230 ELSE 175 'F10? 225 PRINT#2,E$;:GOTO 175 ' Zeichen senden 230 CLOSE 1:CLOSE 2:PRINT:PRINT"Programm beendet":END Hinweise zu QBasic, QuickBasic und Visual Basic Der Quickbasic- und Visual-Basic-Compiler sowie der QBasic- Interpreter von Microsoft k”nnen keine CTRL-Z-Steuerzeichen ausgeben, wenn man den Ausgabekanal mit OPEN ... FOR OUTPUT ”ffnet. Das Problem tritt nicht auf, wenn der Kanal mit OPEN ... FOR BINARY ge”ffnet wird; dann kann sogar der gleiche Kanal zum Schreiben und Lesen verwendet werden. Allerdings eignen sich dafr nicht mehr INPUT#, INPUT$ und PRINT, sondern GET# und PUT# (siehe Compiler- Handbuch). - WINTERM ist ein einfaches Terminal-Programm fr Visual Basic unter Windows. Laden Sie den Treiber dafr mit der Option T0:\1A. Dadurch wird bei leerem Empfangspuffer ohne Wartezeit ein CTRL-Z-Zeichen zurckgeliefert. Das ist n”tig, weil Visual Basic keine IOCTL-Anweisungen zur Statusabfrage kennt. Turbo-Pascal: CMTERM.PAS Das folgende Beispielprogramm ist in Turbo-Pascal 4.0 geschrieben. Der "etwas" gr”áere Umfang der Pascal-Version rhrt vor allem daher, daá die in GW-Basic vorhandenen IOCTL-Anweisungen erst als neue Prozeduren definiert werden mssen. Auch dieses Programm ist zun„chst fr die erste serielle Schnittstelle ausgelegt, da es RS1 und RS1X als Namen fr die Treiberprogramme verwendet. Eine Besonderheit ist der MS-DOS-Aufruf mit AX=$4401, der dazu dient, das Betriebssystem in den "raw mode" zu versetzen. Andernfalls w„re MS-DOS 3.x nicht in der Lage, ber ein CTRL-Z- Zeichen hinaus von einem logischen Ger„t zu lesen. (Dieses Problem tritt in MS-DOS 2.11 nicht auf, ebenso nicht in GWBASIC unter MS-DOS 3.11, weil Basic diesen MS-DOS-Aufruf intern automatisch durchfhrt.) Wir empfehlen Ihnen, Programme, die zur Weitergabe an Kunden bestimmt sind, grunds„tzlich so zu schreiben, daá sie unabh„ngig von der MS-DOS-Versionsnummer funktionieren. Verwenden Sie deshalb stets die IOCTL-Anweisung "I" nach einer OPEN-Anweisung, und bernehmen Sie den MS-DOS-Aufruf $4401 auch dann, wenn Ihr Kunde (noch) mit MS- DOS 2.11 arbeitet. { TERMINAL PROGRAM FOR V.24-OEM WITH TURBO PASCAL 4/5/6 } { (C) SHAMROCK SOFTWARE/FE 1988-90 } program CMTERM; uses dos, crt; type iotyp = string[4]; {format of ioctl string} var comnr, comxnr: text; {file handles for RS232} i,l: integer; iostat: iotyp; var regs: registers; ch,buffer: char; leave: boolean; {V-} {this switch allows different length of ioctl string} function getbx(var handle:text):integer; {GET MS-DOS HANDLE } var ad,sg:integer; begin ad:=ofs(handle); sg:=seg(handle); {address of block} getbx:=mem[sg:ad]+256*mem[sg:ad+1]; {handle=1st 2 bytes} end; procedure ioctlin(var handle:text; var io:iotyp); begin { GET IOCTL STRING } regs.bx:=getbx(handle); {get handle into bx} regs.ax:=$4402; {function 44H, read} regs.dx:=ofs(io)+1; regs.ds:=seg(io); msdos(regs); {call INT 21H} end; {status in iostat} procedure ioctlout (var handle:text; var io:iotyp); begin { SEND IOCTL STRING } regs.bx:=getbx(handle); {get handle into bx } regs.ax:=$4403; regs.cx:=length(io); {funct. 44H,03=write} regs.dx:=ofs(io)+1; regs.ds:=seg(io); {address of string} msdos(regs); {call INT 21H} end; begin { PROGRAM BODY } assign(comnr,'RS1'); {sets turbo buffer..} settextbuf(comnr,buffer); {..to only one byte } reset(comnr); {open RS1 for read } assign(comxnr,'RS1X'); rewrite(comxnr); {open RS1X for write} regs.bx:=getbx(comnr); regs.ax:=$4401; regs.dx:=$00e0; {ignore CTRL-Z..} msdos(regs); {..when in DOS >2.X!} regs.bx:=getbx(comxnr); regs.ax:=$4401; regs.dx:=$00e0; msdos(regs); writeln('Terminal, ESC=End'); leave:=false; iostat:='I6B+'; ioctlout(comnr,iostat); {Init driver} while not leave do begin {TERMINAL MAIN LOOP} ioctlin(comnr,iostat); {get driver status} l:=ord(iostat[1])+256*ord(iostat[2]); {char.count i.buff.} if l>0 then begin read(comnr,ch); {read character} if ch<>chr(10) then write(ch); {display if not LF} if ch=chr(13) then write(chr(10)); {add LF if CR} end {if}; if KeyPressed then begin ch:=readkey; {get key if pressed} if ch=chr(27) then leave:=true; {ESC = end program} write(comxnr,ch); {send character} end {if}; end {while}; end {program}. Microsoft-C, Turbo-C: CMTERM.C Das folgende Programmbeispiel zeigt, wie man IOCTL- und Daten- Strings in C von und zum Treiber bergeben kann. Es realisiert ein einfaches Terminal-Programm, das ber die Tastatur eingegebene Zeichen sendet und umgekehrt empfangene Zeichen auf dem Bildschirm darstellt. Die Struktur ioc dient zur Aufnahme des vom Treiber bergebenen Status, der u.a. die Zahl der im Empfangspuffer befindlichen Zeichen enth„lt. Der Microsoft-C-Compiler bietet keine IOCTL-Funktionen an. Sie lassen sich aber leicht implementieren: a) Abholen des Treiberstatus (4 Byte) regs.h.ax=0x4402; regs.x.bx=fileno(f);regs.x.cx = 4; regs.x.dx=Offset eines 4-Byte-Arrays; regs.x.ds=Seg.d.Arrays; intdosx (®s,®s,&segregs); b) Setzen von Parametern im Treiber regs.h.ax=0x4403; regs.x.bx=fileno(f); regs.x.cx=Stringl„nge; regs.x.dx=Offset des Param.-Strings; regs.x.ds=Seg.Par.-Str.; intdosx (®s,®s,&segregs); /* Einfaches Terminal-Programm in Borland- bzw. Turbo-C */ #include #include #include FILE *f; int run = 1; char *ini; char ch; struct ioc { unsigned int cnt; char port; char status; }; struct ioc iocin; /* Struktur fr IOCTL-Status */ main() { printf("\nTerminal-Programm fr V.24-OEM (ESC = Ende)\n\n"); f=fopen("RS2","r+b"); /* Hier RS2 fr COM2 */ if (f==NULL) { printf("Treiber nicht geladen!\n"); return 1; } setbuf(f,NULL); /* Stream nicht puffern! */ ini = "6B"; /* Baudrate+Datenformat */ ioctl (fileno(f),3,ini,strlen(ini)); while (run) /* Terminalschleife... */ { ioctl(fileno(f),2,&iocin,4); if (iocin.status != 32) /* Status=OK? */ printf("\nStatus=%c\n",iocin.status); while (iocin.cnt) /* Was empfangen? */ { fread(&ch,1,1,f); /* Ja, lesen+anzeigen */ printf("%c",ch); iocin.cnt--; }; if (kbhit()) /* Taste? */ { ch = getch(); if (ch==27) run=0 ; /* ESC=Programmende */ else fwrite(&ch,1,1,f); /* Tastendruck senden */ } } fclose (f); printf("\nProgramm beendet.\n"); return 0; } Sonstige Hinweise zu h”heren Programmiersprachen þ In C gibt es Compiler-abh„ngige Probleme bei der Behandlung von Line-Feed- und Return-Steuerzeichen, da C teilweise Line Feed statt Return als Zeilen-Ende annimmt. Dieses Problem hat aber berhaupt nichts mit dem V.24-Treiber zu tun, sondern ausschlieálich mit der jeweiligen C-Implementation (beachten Sie dazu bitte die Hinweise im Handbuch Ihres Compilers). þ Die EOF-Funktion in C, Basic oder Pascal gibt nicht an, ob sich Zeichen im Empfangspuffer befinden, sondern nur, ob ein CTRL-Z- Steuerzeichen (Dezimalcode 26) empfangen wurde. Die Zahl der Zeichen im Empfangspuffer ist nur mit Hilfe einer IOCTL-Anweisung ermittelbar. þ Viele C-, Pascal- und Cobol-Compiler sind so voreingestellt, daá sie nicht nur fr Dateien, sondern auch fr Ger„tetreiber unsinnigerweise zus„tzlich einen internen Puffer ”ffnen. Wenn man ihn nicht mit "setbuf" (in C), "SetTextBuf" (Pascal) oder "Rewind" (Cobol) deaktivert, fhrt er zu erheblichen Problemen. þ Die Basic-Anweisung ON COM GOSUB ist mit V.24-OEM nicht verwendbar, da sie keine echte Interrupt-Anweisung ist, sondern lediglich im Polling-Modus einen internen Puffer abfragt, der von den Basic-typischen OPEN"COM"-Routinen verwaltet wird. þ Unter Windows ist erfahrungsgem„á selbst auf schnellen Rechnern eine Baudrate ab 9600 Bd ohne Zeichenverluste nicht sicher m”glich; „hnliches gilt fr OS/2. Bei gleichzeitiger Verwendung mehrerer Schnittstellen liegt die Grenze noch erheblich niedriger. Der Grund ist die komplizierte Interrupt-Behandlung im Protected Mode der 80X86-Prozessoren. Fr geschwindigkeitskritische Anwendungen wird deshalb dringend von Windows oder OS/2 abgeraten; diese Systeme wurden von Anfang an nie fr Echtzeitanwendungen konzipiert. þ GFA-Basic-Versionen vor 4.43 "verschlucken" aufgrund eines compiler-internen Fehlers manchmal Zeichen. Verwenden Sie bitte ausschlieálich sp„tere Compiler-Versionen. - Ein Beispiel mit GFA- Basic finden Sie auf der Diskette; wegen des Fehlens von IOCTL- Anweisungen wird die gesamte Ein-/Ausgabe dabei ber eigene Prozeduren mit Hilfe des DOS-Interrupts INT 21H abgewickelt. þ Turbo-Basic (alias Power Basic) hat in allen uns bekannten Versionen den Fehler, daá es schon bei OPEN versucht, 128 Bytes einzulesen, und ist deshalb mit Ger„tetreibern generell nicht verwendbar - also auch nicht mit V.24-OEM. þ Vermeiden Sie bei hohen Baudraten m”glichst eine zeichenweise Verarbeitung. Die šbergabe ganzer Strings funktioniert erheblich schneller. Assembler: CMTERM.ASM Die Assembler-Version des einfachen Terminalprogramms verwendet Unterprogramme zur IOCTL-Ein- und Ausgabe. Der Aufruf INT 21H mit AX=4401H schaltet wie im Turbo-Pascal-Beispiel das Betriebssystem in den "raw mode" (Transparent-Modus). Der Einfachkeit halber wird angenommen, daá IOCTL-Kommandos immer genau vier Zeichen lang sind. Im Gegensatz zu Basic und Pascal ist es hier nicht n”tig, getrennte Open-Anweisungen zum Lesen und Schreiben zu verwenden. ;Einfaches Terminalprogramm ;fr COM1 (300 Baud, 8N1, Vollduplex) code segment assume cs:code,ds:code org 100h start: mov ax,3d02h ;R/W-Open mov dx,offset rsname int 21h jc openerr ;Fehler?! mov bx,ax ;BX=Handle mov ax,4401h mov dx,00e0h ;CTRL-Z int 21h ;ignorieren call ioctlout ;Baudrate usw. mov dx,offset hello mov ah,9 ;Text ausgeben int 21h receive:call ioctlin ;Zch.im Puffer? cmp word ptr ioctl,0 jz send ;nein call getch ;ja,holen call display ;und anzeigen send: mov ah,1 ;Taste gedr.? int 16h ;(Z148 braucht sti ;STI nach INT 16H) jz receive ;nein mov ah,0 int 16h ;ja,lesen sti cmp al,0 ;Sondertaste? je receive ;ja,ignorieren cmp al,27 ;ESC? je leave ;ja,Ende! call sendch ;nein,senden jmp short receive openerr:mov dx,offset opentxt mov ah,9 ;Fehlermeldung int 21h int 20h ;zu MS-DOS leave: mov ah,3eh ;Close RS232 int 21h ;mit BX=Handle int 20h ;zu MS-DOS ;---------------------------------- ;Unterprogramm:1 Zeichen empfangen getch: mov cx,1 ;1 Zeichen mov dx,offset dta mov ah,3fh ;Read int 21h mov al,dta ;AL=Zeichen ret ;Unterprogramm: 1 Zeichen senden sendch: mov cx,1 ;1 Zeichen mov dta,al mov dx,offset dta mov ah,40h ;Write int 21h ret ;Unterprogramm: IOCTL lesen ioctlin:mov ax,4402h jmp short ioctlf ;Unterprogramm: IOCTL schreiben ioctlout:mov ax,4403h ;BX=Handle! ioctlf: mov cx,4 ;4 Byte mov dx,offset ioctl int 21h ret ;Unterprogramm: 1 Zeichen anzeigen display:cmp al,10 ;LF? je disp2 ;ignorieren! cmp al,13 ;CR? jne disp1 call disp1 ;ja,erst CR mov al,10 ;dann LF disp1: push bx mov bl,7 ;Farbe=7 mov ah,0eh int 10h ;ROM-BIOS pop bx disp2: ret opentxt db 7,'Treiber geladen?$' hello db 'SHAMROCK SOFTWARE - V.24-OEM' db 13,10,'TERMINAL-PROGRAMM ' db '(ESC=Ende)',13,10,'$' rsname db 'RS1',0 ;hier fr COM1 ioctl db 'I2B+' ;immer 4 Bytes! dta equ this byte ;Transfer-Adresse code ends end start User-Interrupt Fr spezielle Anwendungen ist es m”glich, immer dann, wenn ein bestimmtes Zeichen empfangen wird, einen frei definierbaren Interrupt auszul”sen, um eine anwendungsspezifische Routine auszufhren. Maximal kann dies allerdings 18,2mal je Sekunde erfolgen, da dieser User-Interrupt aus der internen Systemzeit- Interrupt-Routine aufgerufen wird (der serielle Empfangs-Interrupt selbst w„re allzu zeitkritisch). Der gewnschte Zeichencode und die Interrupt-Nummer k”nnen jeweils zweistellig hexadezimal beim Laden des Treibers in CONFIG.SYS angegeben werden. Ein Beispiel: DEVICE = V24.SYS U1A,7B Hier wird immer bei Empfang des Zeichens 1A (Ctrl-Z) der Interrupt 7B aufgerufen. Der Zeichencode FF ist reserviert und wird nicht akzeptiert, ebenso sind Interrupts unterhalb hex 44 unzul„ssig, da sie vom System belegt sind (wir empfehlen Interrupts von 7B bis 7E, diese sind gew”hnlich unbenutzt). Der so konfigurierte Interrupt zeigt nach dem Laden zun„chst auf eine IRET-Anweisung innerhalb des Treibers. Ein Anwenderprogramm kann den Interrupt-Vektor sp„ter auf eine eigene Routine umlenken. Am Ende des Anwenderprogramms sollte der vorherige Inhalt des Interrupt-Vektors unbedingt wiederhergestellt werden (auch bei unvorhergesehenen Programm-Abbrchen z.B. nach Laufzeit-Fehlern!). Der Interrupt-Routine im Anwenderprogramm werden in vier Registern folgende Informationen bergeben: AX = aktueller Stand des Puffer-Schreibzeigers BX = aktueller Stand des Puffer-Lesezeigers CX = konfigurierte L„nge des Empfangspuffers DS:DX = absolute Anfangsadresse des Empfangspuffers Die Interrupt-Routine muá den Lesezeiger BX entsprechend korrigiert zurckgeben, wenn sie Zeichen aus dem Puffer gelesen hat. Um festzustellen, wieviele Zeichen (n) sich gerade im Empfangspuffer befinden, ist folgender Algorithmus n”tig (hier programmiersprachen- neutral formuliert): n := AX - BX; IF n < 0 THEN n := n + CX Um das jeweils n„chste Zeichen c aus dem Empfangspuffer zu lesen, eignet sich folgender Algorithmus: c := DS:[BX+DX]; BX := BX + 1; IF BX = CX THEN BX := 0 Hierbei wird c aus der Speicherstelle [BX+DX] im Segment DS gelesen. Die Interrupt-Routine darf nie l„nger als 50 ms dauern. Sie darf die Segment-Register sowie SI, DI und BP nicht ver„ndern. Der Aufruf von DOS- und BIOS-Funktionen aus der Interrupt-Routine ist nicht zul„ssig. Wir empfehlen, die Routine in Assembler zu formulieren. Sie muá mit einem IRET-Befehl enden (also nicht mit RET oder RETF). Bei Miáachtung dieser Punkte wird sich der Rechner unweigerlich aufh„ngen. Die V.24-Schnittstelle Das V.24-OEM-Treiberprogramm l„át prinzipiell eine 3-Draht- Verbindung an der V.24-Schnittstelle zu (GND = Bezugspotential = Masse, TXD = Sendedaten, RXD = Empfangsdaten). Alle brigen Leitungen dienen ausschlieálich Steuerzwecken und k”nnen bei Bedarf abgefragt (DSR, CTS, CD, RI) oder gesetzt werden (DTR, RTS). Die Pinbelegung der hier erw„hnten Leitungen geht aus folgender šbersicht hervor (sie entspricht der Lage der Pins an einer V.24- Buchse). Pinbelegung o 1 o 14 o 2 TXD (Sendedaten) o o 3 RXD (Empfangsdaten) o o 4 RTS (Request To Send, zum Modem) o o 5 CTS (Clear To Send, vom Modem) o o 6 DSR (Data Set Ready, vom Modem) o DTR (Data Terminal o 7 GND (Ground=Masse, vom/zum Modem) Ready,zum Modem)o 20 o 8 CD (Carrier Detect, vom Modem) o o RI (Ring Indi- o 22 cator,vom Modem) o o o o o o 25 o 13 Pin 1 ist im jeweiligen Ger„t meist mit dem Geh„use (Schutzkontakt!) verbunden. Es ist normalerweise aber nicht erforderlich, auch ihn zu verdrahten, da Pin 7 als Bezugspotential ausreicht. Theoretisch erlaubt die CCITT-V.24-Norm eine noch gr”áere Zahl von Steuerleitungen, beispielsweise sieht sie auch Taktleitungen fr synchrone šbertragung (z.B. X.25-Protokoll) vor. Die in IBM- kompatiblen PCs und ATs verwendeten V.24-Interfaces untersttzen jedoch nur die oben genannten Leitungen und sind auch nicht fr synchrone šbertragung mit externem Takt geeignet. Manche Schnittstellen-Karten, insbesondere solche fr COM2 und COM4 sowie Multifunktionskarten, besitzen keinen normgerechte DB25- Stecker als Ausgang, sondern eine neunpolige DB9-Buchse. Das entspricht zwar nicht der CCITT-Norm, reicht aber prinzipiell aus, da auch eine neunpolige Buchse alle erforderlichen Leitungen zur Verfgung stellt. Wenn man ein Adapter-Kabel herstellen m”chte, das am einen Ende einen neunpoligen Stecker (z.B. fr einen IBM-AT) und am anderen Ende einen 25poligen besitzt (z.B. fr ein Modem), dann sind folgende Verbindungen n”tig: Pin Name der Pin 9polig Leitung 25polig 1 CD 8 2 RXD 3 3 TXD 2 4 DTR 20 5 GND 7 6 DSR 6 7 RTS 4 8 CTS 5 9 RI 22 Bedeutung der Leitungen GND Gemeinsames Bezugspotential fr alle Signale (0 V). TXD Sendedaten; Ruhelage -12 V = log. 1. Jedem Zeichen ist ein Startbit (log.0 = + 12 V) voran- und 1...2 Stopbits (log.1) nachgestellt. Die sieben oder acht Datenbits werden mit dem niederwertigsten Bit (Bit 0) zuerst gesendet. TXD Empfangsdaten (Datenformat natrlich wie TXD). Bei den folgenden Leitungen entspricht "wahr" (log. 1) einem elektrischen Pegel von + 12 V und "nicht wahr" (0) einem Pegel von - 12 V: DTR Computer sendebereit. RTS Computer empfangsbereit (Halbuplex-Modem: Senden). CTS Modem sendebereit. DSR Modem empfangsbereit bzw.an die Leitung geschaltet. CD Modem stellt Tr„ger-Ton der Gegenstation fest. RI Das Telefon klingelt, ein Anruf liegt vor. (Insbesondere bei Hayes-kompatiblen Modems werden die Steuerleitungen nicht immer korrekt nach CCITT-Vorschrift untersttzt, insbesondere CD, CTS und DTR.) M”chte man zwei Computer miteinander verbinden, so ist ein sogenanntes Nullmodem n”tig - das ist schlicht ein Kabel, bei dem einige Leitungen miteinander vertauscht sind: Computer A Computer B Name DB25 DB25 Name GND 7 ÄÄÄ 7 GND TXD 2 ÄÄÄ 3 RXD RXD 3 ÄÄÄ 2 TXD RTS 4 ÄÄÄ 5+8 CTS+CD CTS+CD 5+8 ÄÄÄ 4 RTS DSR 6 ÄÄÄ 20 DTR DTR 20 ÄÄÄ 6 DSR Zur Simulation des Zustands "Anruf liegt vor" (RI=1) kann RI (Pin 22) kurzzeitig, z.B. ber eine Taste, mit DTR des anderen Rechners bzw. mit DSR desselben Rechners (Pin 6) verbunden werden. Verwendung von Steuerzeichen Die V.24-OEM-Treiberprogramme sind bei ausgeschaltetem XON/XOFF- Protokoll vollst„ndig transparent, fangen also keine Steuerzeichen ab. Das aufrufende Anwenderprogramm kann dadurch auf bestimmte Steuerzeichen bei Bedarf individuell reagieren. Ist die šbertragung von Bin„rdateien vorgesehen, so sollte dies mit einer Wortl„nge von 8 Datenbits und ohne das Abfangen von Steuerzeichen geschehen. (Das Datex-P-Netz der deutschen Bundespost akzeptiert ber PADs nur 7-Bit- Zeichen, ein Bin„r-Transfer ist deshalb nicht m”glich.) Bei Textdateien, die selbst keine Steuerzeichen (auáer CR und LF) enthalten, ist eine Steuerung der šbertragung mit Hilfe des XON/XOFF- Protokolls m”glich, das beim Treiberprogramm mit dem IOCTL-Kommando X ein- und mit Y ausgeschaltet werden kann: Zeichen Dez.Code Bedeutung XOFF 19 (CTRL-S) šbertragung anhalten XON 17 (CTRL-Q) šbertragung weiterlaufen lassen IBM- und ISO-Zeichencode Die International Standards Organisation (ISO) hat fr den nationalen Datenverkehr in Deutschland einen Code genormt, der auch mit 7 Bits die Darstellung deutscher Umlaute gestattet und identisch mit dem entsprechenden DIN-Vorschlag ist. Gegebenenfalls muá das Anwenderprogramm also eine Zeichensatz-Anpassung nach folgender Tabelle durchfhren (dez.): Zeichen IBM-PC ISO Zeichen IBM-PC ISO Ž 142 91 „ 132 123 ™ 153 92 ” 148 124 š 154 93 129 125  21 64 á 225 126 Folgende Zeichen stehen im ISO- bzw. DIN-Code wegen der šberdeckung mit Umlautcodes nicht zur Verfgung: @ [ \ ] { | } ÿ7E (und natrlich auch alle IBM-Grafikzeichen!). (c) Shamrock Software GmbH