Guten Morgen, ich kann mir zwar nicht vorstellen das ich der erste bin der folgende Frage hier stellt, allerdings hab ich mit der Forumssuche bis jetzt noch nichts gefunden, daher: Ich entwickel ein mobiles USB-Gerät und versuche momentan herauszufinden mit welche Datenraten ich ein USB-CDC Device betreiben könnte und welcher Aufwand damit verbunden wäre. Welche windwosseitigen Treiber gibt es für diesen Zweck, gibt es kompatible versionen auch für Linux, Mac, oder mobile USB-OTG Geräte auf Basis von Android oder vielleicht sogar (aber unwahrscheinlich) iOS? Wie groß wäre schätungsweise der Aufwand auf uC Seite, wenn eine USB-CDC Implementierung bereits besteht, allerdings bisher nur auf den Standard-Windowstreiber ausgelegt ist? Erfahrungsberichte in die Richtung wären cool, ich für jede Anregung dankbar =)
:
Verschoben durch Moderator
ne dann solltest du kein vcom verwenden sondern ein HID oder noch besser versuchen das massstorage mit eigener remote applikation die im prinzip die daten vom storage abggreift. oder ein eigenes device mit eigenem treiber wo z.b. du mehrere vcom endpoints benutzt um den durchsatz zu erhöhen. Ist aber alles nicht so einfach.
CDC verwendet man entweder wenn man ein echtes CDC-Device (Modem z.B) hat, oder wenn man einen USB->RS232 Wandler will, aber kein Geld für einen "echten" FT232, CP210*, PL2303, ... hat. Software-USB (V-USB) am AVR ist sowieso langsam (Low-Speed only, 1.5MBit/s), der CDC-Overhead macht das nicht besser. (Wer mag's ausmessen, ich habe so 20kBit/s im Hinterkopf) Außerdem sperren Betriebssysteme mit korrekt implementiertem USB-Stack solche Geräte aus. (CDC braucht Bulk-Transfers, Low-Speed Geräte dürfen kein Bulk...) => Nimm einen USB-Seriell-Wandlerchip, und schließe den per UART an den µC an. Damit gehen auch 2Mbit/s ganz ohne Probleme, Treiber-Seitig hast du keinen Aufwand, den Treiber gibts vom Chiphersteller. Oder nimm einen µC mit integriertem USB. Je nach Typ und Aufwand geht das dann "beliebig" schnell.
ok, da hab ich mich wahrscheinlich etwas schlecht oder ungenau ausgedrückt. Ich habe einen Controller mit integriertem Full-Speed USB-Controller. Es existiert auch ein Beispiel vom Chiphersteller zum Verwendung als CDC VCP Gerät, allerdings verwendet dieser den Windowseigenen Treiber, der geht meineswissens nur bis zu Baudrates von 256000baud. Daher versuch ich rauszufinden ob es alternative Treiber gibt mit denen man den Full-Speed USB besser ausreitzen kann, also die 1,2MB/s bei Bulk-Transfer oder 1MB/s bei Isochon. Das ganze unter dem Gesichtspunkt auch für anderen Plattformen kompatibel (oder anpassbar) zu sein. Da ihr so motiviert bei der Sache seit und auch Vorschläge macht die vom Virtual Com-port weg gehen, hier noch ein paar Informationen: Controller: EFM32GG330F1024, 48MHz Clock, Full-/Low-Speed USB Controller integriert mit OTG-Unterstützung Es soll eine mobile Sensorplattform werden. Externen USB-Controller würde ich gerne vermeiden, da intern ja bereits vorhanden und wegen der zusätzlichen Kosten und des Stromverbrauchs. Des USB soll zum einen dem steuern des Gerätes dienen, also um Befehle hin zu schicken, und um die Sensordaten auszulesen. Ein USB-Bootloader gehört natürlich auch dazu aber das soll hier nich das Thema sein.
Chris S. schrieb: > Es existiert auch ein Beispiel vom Chiphersteller zum > Verwendung als CDC VCP Gerät, allerdings verwendet dieser den > Windowseigenen Treiber, der geht meineswissens nur bis zu Baudrates von > 256000baud. Da ist dein Denkfehler. Die Übertragung vom PC->Device bei CDC läuft immer mit voller USB-Geschwindigkeit, egal was für eine Baudrate im Treiber eingestellt ist. Hintergrund: CDC war für Modems gedacht. Die Baudraten-Einstellung im Treiber ist die Baudrate, die auf der Telefonleitung verwendet werden soll, nicht die Baudrate zwischen PC und Modem.
Εrnst B✶ schrieb: > (CDC braucht Bulk-Transfers, Low-Speed Geräte dürfen kein Bulk...) Nö, Low-Speed muss nur zwei Endpunkte unterstützen, CDC braucht aber drei (weil noch ein Interrupt-EP dabei ist). Allerdings ist es keineswegs verpflichtend für einen "korrekt implementierten Host", ein solches Gerät "auszusperren", es gibt eben nur seitens des Geräts keine Garantie, dass jeder Host es auch akzeptieren wird. (Viele tun's aber.) Da die Baudrate nur eine Zahl ist, die über den Bus zum Gerät 'rübergeschoben wird, kann man da im Prinzip beliebige Werte einstellen. Der Treiber auf PC-Seite muss sie halt kennen oder akzeptieren. (Die USB-Seite kann sie ggf. auch komplett ignorieren, siehe FT245.) Gehört daher wohl eher unter "PC-Programmierung". Ich würde es dahin verschieben.
da hast du wohl was reininterpretiert was nicht dasteht. Ich meine selbstverständlich die virtuellen Baudrates, welche man beispielsweise in HTerm auswählen kann, nicht die physikalische Taktrate auf dem USB. Der windowseigene Treiber erlaubt jedoch nicht die Verwendung von Baudrates welche auch nur annährend an das theoretische Maximum einer Full-Speed USB Verbindung herankommen. Was wahrscheinlich mit der implementierung und der verwendeten Transferart zusammenhängt, oder es ist nur historisch bedingt, das hab ich noch nicht herausgefunden.
Chris S. schrieb: > Der windowseigene Treiber erlaubt jedoch nicht die Verwendung von > Baudrates welche auch nur annährend an das theoretische Maximum einer > Full-Speed USB Verbindung herankommen. Kann es sein, dass dem die zulässigen Baudraten durch das INF-File vorgegeben werden?
Hallo,
ich weiss nicht woher die Vorredner ihre Informationen haben, aber mit
dem CDC erreicht man die die gleichen Datenraten wie bei den genannten
("echten" ???) Chips mit proprietären Treibern.
Εrnst B✶ schrieb:
> einen "echten" FT232, CP210*, PL2303, ...
Ich hab hier mehrere Aufbauten (Atmega32u4, LPC2148 ... ) mit
integrierten Full-Speed USB und CDC am laufen. Alle schaffen 2,5Mb
(MegaBits)) locker.
Getestet und gemessen mit HTERM.
Alle anderen Aussagen sind ..., ja woher ???
Jörg Wunsch schrieb: > Chris S. schrieb: >> Der windowseigene Treiber erlaubt jedoch nicht die Verwendung von >> Baudrates welche auch nur annährend an das theoretische Maximum einer >> Full-Speed USB Verbindung herankommen. > > Kann es sein, dass dem die zulässigen Baudraten durch das INF-File > vorgegeben werden? den Gedankengang hatte ich auch, hab allerdings im inf file nix gefunden was diese Vermutung bestätigen würde, daher hatte ich das wieder verworfen. Ich werd mich mal schlau machen, ich hoff mal google ist nett zu mir =)
Chris S. schrieb: > ich hoff mal google ist nett > zu mir =) Wenn du Zeugs für Windows suchst, kann es sich zuweilen auch lohnen, bei msdn[.microsoft.com] danach zu gucken.
Stefan ++ schrieb: > Ich hab hier mehrere Aufbauten (Atmega32u4, LPC2148 ... ) mit > integrierten Full-Speed USB und CDC am laufen. Alle schaffen 2,5Mb > (MegaBits)) locker. > Getestet und gemessen mit HTERM. Was hast du auf Windowsseite tun müssen um die 2,5Mbit/s erreichen/einstellen zu können? Und warum nur 2,5Mbit/s, ist das eine protokoll bedingte Obergrenze für CDC bei Full-Speed USB? denn Bulk transfer soll ja theoretisch bis 1,2MB/s (MegaByte) gehn, bei freiem Bus.
Stefan ++ schrieb: > ich weiss nicht woher die Vorredner ihre Informationen haben, aber mit > dem CDC erreicht man die die gleichen Datenraten wie bei den genannten > ("echten" ???) Chips mit proprietären Treibern. Bevor der verwendete µC genannt wurde, bin ich von der hier sehr oft AVR-CDC Lösung ausgegangen. Die ist langsam. Stefan ++ schrieb: > Alle schaffen 2,5Mb > (MegaBits)) locker. s.O. über LowSpeed USB am V-USB AVR geht das nicht. Jörg Wunsch schrieb: > Kann es sein, dass dem die zulässigen Baudraten durch das INF-File > vorgegeben werden? Die sind ja mehr oder weniger egal. Wenn der PC einen Request zum Ändern der Baudrate an den µC schickt, kann der ja einfach ein "OK" zurückmelden, und braucht deswegen noch nicht künstlich die Bremse einzulegen. Jörg Wunsch schrieb: > Nö, Low-Speed muss nur zwei Endpunkte unterstützen, CDC braucht aber > drei (weil noch ein Interrupt-EP dabei ist). IIRC durfte Low-Speed kein Bulk (und ISO) unterstüzen, weil dann ein Bulk-Transfer solange dauern könnte, dass die Interrupt-Transfer-Zeitgarantie für am selben HUB steckende andere Geräte nicht eingehalten werden kann.
Hallo, Chris S. schrieb: > Was hast du auf Windowsseite tun müssen um die 2,5Mbit/s > erreichen/einstellen zu können? einfache Antwort: Nichts! Vielleicht noch dazu: ich ignoriere die Baudrateneinstellung im Controller! Chris S. schrieb: > Und warum nur 2,5Mbit/s, ist das eine > protokoll bedingte Obergrenze für CDC bei Full-Speed USB? denn Bulk > transfer soll ja theoretisch bis 1,2MB/s (MegaByte) gehn, bei freiem > Bus. Zu dem Wert ist anzumerken, dass man die theoretische Grenze von 12Mb/s nie erreichen wird, das ist nur die Übertragungsrate auf dem USB-Bus selbst. Die Daten müssen sowohl im PC als auch im Controller verarbeitet werden (Treiber + Terminalprogramm) und der USB-Bus selbst ist auch nie ganz frei. Da läuft ständig irgendeine Pollerei! Z.B. mit ZOC als Terminalprogramm erreiche ich die 2,5Mb/s nicht!
Stefan ++ schrieb: > Zu dem Wert ist anzumerken, dass man die theoretische Grenze von 12Mb/s > nie erreichen wird, das ist nur die Übertragungsrate auf dem USB-Bus > selbst. > Die Daten müssen sowohl im PC als auch im Controller verarbeitet werden > (Treiber + Terminalprogramm) und der USB-Bus selbst ist auch nie ganz > frei. Da läuft ständig irgendeine Pollerei! > Z.B. mit ZOC als Terminalprogramm erreiche ich die 2,5Mb/s nicht! Das kann man so nicht stehn lassen, nachher glaub noch jemand das bei USB 70% der Transferrate für Overhead drauf geht. Mir ist bewusst dass du das nicht mit deinem Text aussagen wolltest, aber das steht halt leider so da. Von den 12Mbit/s Nettodatenrate bleiben nach Abzug des USB Protokolloverheads für Bulktransfer noch ca. 9,6Mbit/s übrig. Selbstverständlich vorausgesetzt da klaut einem nicht grad jemand Datenrate weil er den Bus mit der Übertragung von unzüglichen Filmen auslastet. Diese Datenraten sind mit einem USB-Masstorage Device auch praktisch erreichbar, mal abgesehn von wenigen Prozent die für anderes Gedöns draufgehn. Warum das bei CDC einscheinen nicht erreichbar ist, hängt vermutlich mit dem Protokoll zusammen. Da ich das protokoll nicht kenne will ich allerdings keine weiteren Vermutungen anstellen. Für konkrete Begründungen dieser scheinbaren Grenze würd ich mich freuen. Ist eine Übertragung mit höheren theoretischen Baudraten garnicht möglich oder treten "nur" Fehler auf während den Übertragungen?
Chris S. schrieb: > Ist eine Übertragung mit höheren theoretischen Baudraten garnicht > möglich Warum sollten sie nicht möglich sein? Es existiert ja nichts, was die Geschwindigkeit auf die Baudrate begrenzt, *außer du baust es selber ein*. Wenn du den VCP auf 300 Baud konfigurierst, dann kriegt dein Gerät die freundliche Anfrage, doch bitte 300 Baud zu verwenden. Ob du das dann tust oder es ignorierst ist deine Sache.
Εrnst B✶ schrieb: > Chris S. schrieb: >> Ist eine Übertragung mit höheren theoretischen Baudraten garnicht >> möglich > > Warum sollten sie nicht möglich sein? Es existiert ja nichts, was die > Geschwindigkeit auf die Baudrate begrenzt, *außer du baust es selber > ein*. > > Wenn du den VCP auf 300 Baud konfigurierst, dann kriegt dein Gerät die > freundliche Anfrage, doch bitte 300 Baud zu verwenden. Ob du das dann > tust oder es ignorierst ist deine Sache. Da einer meiner Vorredner meinte dass bei seinen Full-Speed Geräten bei 2,5MBit/s Schluss ist. Meine Frage bezog sich nur darauf was passiert wenn man versucht schneller zu übertragen. Aber dank deiner Aussage hat sich meine Frage wohl beantwortet.
Εrnst B✶ schrieb: > Bevor der verwendete µC genannt wurde, bin ich von der hier sehr oft > AVR-CDC Lösung ausgegangen. Die ist langsam. Naja, "die AVR-CDC-Lösung" ist zu allgemein: du hattest VUSB im Kopf. Ich würde mit AVR-CDC eine Lösung auf Basis AT90USB1287 erstmal assoziieren. ;-) >> Kann es sein, dass dem die zulässigen Baudraten durch das INF-File >> vorgegeben werden? > > Die sind ja mehr oder weniger egal. Kann sein, muss nicht. Ehrlich gesagt, bin ich jetzt auch etwas verwirrt, was Chris' Problem nun eigentlich ist. Du hast natürlich dahingehend Recht, wenn auf der Seite des USB-Geräts gar keine echte serielle Verbindung dahinter ist, dann kann mir der Host ja zehnmal erzählen, dass ich auf 9600 Bd konfiguriert wäre, er wird mich trotzdem nicht daran hindern, ihm die Daten mit 500 KiB/s aufzuhalsen. >> Nö, Low-Speed muss nur zwei Endpunkte unterstützen, CDC braucht aber >> drei (weil noch ein Interrupt-EP dabei ist). > IIRC durfte Low-Speed kein Bulk (und ISO) unterstüzen, weil dann ein > Bulk-Transfer solange dauern könnte, dass die > Interrupt-Transfer-Zeitgarantie für am selben HUB steckende andere > Geräte nicht eingehalten werden kann. OK, kann natürlich auch sein. Allerdings würde dann der übliche Ansatz "nimm doch HID" auch nicht sinnvoll funktionieren, denn ein Interrupt-EP kann ja nur vom Gerät zum Host gehen, man bekäme damit also keinen Kanal vom Host zum Gerät. Oder habe ich jetzt was verdreht?
ja bei meinen fragen und äusserungen bin ich etwas hin und her gedriftet. Grundproblem: Wie schnell kann ich mit CDC daten übertragen? maximale Obergrenze die mit Full-Speed USB möglich ist. Unterpunkte gibt es viele: Woher kommen die Probleme? Gibt es Konsequenzen oder Restriktionen mit denen man leben muss wenn man an der Obergrenze arbeiten will und welche wäre dies? Gibt es bessere Alternative? ..... Aber momentan geht es erstmal nur um mein Grundproblem. Ich versuch auch grade die Beispielapplikation so umzuschreiben das sie fullspeed Daten sendet. Dann müsste ich nurnoch aufzeichnen wie schnell sie tatsächlich am PC ankommen und verifizieren (so gut es geht und sinnvoll ist) woher diese Grenze kommt.
Habe auch festgestellt, dass eine CDC-Implementierung langsamer ist als bulk-Transfers z.B. per libusb. Bei mir unter Linux sind es ca Faktor 3-4, also ca 250 kiB/s per cdc und über 800 kiB/s per reinem bulk. Gemessen auf einem AT91SAM7S unter verschiedenen Programmiersprachen mit Zeitmessung für größere Blöcke. Als Ursache vermute ich, dass die zusätzlichen Treiberschichten beim Zugriff über /dev/tty* und dann nach USB-Bulk nicht auf höchsten Durchsatz ausgelegt sind. Vom und zum Gerät selbst ist es nämlich wieder ein ganz normaler Bulk-Endpoint, der bekanntlich nahe an das theoretische Limit herankommt...
Ok, da ich mit CDC wohl in eine Sackgasse gerate wenn ich die geschwindigkeit der Full-Speed USB Verbindung ausreizen will, stoß ich an dieser Stelle nochmal das Thema an auf der Suche nach neuen Ansätzen. Ich muss mit meinem Gerät kommunizieren können und Daten (100te MB an sensordaten) so schnell wie möglich auslesen. Hostseitig soll so wenig wie möglich gemacht werden um mit möglichst wenig Aufwand möglichst viele Betriebssysteme zu unterstützen (Windows, Linux, Android (ab 3.1)....) Wäre ein Kombigerät aus USB-MSD (Massstoragedevice) und CDC Virtual Com Port realisierbar? oder läuft es eher auf ein VUD (Vendor Unique Device) hinaus mit eigenem Hosttreiber? Für Vorschläge und Erfahrungsberichte bin ich immer offen. Für alle die den Rest des Thread nicht gelesen haben, meine plattform ist ein EFM32GG... mit integriertem Full/Low-Speed USB controller, 48MHz Takt und Cortex-M3 Kern.
habe den AT91SAM7S256 mit 4.000.000 Baud auf VCOM laufen. Funzt mit Windows (atmel driver) als auch Linux (usbserial).
Mit einem Mass-Storage-Device kannst Du nur Daten übertragen, die sich während der Verbindung mit dem Host nicht ändern. Das eignet sich z.B. um den Speicher eines Datenloggers auszulesen, nicht aber, um die Datenloggerfunktion selbst zu implementieren. Der Grund ist der, daß ein Mass-Storage-Device ein Massenspeicher ist, dessen Dateisystem vom Host verwaltet wird. Ein gleichzeitiger Zugriff auf diesen Massenspeicher von zwei Seiten aus ist nicht vorgesehen; der Host bekommt nicht mit, wenn das Gerät von sich aus im Dateisystem liegende Daten verändert, was zu netten aber nicht hilfreichen Effekten führen kann. Mit dem CDC bist Du, wenn Du möglichst ohne gerätespezifische Devicetreiber auskommen möchtes, am besten bedient. Allerdings muss Du gerätespezifische Datenerfassungssoftware liefern, und die muss mit der virtualisierten seriellen Schnittstelle sinnvoll umgehen können; die meisten Probleme, die es mit VCOM gibt, sind an genau dieser Stelle zu finden. Muss es denn unbedingt USB sein? Höhere Datenraten und eine treiberlose Funktionalität bekommst Du mit Ethernet.
Rufus Τ. Firefly schrieb: > Der Grund ist der, daß ein Mass-Storage-Device ein Massenspeicher ist, > dessen Dateisystem vom Host verwaltet wird. Aber ich kann doch trotzdem den uC so programmieren, dass er bestimmte Daten zurückgibt, wenn eine bestimmte Adresse des Massenspeichers gelesen wird. Rufus Τ. Firefly schrieb: > Mit einem Mass-Storage-Device kannst Du nur Daten übertragen, die sich > während der Verbindung mit dem Host nicht ändern. Dann könnte ich auch "neue Daten" übertragen.
Rufus Τ. Firefly schrieb: > Mit einem Mass-Storage-Device kannst Du nur Daten übertragen, die sich > während der Verbindung mit dem Host nicht ändern. Das eignet sich z.B. > um den Speicher eines Datenloggers auszulesen, nicht aber, um die > Datenloggerfunktion selbst zu implementieren. > > Der Grund ist der, daß ein Mass-Storage-Device ein Massenspeicher ist, > dessen Dateisystem vom Host verwaltet wird. Ein gleichzeitiger Zugriff > auf diesen Massenspeicher von zwei Seiten aus ist nicht vorgesehen; der > Host bekommt nicht mit, wenn das Gerät von sich aus im Dateisystem > liegende Daten verändert, was zu netten aber nicht hilfreichen Effekten > führen kann. Das Aufzeichnen der Daten kann man ja automatisch Beenden bei Verbindung mit einem Host. Allerdings würde ich gerne noch die Möglichkeit haben Befehle zu senden, das ist mit einem MSD wahrscheinlich nicht möglich, daher die idee eines Kombigerätes welches beide Schnittstellen beinhaltet, allerdings hab ich in die Richtung noch nichts gemacht, sondern nur gelesen das es sowas gibt. > Mit dem CDC bist Du, wenn Du möglichst ohne gerätespezifische > Devicetreiber auskommen möchtes, am besten bedient. Allerdings muss Du > gerätespezifische Datenerfassungssoftware liefern, und die muss mit der > virtualisierten seriellen Schnittstelle sinnvoll umgehen können; die > meisten Probleme, die es mit VCOM gibt, sind an genau dieser Stelle zu > finden. Das wäre kein Problem, allerdings soll es wohl nicht möglich sein mit CDC auch nur annähernd an die praktisch realisierbare maximale Datenrate von Bulktransfer herran zu kommen. > > Muss es denn unbedingt USB sein? Höhere Datenraten und eine treiberlose > Funktionalität bekommst Du mit Ethernet. Den uC den ich verwende/verwenden will gibt es mit integriertem USB-controler. Die Datenrate von 1MB/s wäre ausreichend wenn ich da herrankomme. Ein Gerät mit USB Anschluss kann man sogar einem Kaufmann in die Hand drücken und er weis was er damit tun soll. Man könnte das Gerät auch mit mobilen Geräten wie Handys und Tables verbinden (wenn man es entsprechend implementiert). Ich muss auch zugeben das ich nicht erwartet hatte bei der Suche nach der richtigen Klasse auf Problem zu stoßen.
Kan asta schrieb: > Aber ich kann doch trotzdem den uC so programmieren, dass er bestimmte > Daten zurückgibt, wenn eine bestimmte Adresse des Massenspeichers > gelesen wird. Schon, aber davon weiß der Host nichts, der bei wiederholtem Lesen desselben Datenblocks durchaus aus seinem internen Cache lesen wird und nicht immer wieder vom USB-Massenspeicher. Klar, man kann das Caching abschalten, aber dann wandert man immer mehr in die Nähe einer Frickellösung. Chris S. schrieb: > Die Datenrate von 1MB/s wäre ausreichend wenn ich da > herrankomme. Was sind "1MB"? 1 MBit oder 1 MByte? > Ein Gerät mit USB Anschluss kann man sogar einem Kaufmann > in die Hand drücken und er weis was er damit tun soll. Ja. Er schließt es an seinen PC/sein Tablet/wasauchimmer an, und kann damit nichts weiter anfangen, weil die das Gerät ansteuernde Auswertungssoftware fehlt. Wenn die sowieso installiert werden muss, dann kann die auch sehr wohl Netzwerkgeräte oder was auch immer ansteuern. Ein Mobilgerät (egal ob Tablet oder Telephon) kann mit Deinem Gerät gar nichts anfangen, auch wenn es eine Standardgeräteklasse implementiert -- denn was soll es mit den Daten anfangen, die es empfangen könnte? Ohne Auswertungs- oder wenigstens Erfassungssoftware ist das nicht sehr sinnvoll. Und das ändert sich nicht, ob Du nun eine Standardgeräteklasse wie CDC, MSD oder was auch immer verwendest. Was willst Du überhaupt erreichen? Vielleicht liegen Deine Probleme eher im konzeptionellen Bereich?
Chris S. schrieb: > Das Aufzeichnen der Daten kann man ja automatisch Beenden bei Verbindung > mit einem Host. Allerdings würde ich gerne noch die Möglichkeit haben > Befehle zu senden, das ist mit einem MSD wahrscheinlich nicht möglich, > daher die idee eines Kombigerätes welches beide Schnittstellen > beinhaltet, allerdings hab ich in die Richtung noch nichts gemacht, > sondern nur gelesen das es sowas gibt. Geht schon mit MSD (ist nur nicht mehr so einfach) Grob umrissen: Das Gerät liefert immer eine feste Dateisystem-Struktur (FATxx, je nach Datenmenge, Dateien liegen somit immer an festen Sektoren), egal was passiert. Bspw. eine Datei in die Konfigurationsdaten geschrieben werden können und eine in der die Daten stehen, kein Speicherplatz mehr frei. Lesezugriffe liefern die festen Sektoren bzw. die gespeicherten Daten und Konfigurationsdaten.. Schreibzugriffe auf Sektoren des Directories etc. werden ignoriert, bei den Sektoren in denen die Steuer/Konfigurationsdaten stehen, muss man aufpassen bspw. indem überprüft wird, ob alle Sektoren geschrieben wurden und/oder das Prüfsummen passen etc. Wenn die Zeitstempel aktualisiert werden funktioniert auch einfaches Kopieren problemlos ansonsten sollte unter Win bspw. mit
1 | HANDLE h = CreateFile(fileName GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_NO_BUFFERING | FILE_FLAG_WRITE_THROUGH, NULL); |
2 | WriteFile/ReadFile |
geschrieben/gelesen werden. Funktioniert, wie oben schon erwähnt, natürlich nicht wenn man bspw. auf eine SD-Karte schreibt bzw. das Gerät mehr oder weniger nur ein Kartenleser ist. Andere Möglichkeiten das schon aufgegebene CDC, libusb, WinUSB oder MTP (aufwendig) (theoretisch auch die Test & Measurement Class).
Rufus Τ. Firefly schrieb: > Ein Mobilgerät (egal ob Tablet oder Telephon) kann mit Deinem Gerät gar > nichts anfangen, auch wenn es eine Standardgeräteklasse implementiert -- > denn was soll es mit den Daten anfangen, die es empfangen könnte? Ohne > Auswertungs- oder wenigstens Erfassungssoftware ist das nicht sehr > sinnvoll. Und das ändert sich nicht, ob Du nun eine Standardgeräteklasse > wie CDC, MSD oder was auch immer verwendest. > > Was willst Du überhaupt erreichen? Vielleicht liegen Deine Probleme eher > im konzeptionellen Bereich? natürlich brauch man man eine software auf dem Host, das sollte wohl selbstverständlich sein. Eine Windowssoftware existiert bereits, allerdings für ein älteres Gerät mit FTDI usb-controller welcher per uart am conroller hängt (älterer, langsamerer, mehr strom verbrauchender controller). USB will ich verwenden weil ich theoretisch irgendwann mal in mein handy rammen kann, und standardklassen wären mir lieber damit ich nicht für jedes OS einen Treiber schreiben muss. Um eine Hostsoftware welche auf allen geräten läuft komm ich natürlich nicht herum, aber witzig ist der gedanke das es möglich wäre =D Ich beschränke mich bei meiner Fragestellung und der Erklärung drum rum auf ein spezielles Problem. Wie implementiere ich am sinnvollsten mein USB-Slave Gerät unter den erwähnten Bedingungen? Mit dem Rest drum rum komm ich schon klar. Ob die implementierung auf dem uC aufwendig ist, ist erstmal total egal, solange der Weg der richtige ist. Ich suche dabei nicht den einfachsten Weg, sondern nach der Lösung mit der ich glück bin wenn sie realisiert ist und mit der ich möglichst wenige oder keine Kompromisse eingehen muss. Ich hätte gerne: - 1MByte/s Datenrate beim auslesen der Daten einer externen SD-Karte die am SPI Bus des Controller hängt (maximal 24MHz Spi-clock vom conroller) - einfache Befehle senden können (Host -> Slave) und darauf Antworten (Slave -> Host) - eine Lösung die mit Windows, Linux und Android (je mehr je besser) kompatibel ist unter berücksichtigung des Aufwandes der nötig ist um diese Kompatiblität auf Hostseite herzustellen (Treiber schreiben, bzw. Standardklassen verwenden) Was ist der Richtige weg, oder wo muss ich Kompromisse eingehen? Wenn ihr Ideen habt aber nicht sicher seit ob sie alle Anforderungen erfordern, bitte postet sie trotzdem, und erwähnt wo ihr euch nicht sicher seit. Ich möchte mich an dieser Stelle mal dafür bedanken das einige so eifrig versuchen mir zu helfen. Ich werde in Zukunft versuchen besser im vorhinein klar zu machen das ich professionellen Rate suche und keinen Tip für ein Bastelprojekt neben der Ausbildung.
> Andere Möglichkeiten das schon aufgegebene CDC, libusb, WinUSB oder MTP > (aufwendig) (theoretisch auch die Test & Measurement Class). Mit einer speziellen lib, wie libusb, wäre ich wieder weg von der Universallösung welche auch für Android kompatibel wäre, oder? Mit CDC erreich icht nicht die Geschwindigkeiten die mir vorschweben. korrigiert mich wenn ich irgendwo falsch liege, bin ja noch relativ neu im USB Bereich und würde daher mein Wissen noch nicht als fundiert bezeichnen ;-)
Arc Net schrieb: > Funktioniert, wie oben schon erwähnt, natürlich nicht wenn man bspw. auf > eine SD-Karte schreibt bzw. das Gerät mehr oder weniger nur ein > Kartenleser ist. Wieso funktioniert die Idee einer config Datei nicht bei der Verwendung einer SD Karte als Speichermedium?
Kan asta schrieb: > habe den AT91SAM7S256 mit 4.000.000 Baud auf VCOM laufen. Funzt mit > Windows (atmel driver) als auch Linux (usbserial). Dann aber nicht als CDC, sondern als Emulation von einem anderen USB->RS232-Chip? Welchem? CDC unter windows hätte nicht den atmel treiber, und unter linux den cdc_acm Treiber. Wenn tatsächlich die PC-Seitigen CDC-Treiber für das Ausbremsen sorgen, wäre es vielleicht ein gangbarer Weg, einen FT232 o.Ä. zu emulieren. Mit der Gefahr, das irgendein Treiber-Update von FTDI das zerschießt.
Εrnst B✶ schrieb: > Mit > der Gefahr, das irgendein Treiber-Update von FTDI das zerschießt. und genau da liegt wieder das Problem. Ich weis das ich die Eierlegendewollmilchsau suche, aber sonst wär ich nachher auch selber nicht zufrieden mit meiner Arbeit. Nochmal ein Denkanstroß mit dem sich vielleicht jemand auskennt. Mein schlaues USB Buch behaupt: "Massenspeichergeräte verwenden Bulk-Transfers für den Austausch von Datein. Für den Austausch anderer Inforamtionen kann ein Gerät eines von zwei Transportprotokollen verwenden: Bulk-only oder CBI (Control/Bulk/Interrupt)" Der Inforamtionsaustausch läuft auf Basis einer definierten Strucktur (CBW). Gibt es Erfahrungen in die Richtung?
Ich hab mal ein bischen mit CDC gebenchmarkt: Host ist ein Linux-PC (Athlon 64 X2) mit cdc_acm, verbunden über einen USB2.0 HUB an das Device, ARMv7@1GHz, embedded-Linux, mit usb-gadget-Treiber. Senden von PC->CDC-Device:
1 | Summary for /dev/zero -> /dev/ttyACM0: |
2 | dd_rescue: (info): ipos: 356608.0k, opos: 356608.0k, xferd: 356608.0k |
3 | errs: 0, errxfer: 0.0k, succxfer: 356608.0k |
4 | +curr.rate: 15258kB/s, avg.rate: 15228kB/s, avg.load: 9.6% |
(Ja, das sind über 14 MegaBYTE pro Sekunde) Also: Probier halt CDC mal aus.
Εrnst B✶ schrieb: > Ich hab mal ein bischen mit CDC gebenchmarkt: > > Host ist ein Linux-PC (Athlon 64 X2) mit cdc_acm, verbunden über einen > USB2.0 HUB an das Device, ARMv7@1GHz, embedded-Linux, mit > usb-gadget-Treiber. > ... > (Ja, das sind über 14 MegaBYTE pro Sekunde) > Also: Probier halt CDC mal aus. 14MByte/s bei einem High Speed USB mit theoretischer maximaler Nettodatenrate von 53MByte/s passt recht gut zu den vorherigen Angaben von 2,5Mbit bei einem Full-Speed USB mit theoretischer maximaler Nettodatenrate von 9,6Mbit/s. Da scheint wohl wirklich einiges an Overhead zu sein, oder ine Protokollbedingte prozentualle Begrenzung der Datenrate. Aber ich werds so bald wie möglich selber mal testen mit meinem Device. Umgeschrieben ist es schon das es fleißig daten sendet, allerdings noch nicht optimiert und nocht nichts auf Hostseite welches die Datenrate misst, oder mit timestamp aufzeichnet. vielleicht nehm ich hterm, oder schreib mir schnell selber was, soll ja nur eine Abschätzung werden ob ich auf die selben Ergebnisse komme.
Chris S. schrieb: > Arc Net schrieb: >> Funktioniert, wie oben schon erwähnt, natürlich nicht wenn man bspw. auf >> eine SD-Karte schreibt bzw. das Gerät mehr oder weniger nur ein >> Kartenleser ist. > > Wieso funktioniert die Idee einer config Datei nicht bei der Verwendung > einer SD Karte als Speichermedium? Es kommt drauf an wie das implementiert ist: Werden die Befehle, die über USB kommen (ReadCapacity, SectorSize, MediaDetect, SectorRead, WriteProtectState, SectorWrite und MediaInitialize) direkt an die Speicherkarte weitergeleitet, muss das Gerät 1. das FAT-Dateisystem implementieren und 2. müsste es - und u.a. das geht nicht - auch Datei-Locks o.ä. implementieren können, damit sich Host und Gerät nicht in die quere kommen. Wenn die Karte fest eingebaut ist und nicht bspw. extern ausgelesen/beschrieben werden kann, könnte man, wie oben grob umrissen, die Zugriffe abfangen und passend machen. Kurz gesagt: Das Problem ist, das die MSD-Klasse nichts von Dateisystemen "weiß". Die MTP-Klasse abstrahiert und vereinfacht das (Android (http://developer.android.com/reference/android/mtp/package-summary.html), Linux und Windows unterstützen das mehr oder weniger direkt, die PC-Anwendung könnte afaik sowohl unter Linux, als auch Windows libmtp für den Zugriff verwenden) http://en.wikipedia.org/wiki/Media_Transfer_Protocol http://www.usb.org/developers/devclass_docs/MTPv1_1.zip
libusb gibts auch für Android und damit kommst Du dann zumindest mit Bulk-Transfers in die Nähe des Gewünschten.
Usb Massstorage macht die Synchronisierung zwischen den beiden Peers schwierig.
Ich würde auch LibUSB empfehlen, da kannst du auf allen von dir gewünschten Platformen arbeiten.
Hi, so richtig schlau werde ich nicht aus deinen Vorgaben, aber eine SD-Karte schreit förmlich nach einem MSD. Sobald der USB dann enumeriert hat wird die Logger funktion abgeschaltet und der PC hat exklusiven Zugriff. Wenn der PC abgestöpselt ist, darf Dein Mikrocontroller wieder ran. Dazu noch ein HID-Interface für Steuersignale. Zuerst wird beides getrennt implementiert und getestet. Danach als Verbundgerät zusammen gefasst. Gruß Potter
Ich fass mal kurz zusammen wenns recht ist: - Media Transport Protocol (MTP) - Massstorage Device (MSD) - Massstorage Device + HID als Kombigerät - libUSB meine Drei Hauptanforderungen (hohe Datenrate, Schnittstelle um Befehle zu senden/empfangen und Kompatiblität für mindestens Windows, Linux und Android) biete alle. Muss ich also "nurnoch" entscheiden welches die beste Lösung ist. Tut mir echt leid das ich noch mehr Fragen stellen muss, ich bin bereits auf der Suche nach Antworten auf folgende Fragen, allerdings ist USB ein derart umfangreiches Thema, zu dem es sooo viel an Informationen (sinnvoll und sinnfrei) gibt, dass es sich echt schwierig gestalltet die Infos rauszusuchen die für meinen speziellen Fall interessant sind. kann man die libUSB variante auch ohne Adminrechte durchführen? Also wenn das Gerät mal fertig ist, und die zugehörige PC-software existiert, kann eine Person ohne Adminrechte an seinem PC das Gerät verwenden oder könnte er auf Probleme treffen bei der Installion des Treibers oder bei der Verwendung? die MSD-Klasse beinhaltet einen Endpoint welcher zum Befehlsaustausch gedacht ist, die subclass definiert dabei den Befehlssatz. Windows unterstützt ATAPI-CD/DVD-Geräte, ATAPI-Wechselmedien und Generische SCSI-Medien als subclass. Könnte man einen der Befehlssätze für die Übertragung eigener Befehle "missbrauchen". Ich suche derzeit nach einem Java oder C# Beispiel, wie man einen solchen Befehlssatz verwendet. Die Suche war allerdings noch nicht sehr erfolgreich. bei MSD + HID wäre ich an einer Beispielimplementierung auf Controller seite interessiert, hab allerdings aus Zeitgründen selber noch nicht danach gesucht. Von MTP hab ich noch am wenigsten Ahnung, da werd ich erst noch versuchen mich selber schlau zu machen, bevor ich sinnfrei Fragen stelle.
libUSB unter Linux geht ohne Admin-Rechte, wenn die device-node mit entsprechenden Rechten angelegt wird. eigene udev-rule, Benutzer in die Plugdev-Gruppe usw. d.H. das Installieren der Software muss mit Root-Rechten geschehen, einfach ein tarfile im $HOME auspacken reicht nicht. Unter Windows: Keine Ahnung. Früher musste man IIRC 64-Bit-Windows sogar irgendwie "Jailbreaken", damit nicht signierte Kerneltreiber geladen werden durften. Ist das inzwischen anders? Vorteil libUSB: Kein anderer Treiber funkt dir dazwischen, und du kriegt volle Performance. MTP: Kann mir vorstellen, das es da viele Probleme mit ggfs installierter Fremdsoftware gibt, z.B. iTunes, WindowsMediaPlayer, ... die automatisch versuchen deine MP3-Sammlung auf den neuen Musikplayer zu synchen... Ansonsten umgeht das die Dateisystem-Problematik bei gleichzeitigem Zugriff (s.u.) elegant. MSD (mit oder ohne HID): Gute Lösung, wenn nicht gleichzeitig zugegriffen werden soll. d.H. entweder hat der PC über USB Zugriff auf die SD-Karte, oder der µC darf dran. Geht deshalb nicht, wenn der Datenlogger auch mit angestöpseltem USB-Kabel arbeiten soll. Würg-Arrounds, wie dem Windows-FAT-Dateisystemtreiber das Caching komplett zu verbieten, könnten vielleicht funktionieren, sind aber nicht portabel. Und wenn das Gerät an einem nicht entsprechend gepatchtem Rechner angestöpselt wird, ist halt schlimmstenfalls das Dateisystem kaputt und die Daten weg.
Unter Windows muss man den LibUSB Treiber natürlich mit Admin-Rechten einmalig installieren. Auch auf x64 ist das mittlerweile kein Problem mehr, denn der Treiber ist signiert, die nutzen das KMCS mit eingebetteter Signatur. Somit brauchst du nur das passende Inf File. Die Anwendungssoftware selber erfordert dann natürlich keine Admin-Rechte so wie jede gescheit geschriebene Windows Software, denn sie greift ja nur auf die LibUSB0.dll zu, eine User Mode DLL.
Besten dank, das hilft mir weiter =) Wie bereits erwähnt bin/war ich dabei das genannte Geschwindigkeitsproblem bei CDC selber nachzubilden. Zunächst hab ich das CDC beispiel des Chipherstellers umgeschrieben das die Callbackfunktion zum Senden der Daten sich selbst wieder aufruft wenn die USB Übertragung abgeschlossen ist und mir eine kleine C# Anwendung geschieben die einen COM-Port öffnen kann und die Geschwindigkeit der eingehenden Daten anzeigt. Mein erster Tets kam so auf eine Geschwindigkeit von ca. 250kByte/s +-50kByte/s denn die Auswertung ist sehr sehr rudimentär. Das passt ungefähr zu den genannten 2,5Mbit/s. Allerdings ist mir dann aufgefallen das die maximale puffer größe welche der USB-Write funktion übergeben wird auf 127 gesetzt ist, in den Descriptoren zu CDC stehlt allerdings 64*1023 als Obergrenze drin, daher hab ich an der stelle mal den Puffer erhöht und siehe da, meine C# Anwendung zeigt mir eine Geschwindigkeit von 1,1MByte/s als datenrate an. Die umgekehrte Richtung, also vom PC zum Controller habe ich nicht getestet, da ich schlecht feststellen kann ob die gesendeten daten zum controller auch wirklich ankommen. Und weil es für meine speziellen Fallen nicht wirklich relevant ist.
Chris S. schrieb: > Allerdings ist mir dann aufgefallen > das die maximale puffer größe welche der USB-Write funktion übergeben > wird auf 127 gesetzt ist, in den Descriptoren zu CDC stehlt allerdings > 64*1023 als Obergrenze drin, daher hab ich an der stelle mal den Puffer > erhöht und siehe da, meine C# Anwendung zeigt mir eine Geschwindigkeit > von 1,1MByte/s als datenrate an. Frage: WO hast du WAS erhöht ???
sorry das ich den thread doch nochmal in leben rufen muss, aber ich hab noch 2 Fragen die ich noch nicht beantworten konnte. Für ein USB-CDC Device benötigt man ein inf-File zur Treiberinstallation auf dem PC, auch wenn man nur den windowseigenen Treiber verwenden möchte, korrekt? Für diese Treiberinstallation benötigt man im Extremfall Adminrechte da es sich um einen unsegniertes inf-File handelt, auch korrekt oder kann man das ganze so realisieren das man auch ohne Adminrechte auf Windows-PC auskommt? (bei Linux scheint ja kein inf-File nötig zu sein) Die Alternative die ich verfolge ist USB-MSD + HID, was passiert wenn ich mehr meiner Geräte an den PC anschließe als es Laufwerkbuchstaben (A-Z) gibt? so dumm wie es klingt, aber dieser Fall könnte auftreten und nein, ich würde dies nicht an einem Android-Gerät versuchen. nur um das mal vorweg zu nehmen =) Danke schonmal für eure Hilfe und ein schönes Wochenende an alle die sich schon auf ihren Feierabend freuen.
Stefan ++ schrieb: > Chris S. schrieb: >> Allerdings ist mir dann aufgefallen >> das die maximale puffer größe welche der USB-Write funktion übergeben >> wird auf 127 gesetzt ist, in den Descriptoren zu CDC stehlt allerdings >> 64*1023 als Obergrenze drin, daher hab ich an der stelle mal den Puffer >> erhöht und siehe da, meine C# Anwendung zeigt mir eine Geschwindigkeit >> von 1,1MByte/s als datenrate an. > > Frage: WO hast du WAS erhöht ???
1 | /**************************************************************************//** |
2 | * @brief Callback function called whenever a UART receive DMA has completed. |
3 | * |
4 | * @param[in] channel DMA channel number. |
5 | * @param[in] primary True if this is the primary DMA channel. |
6 | * @param[in] user Optional user supplied parameter. |
7 | *****************************************************************************/ |
8 | static void DmaRxComplete(unsigned int channel, bool primary, void *user) |
9 | {
|
10 | (void) channel; /* Unused parameter */ |
11 | (void) primary; /* Unused parameter */ |
12 | (void) user; /* Unused parameter */ |
13 | |
14 | /* |
15 | * As nested interrupts may occur and we rely on variables usbTxActive |
16 | * and dmaRxActive etc, we must handle this function as a critical region. |
17 | */ |
18 | INT_Disable(); |
19 | |
20 | |
21 | USBD_Write(EP_DATA_IN, (void*) testarray, |
22 | (1023*64), DmaRxComplete); |
23 | |
24 | |
25 | INT_Enable(); |
26 | } |
die Funktion war im ursprünglichen beispiel dazu gedacht aufgerufen zu werden wenn vom Uart daten empfangen wurden, welche über usb (Virtueller Com port) wieder verschickt werden sollte. Der funktion USDB_Write über gebe ich den Funktionpointer DmaRxComplete um diese funktion aufzurufen wenn die USB Übertragung abgeschlossen ist. Auf diese Weise habe ich mir eine sendeschleife gebastelt, ist zwar nicht schön aber darum gings ja nicht. Der USB_Write Funktion wird neben dem Endpoint auch das zu sendende Array und seine länge übergeben. Diese länge war begrenzt auf 127 und ich habe diese erhöht auf 1023*64, da in den Descriptors drin steht das pro Transfer maximal 1023 Pakete und pro Paket maximal 64 Byte erlaubt sind.
Chris S. schrieb: > Für ein USB-CDC Device benötigt man ein inf-File zur Treiberinstallation > auf dem PC, auch wenn man nur den windowseigenen Treiber verwenden > möchte, korrekt? Nur Windows benötigt so eine Datei, alle anderen Betriebssysteme tun das nicht. Es gibt von manchen Herstellern von USB-fähigen µCs CDC-Beispielimplementierungen, denen eine passende signierte *.inf-Datei beiliegt. Die kannst Du auch mit einer anderen Lösung eines anderen Herstellers verwenden, solange Du dafür die zur *.inf-Datei passenden Vendor- und Product-IDs missbrauchst.
Rufus Τ. Firefly schrieb: > Die kannst Du auch mit einer anderen Lösung eines anderen Herstellers > verwenden, solange Du dafür die zur *.inf-Datei passenden Vendor- und > Product-IDs missbrauchst. danke, ist natürlich nicht das was ihr hören wollte, aber wann hat man schon das Glück das alles so funktioniert wie man sich das erträumt ;-)
Kauf dir halt eine Verisign ID für 99USD pro Jahr, dann kannst du das Cat File signieren. Die erste Installation benötigt aber trotzdem Admin Rechte.
Christian R. schrieb: > Kauf dir halt eine Verisign ID für 99USD pro Jahr, dann kannst du das > Cat File signieren. Die erste Installation benötigt aber trotzdem Admin > Rechte. benötigt die Installation mit signierten Treibern Adminrechte oder wie darf ich deine Antwort verstehen? dann würde eine mir eine Signierung ja keine Vorteile bringen, ausser das die Abfrage nichtmehr erscheint ob man den unsignierten Treiber wirklich installieren will, bzw. das man die Installation von unsignierten Treibern zulassen muss.
Ja, auch die Installation von signierten Treibern benötigt erstmalig Admin-Rechte. Dann aber nie wieder. Die Signatur hat in dem Fall nur für den Anwender den Vorteil, dass keine rote UAC Meldung kommt, sondern die blaue. Und man kann dann anklicken "Dem Hersteller xyz immer vertrauen". Ohne Admin-Rechte gehts nur wenn die Treiber schon vorinstalliert sind, beispielsweise durch DPInst oder aber wenn die Treiber schon von Windows mitgeliefert werden, also MSD, HID. Für eigene Treiber kannst du sie auch per WHQL testen lassen und dann per Windows Update verteilen lassen, dann brauchts auch keine Admin-Rechte. Da du ja aber wahrscheinlich deine Anwendung sinnvollerweie auch installieren musst, kannst du den Treiber gleich in den Installer mit rein packen. Ein signierter Treiber hat für den Kunden einen viel besseren Eindruck. Jedenfalls haben wir das bei uns gemerkt. Wir verwenden WinUSB mit signiertem Cat File.
Christian R. schrieb: > auch per WHQL testen lassen und dann per Windows Update verteilen > lassen, dann brauchts auch keine Admin-Rechte. dass das en bissel geld kostet hab ich schon gelesen, also bleiben folge Optionen: - unsegniertes inf-File (Adminrechte erforderlich) - segnieren lassen für 99USD/Jahr (Adminrechte einmalig erforderlich) - segniertes inf-File von jemand anderem verwenden (könnte Probleme mache machen wenn der Kunde auch das Gerät besitzt von dem ich das inf-File "ausgeliehen" habe) - WHQL Zertifizieren lassen für 99USD/Jahr + 250USD/Windowsversion - WHQL Zertifizierte VID und PID "missbrauchen" Im Endeffekt bleibt also die Wahl zwischen Geld ausgeben für CDC oder Geld ausgeben für die Entwicklungskosten eines MSD + HID Implementierung. Dafür das USB so toll sein soll geht es mir grad sehr auf den Sack xD
Christian R. schrieb: > signierter Treiber hat für den Kunden einen viel besseren Eindruck. > Jedenfalls haben wir das bei uns gemerkt. Wir verwenden WinUSB mit > signiertem Cat File. Wenn ich an der stelle noch eine ganz andere Frage stellen darf, woher habt ihr die eigene VID + PID? War der Chiphersteller nett oder habt ihr ordentlich geld im USB-IF liegen lassen?
Naja, wenn du so eine Verisign ID hast, kannst du damit auch alle andere Sofware signieren, Installer, Anwendungen usw. der Kunde freut sich. Ja wir haben eine eigene VID, hat damals ein anderer Unternehmens-Standort mal angeschafft. Wir haben da einen Block PIDs zugewiesen bekommen. VID/PID und/oder signierte Files "ausleihen" kann man höchstens in China oder im Bastlerbereich machen. USB an sich ist schon gut, aber eine VID muss man nun mal haben, anders gehts ja nicht. Und der Signatur-Kram ist halt eine MS-Erfindung. Müssen aber nicht Android-Anwendungen auch signiert sein?
Chris S. schrieb: > dass das en bissel geld kostet hab ich schon gelesen, also bleiben folge > Optionen: > - unsegniertes inf-File (Adminrechte erforderlich) > - segnieren lassen für 99USD/Jahr (Adminrechte einmalig erforderlich) > - segniertes inf-File von jemand anderem verwenden (könnte Probleme > mache machen wenn der Kunde auch das Gerät besitzt von dem ich das > inf-File "ausgeliehen" habe) > - WHQL Zertifizieren lassen für 99USD/Jahr + 250USD/Windowsversion > - WHQL Zertifizierte VID und PID "missbrauchen" Falls keine eigene USB-VID vorhanden ist, können, je nachdem von welchem Hersteller die USB-VID-Unterlizenz stammt, noch zusätzlich die Kosten für eine eigene USB-VID hinzukommen (2000 USD, bzw. 1000 USD/Jahr mit Logo-Lizenz). > Im Endeffekt bleibt also die Wahl zwischen Geld ausgeben für CDC oder > Geld ausgeben für die Entwicklungskosten eines MSD + HID > Implementierung. MSD + HID gibt es eigentlich von jedem MCU-Hersteller, das Protokoll, das über CDC oder HID läuft, wird sich nicht so stark unterscheiden, als das es ins Gewicht fallen sollte. > Dafür das USB so toll sein soll geht es mir grad sehr auf den Sack xD Das ist, würde ich mal sagen, normal...
Ich hatte nur gehört das manche Chiphersteller, auf Anfrage manchmal PIDs "verschenken", und da wir noch ein sehr junges unternehmen sind wäre das deutlich antsprechender als eine eigene VID, auch wenn diese natürlich einge Vorteile mit sich bringt und man fürs restliche leben genug PIDs hätte. was MSD + HID angeht, für beides hab ich jeweils ein beispiel vom chiphersteller, für ein kombigerät müsste ich diese ja nur "verheiraten" und die descriptors anpassen oder gibt es bei kombigeräten was spezielles zu beachten? ihr helft mir wirklich weiter, es gibt zu USB so viel das man wissen muss um dir richtigen Entscheidungen zu treffen, und vieles davon steht in den Büchern einfach nicht drin, oder auf eine Art die keinem hilf. Und im Internet findet man die nötigen infos nur wenn man eh schon weis wo nach man suchen muss.
PIDs verschenkt meines Wissens nur noch FTDI, aber unter der Voraussetzung dass du sie für deren Chips benutzt. Ihr werdet doch wohl mal 2000 USD haben.
Christian R. schrieb: > PIDs verschenkt meines Wissens nur noch FTDI, aber unter der > Voraussetzung dass du sie für deren Chips benutzt. Ihr werdet doch wohl > mal 2000 USD haben. Atmel und z.B. TI lassen die Verwendung der eigenen VID/PID zu (http://support.atmel.com/bin/customer.exe?=&action=viewKbEntry&id=220, http://www.ti.com/mcu/docs/mcuorphan.tsp?contentId=72713&DCMP=STELLARIS®ARM®CORTEX+Other&HQS=Other+OT+stellaris_usb_vidpid) Microchip bietet VID/PID-Unterlizenzen (http://ww1.microchip.com/downloads/en/AppNotes/Application%20for%20USB%20Vendor%20ID%20Sublicense.pdf) ebenso wie SiLabs (http://www.silabs.com/products/mcu/Pages/request-PID.aspx) NXP bietet sowas für die LPC11U00 (http://www.lpcware.com/content/project/usb-vid-pid-program) an > was MSD + HID angeht, für beides hab ich jeweils ein beispiel vom > chiphersteller, Mir fällt auf Anhieb keiner ein, der kein USB-Composite Beispiel hätte. Einfacher wäre es aber, wenn der Controller bekannt wäre...
efm32gg.. von energy micro, sry dacht das hät ich erwähnt
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.