Forum: PC Hard- und Software USB Serial Port unter DOS?


von Marc X. (marc_x)


Lesenswert?

DOS bietet von Natur aus keinen USB Support, es scheint aber 
verschiedene Treiber zu geben um USB nachzurüsten, kennt jemand von euch 
solch einen Treiber der gleich Support für USB-RS232 Wandler mitbringt?

von Peter II (Gast)


Lesenswert?

Marc X. schrieb:
> DOS bietet von Natur aus keinen USB Support, es scheint aber
> verschiedene Treiber zu geben um USB nachzurüsten, kennt jemand von euch
> solch einen Treiber der gleich Support für USB-RS232 Wandler mitbringt?

ich glaube nicht das das überhaupt geht. Für Dos gibt es ja keine API 
für den zugriff auf der Serielle Schnittstelle. Das geht direkt über die 
IO-Adresse oder über Bios Funktionen.

Die Bios aufrufe könnte man zwar umbiegen, aber die meisten Programm 
verwenden direkt die IO-Adressen. Diese kann man aber nicht 
"simulieren".

von Georg (Gast)


Lesenswert?

Marc X. schrieb:
> DOS bietet von Natur aus keinen USB Support, es scheint aber
> verschiedene Treiber zu geben um USB nachzurüsten

Ich habe nur welche für Massenspeicher (Sticks, Festplatten) gesehen.

Für serielle Schnittstellen: DOS nein, DosBox unter Windows vielleicht. 
Siehe dazu:

http://www.ftdichip.com/Support/Knowledgebase/index.html?aretheremsdosdriversavailable.htm

Georg

von S. R. (svenska)


Lesenswert?

Es ist technisch kein Problem, einen USB-Stack für DOS zu entwickeln, 
der USB-Seriell-Wandler ansprechen kann. Da die Anwendung den aber 
benutzen muss, hängt es von der Anwendung ab, ob das geht.

Daher die Fragen:
- Warum DOS?
- Warum keine Emulation?
- Welche API nutzt die Anwendung?

von Uhu U. (uhu)


Lesenswert?

Peter II schrieb:
> Für Dos gibt es ja keine API für den zugriff auf der Serielle
> Schnittstelle.

Das halte ich aber für ein Gerücht. Die Geräte heißen com<n>:

Allerdings kann man auch - mangels Zugriffsschutz - auf die 
Hardwareregister zugreifen und selbst bestimmen, wie die Musik spielt...

Marc X. schrieb:
> einen Treiber der gleich Support für USB-RS232 Wandler mitbringt

Wozu das denn? Wenn RS232 rein kommt, muss man das doch nicht nach USB 
wandeln, damit der gesuchte Treiber das auf eine com-Schnittstelle 
bringt?

von Peter II (Gast)


Lesenswert?

Uhu U. schrieb:
> Das halte ich aber für ein Gerücht. Die Geräte heißen com<n>:

nicht wirklich. Bei Dos-Programm gibt anhand der COM_X nur die 
IO-Adresse aus dem Bios ausgelesen und mit dieser Basis Adresse 
gearbeitet.

Ich kenne kein Dos Programm, was ein device mit dem Name COM1 öffnet.

von S. R. (svenska)


Lesenswert?

Uhu U. schrieb:
> Das halte ich aber für ein Gerücht. Die Geräte heißen com<n>:

Das ist richtig, DOS bietet eine API für die BIOS-Treiber. Das Problem 
dabei ist, dass die BIOS-Treiber nur bis etwa 19200 bps brauchbar sind. 
Deswegen werden die, wenn überhaupt, nur als Fallback benutzt.

Es gibt allerdings auch andere APIs. Ein FOSSIL-Treiber für einen 
USB-Seriell-Wandler wäre technisch jedenfalls kein Problem, aber die 
Anwendung muss dann auch die FOSSIL-API unterstützen. Mailboxen können 
das.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

S. R. schrieb:
> Das Problem dabei ist, dass die BIOS-Treiber nur bis etwa 19200 bps
> brauchbar sind.

Was daran liegt, daß sie ohne Interrupt arbeiten, d.h. die Schnittstelle 
pollen. Was schon immer eine dumme Idee war.

von S. R. (svenska)


