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)?
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)...
