2008-10-17 7 views
12

Ich versuche, den geieio.sys Treiber zu verwenden, der eine "Datei" benötigt, um geöffnet zu werden, bevor Sie auf geschützten Speicher zugreifen können. Ich bin von WinAVR/AVRdude bei einem C Beispiel suchen, die Syntax verwendet:Öffnen eines Handle zu einem Gerät in Python unter Windows

#define DRIVERNAME  "\\\\.\\giveio" 
HANDLE h = CreateFile(DRIVERNAME, 
      GENERIC_READ, 
      0, 
      NULL, 
      OPEN_EXISTING, 
      FILE_ATTRIBUTE_NORMAL, 
      NULL); 

aber dies scheint nicht in Python zu arbeiten - bekomme ich nur ein „Der angegebene Pfad ist ungültig“ Fehler, sowohl für

f = os.open("\\\\.\\giveio", os.O_RDONLY) 

und

f = os.open("//./giveio", os.O_RDONLY) 

Warum dies nicht das gleiche tun?

Bearbeitet um hoffentlich Verwirrung der Ideen zu reduzieren (danke Will). Ich habe überprüft, dass der Gerätetreiber über die Batch-Dateien läuft, die mit AVRdude geliefert werden.

Weiter bearbeitet, um SamBs Kopfgeld zu klären.

+0

@SamB warum hat das ein Kopfgeld angeboten? es wurde vor langer Zeit gelöst und geschlossen ... – theheadofabroom

+0

@BiggAl: Ich hatte gehofft, dass jemand erklären würde, warum (das Beispiel des OP zu leihen) 'os.open (" \\\\. geieio ", os.O_RDONLY)' macht im Wesentlichen nicht dasselbe wie das obige C. Rückblickend denke ich, dass ich es am Anfang hätte sagen sollen? – SamB

+0

@SamB würden Sie die Frage aktualisieren, um das zu reflektieren? – theheadofabroom

Antwort

2

Ihre Frage ist sehr verwirrend, um es gelinde auszudrücken.

1> Der Code, den Sie eingefügt wird ein Trick mit dem Fahrer zu kommunizieren seine Verwendung 'DOSname' heißt

\\.\DRIVERNAME 

2> Haben Sie erstellt & die 'giveio' Treiber geladen?

Der Grund der Fahrer behandelt dies nennt, ist wegen dieser

http://msdn.microsoft.com/en-us/library/ms806162.aspx

1

Ich bin nicht sicher, ob das möglich ist. Als Alternative könnten Sie ein C/C++ - Programm schreiben, das all diesen Kernel-Space für Sie arbeiten lässt und in Python über the subprocess module oder Python C/C++ bindings (und another link dafür) eine Verbindung herstellt.

+0

Der GIVEIO.SYS-Treiber erledigt bereits den gesamten Kernel-Space für Sie. Alles, was Sie mit diesem Treiber zu tun haben, ist, wie mit einem COM-Port zu sprechen (rufen Sie CreateFile auf, um die Kommunikationsverbindung zu öffnen). –

3

Ich weiß nichts über Python, aber ich weiß ein wenig über Treiber. Sie versuchen überhaupt nicht, eine Datei im Kernel-Bereich zu öffnen - Sie versuchen nur, einen Handle für ein Gerät zu öffnen, das so aussieht, als würde es sich öffnen lassen.

CreateFile ist eine Benutzermodusfunktion und alles, was Sie hier tun, ist Benutzermodus, nicht Kernelmodus.

Wie Xenon sagt, kann Ihr Anruf versagt werden, weil Sie nicht den Treiber noch geladen haben, oder weil das, was Python rufen Sie die Createfile zu tun, verwenden wird, um die Schreibparameter nicht vorbei in.

I‘ Ich habe gleitio.sys nie selbst benutzt, aber persönlich habe ich festgestellt, dass es korrekt geladen wurde, indem ich 'C' oder C++ (oder eine vorgefertigte App) benutzte, bevor ich versuchte, es über Python zum Laufen zu bringen.

5

Lösung: In Python müssen Sie win32file.CreateFile() anstelle von open() verwenden. Danke, dass ihr mir gesagt habt, was ich versucht habe, es hat mir geholfen, die Antwort zu finden!

2

Es gibt 2 Möglichkeiten, dies zu tun.

Der erste Weg wird mit dem win32 Python-Bindings

h = win32file.CreateFile 

Oder mit ctypes

+1

Diese Antwort wäre besser, wenn es tatsächlich gezeigt würde, wie man die Parameter gibt ... – SamB

+0

Die Parameter sind die gleichen wie die, die Sie im ursprünglichen Beitrag aufgelistet haben. Aber Sie könnten das selbst herausfinden, wenn Sie tatsächlich eine einfache Google-Suche durchführen würden. – Grim

2

Es klingt für mich wie Sie fragen, warum os.open dem Aufruf Createfile nicht auf magische Weise gleich mit einem sehr spezifischer Parametersatz. Kostya's Antwort ist insofern praktisch, als es Ihnen sagt, dass Sie die Win32-Python-Bindings verwenden können, um CreateFile, das eine Win32-API ist, direkt aufzurufen.

Alles andere als das direkte Erstellen von CreateFile/readFile/writeFile IO wird eine weitere Ebene oben einfügen (die Python-Dateiobjekte und ihre Verhalten), die Sie auf die Parameter beschränkt, die von os.open unterstützt werden. os.open erstellt ein Python-Dateiobjekt, das nicht genau dasselbe ist und nicht alle Optionen von Win32 CreateFile bereitstellen soll.

Das bedeutet zum Beispiel, dass kein exaktes Analogon von GENERIC_READ oder OPEN_EXISTING oder FILE_ATTRIBUTE_NORMAL garantiert existiert.

Meine beste Vermutung ist, dass os.open nicht direkte Aufrufe von CreateFile für solch seltsame Zwecke ersetzen soll, für die Sie es verwenden.

Wenn Sie C lesen können, öffnen Sie die Quellen für Python und lesen Sie die Implementierung von os.open. Wenn Sie wirklich os.open durchlaufen müssen, werden Sie herausfinden, welche Parameter übergeben werden sollen, so dass die Implementierung von os.open (in C) am Ende CreateFile in Win32 API mit den korrekten Parametern oben aufruft. All das scheint eher Arbeit zu sein, als Kostyas Vorschlag zu benutzen.

+0

Eigentlich sollte ['os.open'] (http://docs.python.org/library/os.html#os.open) ein ziemlich geradliniger Wrapper um die' open() '-Funktion der CRT (genannt ['_open()'] (http://msdn.microsoft.com/en-us/library/z0kc8e3z.aspx) in Visual C++) und gibt daher einen "file descriptor" zurück (ein 'int', das sich auf das opened bezieht Datei). Ich denke *, dass die Ebene, die stören würde, wahrscheinlich tatsächlich da wäre, nicht in Pythons Code ... – SamB

+0

Ja. Hier bitteschön. Es ist ein Wrapper um die offene Funktion C Runtime Library, die eine eher posix-ähnliche Semantik hat, die nicht die verschiedenen einzigartigen Features enthält, die CreateFile aufdeckt. –

+0

Wenn dies die beste Antwort ist, sollten Sie es akzeptieren, richtig Sam? –

Verwandte Themen