Lesenswert?

Außerdem sind die Treiber üblicherweise nur für den 8250 ohne FIFO, was 
das Polling noch kritischer machte.

von c-hater (Gast)


Lesenswert?

Peter II schrieb:

> ich glaube nicht das das überhaupt geht. Für Dos gibt es ja keine API
> für den zugriff auf der Serielle Schnittstelle.

Doch, die gibt es natürlich. Was glaubst denn du, wozu es die 
reservierten Dateinamen nach dem Muster COMx (x=1..9) gibt? Sprich: das 
API ist das stinknormale DOS-File-API.

> aber die meisten Programm
> verwenden direkt die IO-Adressen.

Das allerdings stimmt. Das liegt vor allem daran, dass das normale 
File-API einen von den vielfältigen Möglichkeiten einer seriellen 
Schnittstelle weitgehend abschneidet, also in schönster Reinheit zeigt, 
dass das Konzept "alles ist eine Datei" durchaus seine Grenzen hat.

Unter DOS, mit der Möglichkeit zum ungestörten Zugriff auf die 
IO-Bereiche, war dies natürlich die einfachste und effizienteste 
Möglichkeit. Deswegen hat sie sich durchgesetzt.

Wobei das Konzept "alles ist eine Datei" ja sowieso eher aus dem 
unixoiden Umfeld stammt, allerdings auch dort zu eher 
lächerlich-abstrusem Programmiergehampel führt, wenn man die 
Möglichkeiten einer seriellen Schnittstelle tatsächlich ausnutzen 
möchte. Ich möchte garnicht wissen, zu was die konsequente Anwendung 
dieser Idee erst im Bereich Netzwerk geführt hätte...

Zum Glück haben sich zumindest dafür auch im Unix-Dunstkreis die 
Berkeley-Sockets durchgesetzt. Vermutlich hatte da irgendwer die 
Weitsicht, zu erkennen, was für ein Müll herausgekommen wäre, wenn man 
auch das hochkomplexe Netzwerk-Zeugs noch in das ziemlich schwachsinnige 
"alles ist eine Datei"-Korsett gezwängt hätte...

von Icke ®. (49636b65)


Lesenswert?

Peter II schrieb:
> Für Dos gibt es ja keine API
> für den zugriff auf der Serielle Schnittstelle. Das geht direkt über die
> IO-Adresse oder über Bios Funktionen.

Du irrst. Es gibt sogar eine sehr umfangreiche DOS-API (Interrupt 21h) 
mit über 100 Funktionen für alles mögliche, u.a. den Zugriff auf die 
serielle Schnittstelle. Die Funktion 03h dient dem Empfang eines 
Zeichens, Funktion 04h sendet eines. Darüberhinaus bietet Funktion 44h 
Zugriff auf Gerätetreiber. Diese müssen in der CONFIG.SYS eingebunden 
werden (DEVICE=IRGENDEINTREIBER.SYS).
Ob sich nun jemand die Mühe macht, für aktuelle RS32/USB-Wandler 
DOS-Treiber zu schreiben, weiß ich nicht. Für USB als solches gibts aber 
welche:

http://www.dosusb.net/

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

c-hater schrieb:
> Das liegt vor allem daran, dass das normale File-API einen von den
> vielfältigen Möglichkeiten einer seriellen Schnittstelle weitgehend
> abschneidet,

Äh, nein. Das liegt vor allem daran, daß die BIOS-Routinen die 
Schnittstelle auf die ineffizienteste aller möglichen Varianten 
ansteuern.

Hätte das BIOS vernünftige Interrupttreiber enthalten, mit ausreichend 
dimensionierten Sende- und Empfangspuffern, dann hätte auch DOS um das 
"alles-ist-eine-Datei"-Konzept erweitert werden können.

Aber das ist nur eines von vielen Beispielen, wie in der PC-Entwicklung 
oft die schlechteste aller möglichen Designentscheidungen gewählt wurde 
(ein weiteres: Active-High-Interrupts, die mit Totem-Pole-Treibern 
angesteuert werden, und das in einem System, das sowieso zu wenig 
verwendbare Interruptleitungen hatte).

