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
Falls du nur niedrige Datenraten benötigst, würde sich auch die HID-Deviceclass anbieten.
FTDI funktioniert bei mir mit Win7 @ 64bit problemlos. Ich glaube sogar dass der Teiber automatisch gefunden wurde.
> 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).
Ich benutze mein kleines im Anhang befindliches Board. C1, C3 und C4 sind optional.
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.