Hallo allerseits,
nachdem ich mir nun nach einer ganze Weile des Installierens von libusb
den PC (Windows 7 64Bit) versaut hab (kein USB mehr, nich mal im
safe-mode), würde mich interessieren, wie gerade der aktuelle Stand ist
bezüglich hobbymäßig den µC per USB an den PC anbinden...
Über FTDI?
Gleich nen µC nehmen der USB an Bord hat? Was aber hieße den Treiber
selbst zu schreiben?
Oder über einen mir nicht bekannten libusb für Windows 7 Hack?
Besten Dank!
Greets
Dev
> Gleich nen µC nehmen der USB an Bord hat? Was aber hieße den Treiber> selbst zu schreiben?
Da gibts doch normalerweise vom Hersteller des µC einen Treiber. Ich
programmiere grade auf USB-fähigen PICs und da gibt es von Microchip
einen fertigen Treiber, der sogar bei mir unter Win7 x64 funktioniert.
Hallo Mars,
@Mars:
hab mir gerade das Whitepaper zu WinUSB durchgelesen.
Statt einen ganzen Treiber selbst implementieren zu müssen, muss man mit
WinUSB "nur":
- den implementierten Kernel-Mode-Treiber und die WinUSB Schicht darüber
verstehen
- die entsprechende .INF für den Treiber erstellen
- den KMDF, WinUSB + INF in ein Treiberpacket stecken und irgendwie
signieren
- die WinUSB API anziehen (C++)
- dann in der Applikation (falls C++) sämtliche nötigen USB
Protokollfunktionen aufrufen (SetupDiGetClassDevs(..),
SetupDiGetDeviceInterfaceDetail(..), SetupDiEnumDeviceInterfaces(..),
...), - oder daraus eine Bibliothek basteln, die man (wie von mir
gewünscht) in .NET anziehen kann
Ich bin wahrscheinlich zu verwöhnt gewesen durch libusbdotnet - aber
anstatt diese Strecke selbst zu entwickeln würde ich etwas effizienteres
vorziehen.
Option A) ist natürlich einen USB<>RS232 Umsetzer zu kaufen und den µC
per RS232 anzubinden. Option B) wäre das gleiche, nur per FTDI mit auf
dem Board, wobei der Unterschied hier schon marginal ist.
Option C) wäre einen µC nehmen, bei dem der Hersteller einen Treiber
mitliefert... Wobei es auch hier wieder nötig wäre, die Low Level
Protokoll Funktionen zu implementieren.
Option D) wäre die HID DeviceClass - dafür müsste es eigentlich schon
von Haus aus auch z.B. in .NET einen Zugriff auf den Endpoint geben,
ohne sich großartig um das USB Protokoll kümmern zu müssen. Das werde
ich mir noch anschauen.
@Di Pi, Daniel R.:
Was musstest Ihr Applikationsseitig an Logik umsetzen um einen nutzbaren
Kommunikationskanal aufzubauen?
Gruß
dev
Hallo,
für WinUSB gibt es für .NET Host Applications, die Einbindung in .NET
ermöglichen, und noch Code-Schnipssel auf Google Code.
Eventuell schau ich mir das doch noch an, ob mit mäßigem Aufwand eine
Kommunikation über USB zu bewerkstelligen ist.
Problem bei allen Treibern ist die Signierung. Ohne Signatur lassen sich
unter x64 die Treiber nur mit F8 -> Deaktivieren der
Gerätetreiber-Signatur bei jedem Start von Windows laden. Sehr
unkomfortabel. Dann gibts noch die Möglichkeit, das System in den
Testsigning Modus zu versetzen, um einen selbst signierten Treiber zu
laden. Das geht wohl mit einem speziellen Programm auch für einzelne
Treiber. Ist auch ganz schöner Bastelmurks. Also am besten was bauen,
für das man fertige, signierte x64 Treiber bekommt.
Genau zu dem Schluss bin ich eben auch gekommen... für OS, die keine
Signierung benötigen, wäre WinUSB eine nette Alternative (die .NET
Bibliotheken sind doch schon fortgeschritten und verwendbar).
Jedoch für x64 passende INF + CAT zu basteln, OS in Testmode versetzen
und diese Signierung zu machen... Hm, ich hab hier zwar ein Batchfile,
das genau das mit den Libusb-Treibern macht, aber ich halts im Endeffekt
auch für Murks.
dev schrieb:
> @Di Pi, Daniel R.:> Was musstest Ihr Applikationsseitig an Logik umsetzen um einen nutzbaren> Kommunikationskanal aufzubauen?
Eigentlich garnichts. Der FTDI-Treiber erzeugt wie gewohnt einen
virtuellen COM-Port, wenn das Gerät angeschlossen ist. Danach gehts in
jedem Programm wie gehabt (Terminal-Progs genauso wie Custom-Software).
Naja, Inf basteln ist ja nur Schreibarbeit. Das cat File basteln ist
auch nicht so viel Arbeit, braucht man halt das WDK. Aber das bringt
alles noch nichts, weil man dann immer den Testsigning Mode bemühen
muss. Erst mit einer Verisign Signatur und dem durchlaufenen WHQL bei MS
kann man den Treiber ohne Verrenkungen installieren. Das kostet aber ein
paar Hunderter.
Für Heimprojekte kann man den Check auf gültige Treibersignatur in
Windows auch dauerhaft deaktivieren (über Gruppenrichtlinien). War auch
das ersten nach FF installieren was ich getan habe.
Das mit Treibersignieren ist zwar lästig, die ~150$ plus Zertifikat von
Verisign oder anderen Anbietern, sollten aber für jede Firma
verschmerzbar sein.
Ansonsten musst du halt die Bausteine von FTDI verwenden. Die bringen
bereits einen signierten Treiber mit. Allerdings hat man mit denen auch
wieder andere Probleme...
Aber wie ich bereits gesagt habe, solltest du mit max 64kbit je Richtung
auskommen, kann ich dir nur HID empfehlen. Das funktioniert ohne das du
Treiber installieren musst.
Ich denke das Thema hat sich für mich erledigt, Danke für die
zahlreichen Rückmeldungen. Für mich als Hobbybastler mit beschränktem
verfügbaren Zeitfenster bleibt es bei A) fertigen USB<>RS232 Adapter
kaufen, MAX232, µC. Mit mehreren µC gleichzeitig kommunizieren zu
wollen, welche nicht an einem Bus hängen, ist eigentlich gerade kein
Anwendungsfall. Und wenn, die Adapter kosten ja nicht die Welt... Aber
meist hat man entweder einen µC oder eben mehrere an einem Bus, und
dafür reicht ja ein Zugang über einen µC.
Gruß
dev