Ob ein "alles-ist-eine-Datei"-Konzept wirklich wünschenswert gewesen 
wäre, ist eine andere Sache, aber es wäre dem dann letztlich 
entstandenen "jeder kümmert sich selbst drum"-Gewurschtel überlegen 
gewesen. Weil beispielsweise transparent andere UART-Hardware hätte 
verwendet werden können (denn auch die 8250 ist eher ... die primitivste 
aller denkbaren UARTs, und das war sie auch schon zu PC-Zeiten).

Oh, und dann wären auch die Chancen größer gewesen, DOS-Programme, die 
serielle Schnittstellen verwenden, in Virtualisierungsumgebungen wie 
NTVDM zu verwenden, weil die nur die Devicetreiberschnittstelle hätten 
nachbilden müssen, aber nicht fünfundzwanzig verschieden schlecht 
gefrickelte "ich schreib' mir meinen UART-Treiber selbst"-Versuche 
hätten unterstützen müssen.

von viel Spass mit EDLIN (Gast)


Lesenswert?

> Ich kenne kein Dos Programm, was ein device mit dem Name COM1 öffnet.

Der vollständige Name ist 'COM1:' - inkl. Doppelpack!
Anwendungsbeispiel:
A:> COPY BRIEF.TXT COM1:

Mit
A:> CTTY CON1
lässt sich DOS von der seriellen Schnittstelle fernbedienen, z.B von 
einem Terminal oder einem anderen Rechner aus - inkontinenterweise hier 
ohne ':'

von Günter Lenz (Gast)


Lesenswert?

Peter II schrieb:
>Ich kenne kein Dos Programm, was ein device mit dem Name COM1 öffnet.

Mit QBasic geht das ganz einfach.
Und es gibt auch Terminalprogramme für DOS.

von Rolf M. (rmagnus)


Lesenswert?

Peter II schrieb:
> Die Bios aufrufe könnte man zwar umbiegen, aber die meisten Programm
> verwenden direkt die IO-Adressen. Diese kann man aber nicht
> "simulieren".

Kann man schon, wenn man den virtuellen 8086-Mode nutzt, wie es z.B. der 
EMM386 oder manche Soundblaster-Emulationen getan haben. Geht dann aber 
erst ab 80386.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Günter Lenz schrieb:
> Und es gibt auch Terminalprogramme für DOS.

Spätestens die nutzen aber nicht die lausigen "Treiber" im BIOS, sondern 
haben die komplette Schnittstellenansteuerung selbstgebastelt. Daß im 
Programm die Schnittstellen den gleichen Namen haben wie die "Devices" 
ist nur ein Entgegenkommen gegenüber dem Anwender.

von Konrad S. (maybee)


Lesenswert?

c-hater schrieb:
> Wobei das Konzept "alles ist eine Datei" ja sowieso eher aus dem
> unixoiden Umfeld stammt, allerdings auch dort zu eher
> lächerlich-abstrusem Programmiergehampel führt, wenn man die
> Möglichkeiten einer seriellen Schnittstelle tatsächlich ausnutzen
> möchte. Ich möchte garnicht wissen, zu was die konsequente Anwendung
> dieser Idee erst im Bereich Netzwerk geführt hätte...
>
> Zum Glück haben sich zumindest dafür auch im Unix-Dunstkreis die
> Berkeley-Sockets durchgesetzt. Vermutlich hatte da irgendwer die
> Weitsicht, zu erkennen, was für ein Müll herausgekommen wäre, wenn man
> auch das hochkomplexe Netzwerk-Zeugs noch in das ziemlich schwachsinnige
> "alles ist eine Datei"-Korsett gezwängt hätte...

Schlechte Nachricht für dich: Sockets sind Dateien. ;-)

von Pandur S. (jetztnicht)


Lesenswert?

Wir hatten zur DOS-Windows Umschaltzeit eine Echtzeitanwendung, die 
kommunizierte mit externer Hardware. Diesse Hardware hatte im Protokoll, 
dass die Baudrate fuer einen Daten download von 2400 auf 115k 
hochschaltet, zwischen Befehl und Antwort. Mit Dos war diese 
Umschalterei eine Registerzuweisung, dem Baudratenregister, ein paar 
Mikrosekunden. Mit dem nachfolgenden WinNT gab es diese Hardwarezugriffe 
nicht mehr. Da musste man ueber den Treiber gehen. Dort dauerte die 
Baudratenumschalterei in der Ordnung von 1.5 sekunden. Toll.

