Portzugriff auf serielle Schnittstelle funzt nicht unter XP

[devidespe]

Hallo,

ich muss die serielle Schnittstelle direkt ansprechen und wollte daher - wie damals unter DOS üblich - direkt auf die entsprechenden Register zugreifen. Hierzu gehören bspw. das Basisregister (bei COM1 z.B. auf 3F8h), das Line-Control-Register (Basisadresse+3) und das Line-Status-Register (Basisadresse+5). Technische Wege zum direkten Portzugriff existieren (mit einem Treiber sowie Administartorrechten), nur habe ich das Problem, dass jedweder Lesevorgang dieser Register ein $FF zurückliefert. Und genau da stecke ich fest, denn beim portbasierten Zugriff auf die parallele Schnittstelle klappt wieder alles.

Hier im Forum ist ja oft von Komponentensammlungen die Rede, und ich glaube, mit der Windows API gibts auch noch diverse Möglichkeiten. Ich muss die Ports aber direkt ansprechen, weil eine DOS-Lösung zu Windows portiert werden muss. Und ich habe angenommen, dass der DOS-Quellcode direkt in Windows übernommen werden kann (mit entsprechenden Anpassungen bspw. beim Portzugriff).

Kennt vielleicht jemand das gleiche Problem oder existiert da eine Sperre in XP, die einen direkten seriellen Portzugriff verhindert ? Parallel funktioniert wie gesagt. Bin über jeden Vorschlag dankbar...

Grüße,

Devid

[Muetze1]

Nö, eigentlich nicht. Die Frage ist nur - warum überhaupt noch direkt drauf zugreifen, wo doch die WinAPI alles liefert? Vor allem bei dem COM Port sehe ich keinen Grund den Quellcode nicht auf die WinAPI zu portieren, schliesslich soll der DOS Code ja in der Windowswelt ankommen.

[devidespe]

Der direkte Zugriff sollte deswegen verwendet werden, weil die Routinen bereits in DOS vorliegen und dort auch funktionieren. Der schnellste Weg (ohne sich erst mit der Windows API befassen zu müssen) ist die direkte Portierung, und für den parallelen Anschluss hat das auch geklappt.

Nun liefert jeder Leseversuch eines seriellen Ports den Wert $FF zurück, und mich beschleicht der Verdacht, dass Windows hier etwas blockt.

Hätte ja sein können, dass dieses Problem nur bei mir auftritt, oder jemand anderes das gleiche Problem hatte.

[Chemiker]

Hallo devidespe,

ich kann Muetze1 nur zustimmen.
Unter DOS konnte man den Datentransfer nur synchron ausführen. Das bedeutet z.B. ein Aufruf zum Lesen blockiert das Programm bis die Daten gelesen waren. Unter Windows ist es möglich das lesen von Daten in einem Thread zu erledigen, währende das Programm schon weitere Aktionen ausführen kann. Windows ist in der Lage einen asynchronen Datentransfer hinzubekommen. Es ist Ereignisgesteuert das bedeutet, dass das Lesen im Hintergrund erfolgt und nach Abschluss des Lesevorgangs das Programm benachrichtigt wird das der Befehl abgeschlossen ist. Ich habe dafür die Komponente MSCOMM32.OCX-Control aus Visual Studio 6.0 benutzt.

Aber wenn es unbedingt wie unter DOS sein soll.

Es können folgende Fehler auftreten:
1. Je nach alter des Rechners kann COM 1 schon durch die Maus belegt sein. Ich habe früher immer COM 2 dafür benutzt. Das währe glaube ich die Portadresse 03E8. Kann das aber jetzt nicht überprüfen, weil auf dem Laptop keine serielle Schnittstelle vorhanden ist.
2. Es könnte sein das der Interrupt von der Schnittstelle noch richtig eingestellt werden muss.
3. Die Schnittstelle muss noch unter Windows eingestellt werden. (in Win 2000 unter Gerätemanager) unter XP ?

Um nur einige zu nennen.

Bis bald Chemiker

[devidespe]

Hallo Chemiker,

danke für die Antwort.

Mir sind die Vorteile der Windows API oder externen Komponenten durchaus bewusst, und es sieht mittlerweile so aus, dass ich daran nicht vorbeikommen werde.

Deine Vorschläge und insbesondere die Gerätemanager-Einstellungen habe ich überprüft, aber kein Problem gefunden.

Mir als langjähriger hardwarenaher Entwickler erschien es nur sehr merkwürdig, dass $FF bei jedem Lesezugriff zurückgeliefert wird. Das geschieht normalerweise nur dann, wenn ein Fehler vorliegt (was ich ausschließen kann) oder etwas von Windows geblockt wird (was ich vermute).

Trotzdem danke für die Hilfe.

[OldGrumpy]

*Eigentlich* sind auf NT-basierten Windowssystemen sämtliche Portzugriffe (also auf Adressen unter 0x0400) tabu, da man nie sicher sein kann, dass Windows nicht selber auch auf die Ports will. Übliche Verdächtige wie z.B. ActiveSync belegen auch mal gerne Com-Ports mit Beschlag ohne den User darüber zu informieren... Innerhalb der NTVDM werden Portzugriffe übrigens direkt abgewürgt (und ggf. irgendwoanders hin umgeleitet, vgl. Mapping von LPT-Ports auf Netzwerkdrucker mittels NET USE). Für direkte Portzugriffe unter Windows NT und höher gibts z.B. Frickellösungen wie ZLPortIO was aus einem Kernelmode-Treiber und einer Userspace-API besteht. Der Treiber greift auf die Ports vom Kernel aus zu und bietet nach aussen (also ins Userland) hin eine Kommunikation über ein symbolisches Device an.