USB Programmierung C++ -> C#
-
Hallo zusammen
ich habe folgendes Problem:
Ich schreibe gerade einen C++-USBTreiber in einen C#-USBTreiber um, was bisher auch ganz gut funktioniert hat. Nun bin ich aber an einem Punkt, an dem ich dieHidD_GetPreparsedData()Methode abfrage und da die Fehlermeldung:
Es wurde versucht, auf ein Token zuzugreifen, das nicht vorhanden ist.bekomme. Woran liegt das? Im Internet finde ich nur Sachen mit Netzwerk und so etwas. Wenn ich den C++-Treiber starte, bekomme ich für die Methode einwandfreie Werte. Nicht aber im C#-Programm. Woran kann das liegen?
Vielen Dank für Eure Hilfe!
-
Einen Treiber in .NET? Das halte ich für keine gute Idee.
-
SeboStone schrieb:
Einen Treiber in .NET? Das halte ich für keine gute Idee.
da bin ich der gleichen Meinung... sorry.
-
Hmm, o.k., und warum nicht?
-
Klärt doch erst mal Treiber auf welcher Ebene und was da jeder unter Treiber versteht. Ich finds einfach nicht gut, wenn kategorische "C# Treiber -> Geht nicht" als Antwort kommen.
-
Die Fehlerbeschreibung ist sowieso unzureichend. Wie fragt man Methoden ab (ich kenne nur Aufrufe) und woher kommt diese "HidD_GetPreparsedData" Methode überhaupt? Nutzt Du für sie in C# einen fertigen Wrapper? Oder ist das PInvoke, und evtl. stimmen die Importe nicht? Hast Du diese Funktion überhaupt importiert? Fragen über Fragen...
-
O.k., das Problem selbst habe ich gelöst, es war eine falsche if-Abfrage drin, die mich immer rausgeworfen hat. Hab die Capabilities meines Handles falsch abgefragt.
Eine andere Frage: c++ dlls kann ich in c# importieren, was aber mache ich mit .h Dateien? Konkret habe ich das Problem, dass ich gerne Methoden aus der hidsdi.h (von WindowsDDK) benutzen würde, es zur hidsdi.h aber keine dll gibt, die ich importieren könnte. Kann ich auch eine .h Datei irgendwie in C# nutzen? Es gibt auch keine .lib dazu.
-
Der Thread wird hier fortgesetzt:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-198382.html
-
simon.gysi schrieb:
Klärt doch erst mal Treiber auf welcher Ebene und was da jeder unter Treiber versteht. Ich finds einfach nicht gut, wenn kategorische "C# Treiber -> Geht nicht" als Antwort kommen.
Mich würde selber auch interessieren, weshalb C# Treiber nicht gut sein sollen.
-
C# wird in Bytecode umgewandelt und das läuft dann auf einem Interpreter (das solltest Du eigentlich wissen!!), ist also ähnlich wie Java und da Treiber was mit Geschwindigkeit zu tun hat ist ein Treiber in C# eben Quark.
-
SeboStone schrieb:
C# wird in Bytecode umgewandelt und das läuft dann auf einem Interpreter
Das ist falsch, und
und da Treiber was mit Geschwindigkeit zu tun hat ist ein Treiber in C# eben Quark.
das ist so pauschal ebenfalls falsch. Die Geschwindigkeit von C# ist (auch für nen Treiber) vollkommen in Ordnung, da nativer Code ausgeführt wird. Das JITten sollte nicht stören. Was stören *kann* (und wird), ist der nicht-deterministische GC, der Dir Dein schönes Realtime-System (welches ein Treiber unbedingt sein sollte) eventuell zerhaut.
Also: C# ist (mit üblichen Compilern) nicht für die Treiberprogrammierung geeignet, aber aus anderen Gründen als den hier genannten.
-
Hi,
Konrad Rudolph schrieb:
Was stören *kann* (und wird), ist der nicht-deterministische GC, der Dir Dein schönes Realtime-System (welches ein Treiber unbedingt sein sollte) eventuell zerhaut.
Hat man für sowas nicht den Unmanaged Code?
Gruß
-
Borschtsch schrieb:
Konrad Rudolph schrieb:
Was stören *kann* (und wird), ist der nicht-deterministische GC, der Dir Dein schönes Realtime-System (welches ein Treiber unbedingt sein sollte) eventuell zerhaut.
Hat man für sowas nicht den Unmanaged Code?
Inwiefern soll unmanaged code da helfen? Stimmt schon, dass man dem GC damit einen Riegel vorschiebt, allerdings erfolgt das eher lokal. Generell wird man dadurch den GC trotzdem nicht davon abhalten können, Objekte zu verwalten und dies auch zu ungünstigen Zeitpunkten zu tun.
-
pharmacy;