von Marc X. (marc_x)


Lesenswert?

Vielen dank für die vielen Antworten, ich denke ich werde stattdessen 
auf ein kleines Linux umsteigen

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

Es gibt ein DOS für USB-Stick
(HP USB Disk Storage Format 2.2.3)
ich meine, das stammt von Win98.
Aber das kann damit immer noch kein RS232/USB-Adapter.
Hat FreeDOS keine Möglichkeit?

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Christoph K. schrieb:
> Hat FreeDOS keine Möglichkeit?

Wie sollte es? Da --wie wir jetzt ausreichend lange ausdiskutiert 
haben-- praktisch kein DOS-Programm serielle Schnittstellen über eine 
standardisierte Treiberschnittstelle, sondern mit direkten 
Hardwarezugriffen ansteuert, kann das nicht funktionieren.

von c-hater (Gast)


Lesenswert?

Konrad S. schrieb:

> Schlechte Nachricht für dich: Sockets sind Dateien. ;-)

Nein, das sind sie nicht. Man kann sie zwar prinzipiell ähnlich wie 
solche benutzen, verliert dabei aber die Kontrolle über wesentliche 
Aspekte der Schnittstelle. Der Effekt wäre also ganz ähnlich, wie bei 
den COM-Ports, wenn man deren Möglichkeiten ausnutzen möchte. 
Programmier-Gehampel fernab jeder selbsterklärenden Logik.

Der Punkt ist: Die vollständige Kontrolle solcher Schnittstellen 
erfordert einfach mehr, als das generische File-API (und auch das 
generische Unix-Socket-API, dessen bloße Existenz allein übrigens schon 
das Konzept "alles ist eine Datei" ad absurdum führt) hergibt.

Und ohne die vollständige Kontrolle sind realen Schnittstellen 
höchstens in Sonderfällen praktisch einsetzbar. Nämlich nur genau dann, 
wenn die Defaults (mehr oder weniger) zufällig zur Anwendung passen...

Vermutlich bist du einfach so unerfahren, dass du noch niemals mit einer 
Anwendung zu tun hattest, bei der das nicht der Fall war...

Lerne einfach weiter. Früher oder später wirst du auf die Schnauze 
fallen, deine Meinung dann gezwungenermaßen revidieren und damit 
zwangsläufig irgendwann meiner Meinung sein. Ich kann das locker 
aussitzen, es tut mir nicht weh, wenn du auf die Schnauze fällst. Ich 
habe meine diesbezüglichen Schnauzenfälle schon vor vielen Jahren 
vollzogen. Böderweise gab es damals noch kein Web, wo man einfach so von 
den Erwachsenen lernen konnte...

von Eddy C. (chrisi)


Lesenswert?

Ein Fall auf die Schnauze steht Dir aber auch noch bevor: Nämlich der, 
wenn Du Deinen Hochmut verlierst.

Pikanterweise werden unter Windows Daten exakt über Dateifunktionen 
versendet und empfangen.

von S. R. (svenska)


Lesenswert?

Man muss einfach nur für jede Schnittstelle eine eigene API definieren, 
die speziell zugeschnitten ist. Jede Form von Abstraktion verschleiert 
die Eigenheiten der Software und ist prinzipbedingt niemals perfekt.

Also muss ein Programm für Netzwerkzugriff völlig anders aufgebaut sein, 
als ein programm für Dateizugriff oder ein Programm für COM-Zugriff. 
Treiber für LPT-, USB- und Netzwerkdrucker müssen vollkommen voneinander 
getrennt werden. Klassentreiber sind böse.

So funktionierte DOS viele Jahre. Warum also nicht wieder dahin zurück?

(Beitrag kann Spuren von Ironie enthalten.)

von Konrad S. (maybee)


Lesenswert?

c-hater schrieb:
> verliert dabei aber die Kontrolle über wesentliche
> Aspekte der Schnittstelle.

