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?
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".
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
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?
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?
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.
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.
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.
Außerdem sind die Treiber üblicherweise nur für den 8250 ohne FIFO, was das Polling noch kritischer machte.
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...
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/
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.
> 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 ':'
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.
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.
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.
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. ;-)
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.
Vielen dank für die vielen Antworten, ich denke ich werde stattdessen auf ein kleines Linux umsteigen
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?
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.
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...
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.
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.)
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.