Hi, ich möchte gern einen virtuellen COM-Port (USB) erstellen auf meinem Xpe System. Das Programm für den LPC Prozessor (USB-Schnittstelle) hab ich bereits geschrieben für den virtuellen COM-Port. Wenn ich Xpe starte, wird mir auch der "neue-hardware-found" dialog angezeigt, nur weiß ich nicht welche Componente ich im Target Designer auswählen muss, damit diese neue Componente auch als virtueller COM-Port dargestellt wird? Muss ich da selbst Hand-anlegen oder gibt es hier ähnlich wie bei dem HID einen generic driver? Den USB Composite-Device hab ich bereits zum Xpe Image hinzugefügt. Gruß Martin
> ...gibt es hier ähnlich wie bei dem HID einen generic driver?
Wenn sich dein Controller gemäß CDC (CommunicationDeviceClass) anmeldet
sollte es eigentlich gehen... Wie's unter XPe aussieht weiss ich leider
nicht.
Ralf
Zwar gibt es die Standardgeräteklasse CDC, aber Windows installiert dafür nicht automatisch einen generischen Standardtreiber. Aus irgendwelchen Gründen ist zwingend eine *.inf-Datei zur Installation erforderlich. Die üblichen USB-Seriell-Bridges aber (FTDI, SiLabs, Prolific oder TI) sind allesamt keine CDC-Implementierungen und benötigen daher eigene Treiber. Diese Treiber sind in den Platform Builder als neue, selbst zu konstruierende Komponente zu integrieren. An die genaue Vorgehensweise kann ich mich leider nicht erinnern, es ist einfach schon deutlich zu lange her, daß ich das das letzte Mal gemacht habe, und das Entwicklungssystem, mit dem ich das damals gemacht habe, existiert auch nicht mehr, als daß ich mal eben nachsehen könnte.
ich dachte ich hätte gerade was gefunden, aber nach deiner Aussage ist diese wieder hinfällig. Hab nur herausgefunden, dass man eine usbser.sys im Driver-Verzeichnis benötigt, die bei mir noch fehlt... Aber wahrscheinlich muss man wie du schon sagst, eine eigene Komponente anlegen.
wenn ich mehrere virtuelle Com-Ports erstellen möchte, benötige ich dann für jeden Com-Port eine eigene inf Datei (bezüglich der Vendor und Device-ID, welche in der inf stehen muss)?
>Hab nur herausgefunden, dass man eine usbser.sys >im Driver-Verzeichnis benötigt, die bei mir noch fehlt... Die hat Windows onboard.
Wenn das unterschiedliche USB-Seriell-Bridges sind, dann ist für jede einzelne, die mit einem anderen Treiber kommt, eine Komponente zu erstellen. Wenn Du aber mehrere gleichartige USB-Seriell-Bridges nutzen willst (also z.B. vier mal einen FT232), dann genügt eine. Inf-Dateien sind nur für USB-Seriell-Bridges erforderlich, die die Standardgeräteklasse CDC implementieren. Andere benötigen (wie ich bereits ausgeführt habe) komplette Treiberpakete, hier ist die zum Treiber gehörende Inf-Datei zu verwenden. Was exakt für eine Art von "virtuellen Com-Port" willst Du denn verwenden?
Rufus Τ. Firefly schrieb: > Was exakt für eine Art von "virtuellen Com-Port" willst Du denn > verwenden? Hi Rufus, als Ziel möchte ich gern 4x virtuelle COM-Ports erstellen die, die vier UARTs vom LPC1758 Prozessor mit Daten versorgen. Darüber sollen dann später DMX-Daten gesendet werden und auch empfangen werden können. Bin mir allerdings nicht 100%ig sicher ob die "virtuellen com-ports" oder einfach vier HIDs die bessere Wahl dafür sind. Eine inf-Datei mit usbser.sys ist ja schnell geschrieben und unter [Devicelist] müsste man in der Lage sein, mehrere VID/PIDs anzugeben, falls man irgendwann noch eine anderen Device hat der auch einen oder mehrere virtuelle Com-Ports darstellen soll. PC-seitig möchte ich mit c++ auf die Com-Ports oder den HIDs zugreifen können - Baudrate etc. einstellen (250kBaud - oder wählt man hier eine etwas höhere aus?) sowie Senden und Empfangen von Daten. Wie aufwendig ist es einen eigenen Treiber zu schreiben und bringt es mir in diesem Fall überhaupt irgendwelche Vorteile?
OK, wenn Du die CDC-Implementierung selbst in die Hand nimmst, dann ist die Inf-Datei die richtige Lösung. Einer HID-Variante gegenüber hat sie den Vorteil der einfacheren Programmierung - das auf dem XPe-System laufende Programm muss nichts von USB, HID etc. wissen, sondern nur wissen, wie serielle Schnittstellen anzusteuern sind. Die Baudrate dürfte sogar völlig irrelevant sein, solange die Daten an tatsächlich virtuelle Schnittstellen gesendet werden. Vergiss den eigenen Treiber, die Treiberentwicklung für Windows ist alles andere als mal eben so gemacht. Der Aufwand, sich darin einzuarbeiten ist die theoretischen Vorteile, die so etwas einer CDC-Lösung gegenüber haben könnte, nicht ansatzweise wert.
Rufus Τ. Firefly schrieb: > Die Baudrate dürfte sogar völlig > irrelevant sein, solange die Daten an tatsächlich virtuelle > Schnittstellen gesendet werden. Weil USB alle x-ms die man einstellt im CDC Treiber nach vorhandenen Daten fragt und diese im Fullspeed Modus überträgt?
Da muss ich gestehen: Keine Ahnung. Jedoch wird die Baudrate erst beim Übergang auf eine real existierende UART o.ä. relevant, und es wäre reichlich aufwendig, wenn der Treiber selbst die Baudrate verwendet, um timergesteuert mehr oder weniger viel Daten in das USB-Device zu übertragen.
Hi Rufus, weißt du wie es möglich ist, dass ein LPC mehr als einen virtuellen Com-Port installiert? Ist das überhaupt möglich? Hab mal ein zweites Interface (Descriptor) und zwei weitere Endpoints hinzugefügt -> Resultat war, dass das Gerät einen blauen Windows-Screen angezeigt hat (schwerer Ausnahmefehler)...
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.