Wirfst du jetzt nicht die Ebenen von FILE-Pointer und File-Descriptor 
bzw. Socket durcheinander?
Auch wenn ein FILE-Pointer über den Socket drübergestülpt wird, so ist 
der Socket nicht verloren. Die vollständige Kontrolle also bleibt 
erhalten.

von Daniel A. (daniel-a)


Lesenswert?

c-hater schrieb:
> Der Punkt ist: Die vollständige Kontrolle solcher Schnittstellen
> erfordert einfach mehr, als das generische File-API (und auch das
> generische Unix-Socket-API, dessen bloße Existenz allein übrigens schon
> das Konzept "alles ist eine Datei" ad absurdum führt) hergibt.

Mir ist nicht wirklich wichtig ist, wie die Schnitstellen aufgebaut 
sind, solange dies systemweit einfach  und einheitlich anzusprechend 
sind. Dennoch kann man immer alles effizient mit files abbilden, mit 
praktisch keinem overhead. Man kann natürlich auch andere APIs 
verwenden, z.B. Libraryfunktionen, oder Restschnitstellen. Aber erstere 
sind aufwendiger anzusprechen, nämlich nur mit Hilfsfunktionen und 
Hintergrundwissen zu dessen Parametern, und Streamen von Daten ist von 
der Console nicht möglich. Das macht sich bei der Powershell schnell 
bemerkbar, wo alles erst in einen String gepackt wird, und man dann 
schnell mal OutOfMemory exceptions bekommt. Bei Restschnitstellen kann 
man mit jedem Browser ansprechen, und streamen von Daten ist möglich, 
aber upload und Download gehen nicht gleichzeitig, und man hat overhead. 
Auf Files kann man mit simplesten Dateioperationen zugreifen, man kann 
praktisch nichts falsch machen. Mein erstes Argument ist also:
1) Files sind meist die einfachsten und Effizientesten schnitstellen.

Alle diese Anwendungen haben Anwendungszwecke für welche sich gewisse 
arten von Schnitstellen besonders gut eignen. Nicht alle können gleich 
einfach angesprochen werden, und nicht alle können alles Abbilden. 
Dateien aber schon. Das wurde durch Plan 9 [1] bewiesen. Dies mag nicht 
immer die Sinvollste variante sein, aber es ist immer möglich. Unter 
linux gibt es für spezielle Dinge, für die separate Files für Overkill 
befunden wurden, ioctl aufrufe. Mein Zweites Argument ist also:
2) Alles kann durch Files abgebildet werden.

Was ich damit sagen will ist, files haben gegenüber anderen 
Schnitstellen häufig einfach viele Vorteile, selbst wenn diese nicht 
immer die Perfekte schnitstelle darstellen. Nichts kann Streams und 
sonstige Daten besser repräsentieren.

Nun zur Behauptung, Sockets wären keine Files. Nunja, eigentlich ist 
nicht alles ein file, es ist eigentlich alles ein Filedeskriptor. Was 
ist ein Filedeskriptor? Ein Tunnel, durch den Daten von A nach B 
gesendet werden. Wenn die Daten von etwas kommen, das eine änderbare 
position hat, also seekable ist, kann man das tun. Andernfalls hat man 
eine haufig eine art Stream. Was ist also ein Socket? Doch nur ein 
Stream zwischen a und b. Also ein non-seekable file. Passt doch perfekt.

So nebenbei, wisst ihr, warum TCP so designed wurde, dass bein 
Schliessen beide ein FIN senden müssen, und damit nur ihre sendende 
Verbindung schliessen? Das ist unter anderem auch damit es besser auf 
das unix file api passt. Dadurch lässt sich nämlich ein FIN vom 
Kommunikationspartner als Ende des Files (EOF) interpretieren, und man 
kann trotzdem moch daten empfangen. Natürlich hat sich MS anfangs nicht 
daran gehalten, aber das ist eine andere Geschichte.

Worauf ich eigentlich hinaus wollte ist, immer wenn man grosse 
Datenmengen oder ein Stream von Daten hat, ist ein File zur 
Repräsentation die Perfekte wahl, und eine gute File API ist zur 
Repräsentantation immer ausreichen.


[1] http://cs-exhibitions.uni-klu.ac.at/index.php?id=214

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.