Hallo ich brauche mal jemanden, der mir in der USB-Welt ganz grob die Richtung zeigt.Denn je mehr ich mich in das Thema hineinlese, desto verwirrter bin ich. Ich habe vor 10 Jahren eine Elektronik entwickelt, die Betriebsdaten erfasst.Die Daten können über eine RS232-Schnittstelle auf einen Windows-PC ausgelesen werden. Nun machen mir meine Kunden druck, weil neu erworbene PC’s über keinerlei RS232-Schnittstelle mehr verfügen. Mit dem USB-RS232-Schnittstellenadapter habe ich nur ärger, weil immer dann, wenn ein weiteres USB-Gerät im PC eingesteckt wird, die COM-Port-Nummer meiner Elektronik auf eine andere Nummer weiterwandert. Erst wenn man meinen Adapter in der Systemsteuerung mit einer festen Adresse einstellt, klappt es problemlos. Wechselt der PC, gehen diese Anfragen von neuem los. Seit es die gute alte RS232-Schnittstell nicht mehr gibt, muss ich viel mehr Servicetelefonate führen. Neues Ziel: Ich habe mir vorgenommen, meine Geräte mit einer USB-Schnittstelle nachzurüsten. Ich verwende einen Fujitsu MB90340-Controller der I2C kann. (leider noch kein SPI). Ich möchte gerne eine I2C to USB Bridge einsetzen. Von FTDI gibt es schönen Bausteine, wie ich gesehen habe. Ich will aber nicht schon wieder einen Virtuellen COM Port, dann habe ich nur wieder das Problem der wandernden Portnummern. Ich habe von USB-HID-Bausteinen gelesen. Wäre das einen Lösung? Oder kann man damit nur einfache Eingabegeräte bauen? Ich stelle mir das folgendermaßen vor: Ich verbinde meine Elektronik über USB mit dem PC. Der PC erkennt meine USB-Schnittstelle und zeigt mir im Windows Explorer ein Verzeichnis an, in der die Dateien meiner Aufzeichnung abliegen. Ich kann Dateien (wie bei einem MP3-Player) zwischen Gerät und PC hin und her kopieren. So der Wunsch. Nun zu meiner Frage: Ist diese Funktionalität bereits mit einem USB-HID-Baustein möglich? Oder benötige ich eine andere Art von USB-Device. Das USB-Thema ist sehr komplex. Ich wäre dankbar, wenn mir jemand ganz grob die Richtung zeigen könnte. Welche Art von USB-Device benötige ich. Was sind geschickte Bausteine, die mir die Protokollarbeit abnehmen. Vielleicht gibt es auch schon Demos, die ich mal studieren könnte? Vielen Dank schon einmal vorab für Eure Hilfestellung. Grüße Markus
Schau dir mal V-USB an, das könnte interessant für dich sein. https://www.obdev.at/products/vusb/index.html
VUSB ist eine technische Krücke und hat die Zertifizierung durch das USB Implementers Forum nicht bekommen. Das alleine ist ein Grund, es nicht für kommerzielle Applikationen einzusetzen, zudem es nur Low-Speed kann. Außerdem kann eine kommerzielle Liznz echt ins Geld gehen. Wenn Du einen USB zu I2C Baustein suchst, dann schau Dir den MCP2221A an. Der hat eine serielle Schnnittstelle, 4 GPIOs und I2C, braucht keinen Quarz, und Du bekommst Bibliotheken für Windows und Linux. Das ist ein Composite CDC-ACM (für seriell)/HID (für GPIO und I2C) Device. Wenn Du die serielle Schnittstelle benutzt, bekommst Du die Nummer des COM-Ports über das Windows SetupAPI heraus. Dafür musst Du Deinem USB-UART-Adapter entweder eine eigene VID/PID oder einen eigenen Stringdescriptor verpassen, mit dem Du ihn in der SetupAPI identifizieren kannst. fchk
Nun. Der Vorteil und Nachteil von USB ist dass er sich selbst beim
System anmeldet. Also :
-hallo system, ich bin ein
a) HID = 60 packete pro Sekunde, gut fuer Keyboard & Mouse
Treiber ist Teil des systems, vorhanden, wird geladen
b) Mass Storage = Zeige Filesystem
Treiber ist Teil des systems, vorhanden, wird geladen
c) Virtual comport - erscheint gegenueber der PC Software
als Serial Port, Treiber wahrscheinlich vorhanden,
wird geladen
d) irgendwas anderes - Funktionalitaet irgendwas
Treiber nicht vorhanden, CD Einschieben, Treiber laden
zu d) Wie lange gibt es den Treiber noch ? Denn, neues Windows, neuer
Treiber, Der Treiberhersteller muss jeweils einen neuen Treiber
bereitstellen. Windows 12 ? Windows 14 ? Falls das Geraet nicht so gut
laeuft, hat der Hersteller vielleicht keine Lust das Geraet zu lange zu
unterstuetzen. Allenfalls hat der Hersteller auch andere Vorstellungen
zum Produkt Life Cycle. Im Sinne von nach 2 Jahren ist das Geraet
sowieso veraltet, die Kunden sollen ein Neues kaufen.
Wenn du den Treiber selbst schreibst .. ist machbar, auch wenn nicht
trivial, gilt dasselbe auch.
Du moechtest eine Logger als Storage Device ansteuern ... kann man
machen. Aber die Konfiguration geschieht wie ? Per Front panel .. kann
man so machen. Per USB ? Dann muesste man ein Konfig file schreiben,
editieren, und laden. Geht auch. Also, dann schreib ein USB Storage
Device fuer ein dein Geraet. Literatur dazu waere zB Jan Axelson, USB
Mass Storage, und den Rest. Nimm dir 3 Monate, vielleicht auch mehr.
:
Bearbeitet durch User
Zudem ist VUSB mit der heißen Nadel für AVRs gestrickt. Ich gehe aber davon aus, dass er die MCU beibehalten möchte.
Die MCU beibehalten ? Eher nicht. Allenfalls die naechst groessere, falls denn erhaeltlich und kompatibel. Eine USB Implementierung ist nicht trivial, wenn es um eine eigene Klasse geht.
markus c. schrieb: > Ich möchte gerne eine I2C to USB Bridge > einsetzen. > Von FTDI gibt es schönen Bausteine, wie ich gesehen habe. Ich will aber > nicht schon wieder einen Virtuellen COM Port, Schau dir mal den MCP2221A an. Der kann USB -> USART und I2C. I2C geht dabei (soweit ich weiß) über HID.
So wie ich das lese und interpretiere hat er aber genau das vor. markus c. schrieb: > Nun zu meiner Frage: > Ist diese Funktionalität bereits mit einem USB-HID-Baustein möglich? > Oder benötige ich eine andere Art von USB-Device. Nein, mit einem HID Device schaffst du das nicht. Bei einem HID-Device kannst du die Kommunikation nach deinen Wünschen gestalten, brauchst aber auf PC-Seite eine entsprechende Software speziell dafür. Geht also eher in Richtung deiner RS232-Variante, wie du sie aktuell verwendest. Wenn du das Ding als "Speicher" im Windows Explorer sehen willst, brauchst du ein Mass Storage Device, hast dann aber das Thema mit der Konfiguration. Lässt sich aber lösen, indem du diese ebenfalls als Datei ablegst und einmalig beim Einstecken ausliest.
markus c. schrieb: > Mit dem USB-RS232-Schnittstellenadapter habe ich nur ärger, weil immer > dann, wenn ein weiteres USB-Gerät im PC eingesteckt wird, die > COM-Port-Nummer meiner Elektronik auf eine andere Nummer weiterwandert. Würdest Du eine USB-RS232-Bridge verwenden, die eine eindeutige Seriennummer hat, gäbe es dieses Problem nicht. Dafür kann man an den meisten FTDI-Bausteinen ein serielles EEPROM anschließen; der FT232R hat dieses EEPROM sogar integriert (und damit ab Werk eine eineindeutige Seriennummer).
Zitronen F. schrieb: > HID = 60 packete pro Sekunde, gut fuer Keyboard & Mouse > Treiber ist Teil des systems, vorhanden, wird geladen Hid hat nichts mit 60/Pakete pro Sekunde zu tun. Neben Interrupt Transfers unterstützt es auch Control Transfers, die für reine Datenübertragung geeigneter sind. So lange die Datenrate ausreicht, ist hid grundsätzlich keine schlechte Wahl.
markus c. schrieb: > Mit dem USB-RS232-Schnittstellenadapter habe ich nur ärger, weil immer > dann, wenn ein weiteres USB-Gerät im PC eingesteckt wird, die > COM-Port-Nummer meiner Elektronik auf eine andere Nummer weiterwandert. > Erst wenn man meinen Adapter in der Systemsteuerung mit einer festen > Adresse einstellt, klappt es problemlos. Dann liegt die Baustelle bei deiner PC Software und/oder bei der VID/PID/SN Konfiguration deines USB-Serial Konverters. Die AN_123 von FTDI zu dem Thema hast du gelesen?
markus c. schrieb: > Ich stelle mir das folgendermaßen vor: > Ich verbinde meine Elektronik über USB mit dem PC. Der PC erkennt meine > USB-Schnittstelle und zeigt mir im Windows Explorer ein Verzeichnis an, Startet Windows Explorer automatisch von BS oder über dein eigenes Programm?
Hi... Warum nicht so ansprechen wie man es richtig macht... https://docs.microsoft.com/en-us/uwp/api/Windows.Devices.SerialCommunication ?
Ich habe 500 Geräte mit Fujitsu MB90340 bei meinen Kunden. Ich möchte die USB-Schnittstelle gerne nachrüsten. Ich kann den Controller nicht gegen einen Atmel AVR tauschen. Der Aufwand wäre zu groß.
M. K. schrieb: > Schau dir mal V-USB an, das könnte interessant für dich sein. > > https://www.obdev.at/products/vusb/index.html Ich habe 500 Geräte mit Fujitsu MB90340 bei meinen Kunden. Ich möchte die USB-Schnittstelle gerne nachrüsten. Ich kann den Controller nicht gegen einen Atmel AVR tauschen. Der Aufwand wäre zu groß.
M. K. schrieb: > Schau dir mal V-USB an, das könnte interessant für dich sein. > > https://www.obdev.at/products/vusb/index.html Ich habe 500 Geräte mit Fujitsu MB90340 bei meinen Kunden. Ich möchte die USB-Schnittstelle gerne nachrüsten. Ich kann den Controller nicht gegen einen Atmel AVR tauschen. Der Aufwand wäre zu groß. fchk schrieb: > VUSB ist eine technische Krücke und hat die Zertifizierung durch > das USB > Implementers Forum nicht bekommen. Das alleine ist ein Grund, es nicht > für kommerzielle Applikationen einzusetzen, zudem es nur Low-Speed kann. > Außerdem kann eine kommerzielle Liznz echt ins Geld gehen. > > Wenn Du einen USB zu I2C Baustein suchst, dann schau Dir den MCP2221A > an. Der hat eine serielle Schnnittstelle, 4 GPIOs und I2C, braucht > keinen Quarz, und Du bekommst Bibliotheken für Windows und Linux. Das > ist ein Composite CDC-ACM (für seriell)/HID (für GPIO und I2C) Device. > > Wenn Du die serielle Schnittstelle benutzt, bekommst Du die Nummer des > COM-Ports über das Windows SetupAPI heraus. Dafür musst Du Deinem > USB-UART-Adapter entweder eine eigene VID/PID oder einen eigenen > Stringdescriptor verpassen, mit dem Du ihn in der SetupAPI > identifizieren kannst. > > fchk Der Baustein MCP2221 kann CDC und HID So wie ich das verstanden habe, benötigen ich aber ein Mass Storage Device, wenn ich Daten per Drag and Drop hin und her kopieren möchte.
Micha schrieb: > Wenn du das Ding als "Speicher" im Windows Explorer sehen willst, > brauchst du ein Mass Storage Device, hast dann aber das Thema mit der > Konfiguration. Lässt sich aber lösen, indem du diese ebenfalls als Datei > ablegst und einmalig beim Einstecken ausliest. Ok, diesen Weg werde ich mir genauer anschauen! Hier gibt es wohl keine fertigen Bausteine, die einem die Arbeit erleichtern?
In meinem USB-Tutorial mit STM32 ist beschrieben, wie du ein komplettes USB-Gerät selbst entwickelst, welches auch ohne Windows keine Treiber-Installation benötigt (Zugriff via WinUSB). Tatsächlich ist USB-Entwicklung gar nicht so schwierig, wenn man alle nötigen Informationen hat. Rufus Τ. F. schrieb: > (und damit ab Werk eine eineindeutige > Seriennummer). Eineindeutig? Zu jeder Seriennummer existiert ein Gerät? ;-)
:
Bearbeitet durch User
Fred R. schrieb: > Kennst du USB4ALL ?? Nein USB4ALL kannte ich noch nicht. Kann sich USB4ALL als Storage Device am PC melden? Ich möchte gerne Dateien über Drag and Drop kopieren, denn damit können meine Kunde umgehen.
markus c. schrieb: > Mit dem USB-RS232-Schnittstellenadapter habe ich nur ärger, weil > immer dann, wenn ein weiteres USB-Gerät im PC eingesteckt wird, > die COM-Port-Nummer meiner Elektronik auf eine andere Nummer > weiterwandert. Du hast doch bereits ein PC-Programm, mit dem du den Datenaustausch über RS232 vornimmst. In diesem Programm kann man den COM-Port sicherlich auch einstellen, oder? Erweitere dein Programm doch einfach um eine Einstellmöglichkeit "USB", die dann einen USB-Seriell-Adapter nimmt und dessen Seriennummer (statt der COM-Portnummer) in den Einstellungen speichert. Die aktuelle COM-Portnummer des Wandlers kannst du beim Programmstart automatisch ermitteln. markus c. schrieb: > So wie ich das verstanden habe, benötigen ich aber ein Mass Storage > Device, wenn ich Daten per Drag and Drop hin und her kopieren möchte. Nicht unbedingt. Ein Mass Storage Device ist eine Festplatte. Du kopierst also nur "Blöcke" umher. Dein Gerät muss in der Lage sein, mit dem Dateisystem zuverlässig umzugehen (auch dann, wenn der Nutzer das "Laufwerk" formatiert oder anderen Unfug damit treibt). Für einen einfachen Dateiaustausch wäre MTP (Media Transfer Protocol) möglicherweise geeigneter, wie es inzwischen von jedem Android benutzt wird. Damit tauschst du tatsächlich "Dateien" aus, das Gerät taucht mit seinem Namen im Explorer auf und es bekommt keinen Laufwerksbuchstaben. Die einfachste Lösung wäre aber, dein derzeitiges Programm um USB-Seriell-Adapter zu erweitern und für zukünftige Geräte einen solchen in das Gerät zu integrieren. Eine ordentliche USB-Integration (ohne Stress mit Treibern und zuverlässig) ist nicht einfach zu machen, wenn die Gerätearchitektur dafür nicht ausgelegt ist.
Niklas G. schrieb: > In meinem USB-Tutorial mit STM32 ist beschrieben, wie du ein > komplettes USB-Gerät selbst entwickelst prima, ... schau ich mir an!
markus c. schrieb: > Ok, diesen Weg werde ich mir genauer anschauen! > Hier gibt es wohl keine fertigen Bausteine, die einem die Arbeit > erleichtern? Eine schnelle Suche fördert den FTDI FT12x zutage. Der hat allerdings nur eine SPI-Schnittstelle. Mit I2C oder RS232 wird es da nichts geben, weil viel zu langsam. Du wirst dir vermutlich mittels eines 2. Controllers selber eine Bridge bauen müssen, wenn du unbedingt am derzeitigen Controller festhalten willst. Wolfgang schrieb: > Die AN_123 von FTDI zu dem Thema hast du gelesen? Da ist das sicher die einfachere und bessere Lösung denke ich. Das Produkt scheint ja zu funktionieren und das einzige Problem ist das COM-Port-Gefrickel. Ggf. musst du halt selbst die USB<->RS232 einkaufen, konfigurieren und dem Produkt beilegen. Parallel könntest du ein Redesign starten und die MCU gegen irgendwas mit USB-Peripherie ersetzen.
Du kannst es auch komplett in die Software auslagern. Die PC-Software fragt einfach alle COM-Ports (COM0..COM255) ab. Die meisten lassen sich nicht initalisieren, da sie schlicht nicht existieren. Bei allen Ports wo ein INIT klappt, schickst Du einfach eine Anfrage an Dein Gerät (zb. "IDN?" wie bei Messgeräten..) Das Gerät, das die richtige Antwort schickt wird verwendet. Der Nutzer merkt das gar nicht, das dauert in Labview unter Win7 vielleicht 3 Sekunden, je nachdem wie viele Ports sich Initalisiern lassen und dann falsch antworten. Blöd wirds dann, wenn mehrere Deiner Geräte an einem PC hängen.
Bentschie schrieb: > Bei allen Ports wo ein INIT klappt, schickst Du einfach eine Anfrage an > Dein Gerät (zb. "IDN?" wie bei Messgeräten..) > Das Gerät, das die richtige Antwort schickt wird verwendet. Das ist derber Pfusch, da nicht sichergestellt werden kann, daß andere Geräte darüber glücklich sind, wenn über ihre Schnittstellen einfach irgendwas 'reingerotzt wird.
Die verfuegbaren Comports werden aus der Registry abgefragt.
Damit müssen die aber immer rechnen. Wenn ich das "händisch" ausprobiere, kann das auch passieren. Ja, gut. Ich hab das bisher nur "für mich" im Labor gemacht. Der eine oder ander Kunde könnte damit Zicken haben. Dann halt umgedreht. Das Gerät sendet ständig einen String an den PC zur Identifikation. Ich lausche also auf allen COM Ports, ob des richtige kommt. Dann dauert halt das suchen etwas länger, aber es wird niemand belästigt. Der Vorteil dieser Methode ist halt, das geht immer. Auch mit dem neuesten Win10 Upgrade und dem dümmsten USB-Seriell Adapter (natürlich nur, sofern der Adapter prinzipell tut). Ohne irgendwelchen Eingriffe in die Registry. Auch unter Linux in WINE oder sonst wo.
Bentschie schrieb: > Bei allen Ports wo ein INIT klappt, schickst Du einfach eine Anfrage an > Dein Gerät (zb. "IDN?" wie bei Messgeräten..) > Das Gerät, das die richtige Antwort schickt wird verwendet. Es soll ein Betriebssystem geben, das standardmäßig alle COM-Ports, auf denen serielle Daten rein kommen, als Serial Ballpoint Mouse im Betriebssystem anmeldet. Da muss man nur ein GPS mit NMEA Daten anstecken ... und schon geht's ab. Wie hieß die Firma noch - Micro<irgendwas>?
Bentschie schrieb: > Dann halt umgedreht. Das Gerät sendet ständig einen String an den PC zur > Identifikation. Naja, warum nicht die Lösung mit dem Namenspace wie oben erwähnt? Wolfgang H. schrieb: > Hi... Warum nicht so ansprechen wie man es richtig macht... > https://docs.microsoft.com/en-us/uwp/api/Windows.D... > ?
Bentschie schrieb: > Dann halt umgedreht. Das Gerät sendet ständig einen String an den PC zur > Identifikation. > Ich lausche also auf allen COM Ports, ob des richtige kommt. Das ist immer noch Pfusch. Vor allem kann das lustige Effekte haben; der Plug&Play-Mechanismus von Windows ist immer noch dafür ausgelegt, serielle Mäuse zu erkennen. Und dann ist a) die serielle Schnittstelle für den Maustreiber blockiert und b) Dein Mauszeiger macht potentiell sehr interessante Dinge. Nein; der saubere Weg ist es, einen sinnvollen Geräteidentifikationsstring im USB-Devicedescriptor unterzubringen, dann nämlich kann nach USB-Geräten mit diesem String gesucht werden. VID & PID lässt man natürlich, wie sie sind, damit der richtige Devicetreiber verwendet wird.
markus c. schrieb: > Der Baustein MCP2221 kann CDC und HID > So wie ich das verstanden habe, benötigen ich aber ein Mass Storage > Device, wenn ich Daten per Drag and Drop hin und her kopieren möchte. Ja, kann man so machen. Bedeutet einiges an Hardwareaufwand und an Kosten. Wenn Du aber akzeptierst, dass Du eine eigene Applikation hast, die das Drag&Drop macht (d.h. auf die Du Dateien im Explorer fallen lassen kannst) und die dann über den MCP2221A (die Version ohne A ist veraltet) mit Deiner Hardware spricht, dann kommst Du mit viel weniger Hardware aus. Statt 50€ pro Gerät an Hardware werden es dann nur maximal 10€. (ganz grob geschätzt, wirklich nur pi mal Daumen, nagelt mich darauf jetzt bloß nicht fest). In einem Fall musst Du die Firmware für den zusätzlichen Mikrocontroller entwickeln, im anderen Fall eine Windows-Applikation. Kommt in etwa aufs gleiche raus. fchk
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.