Weiß jemand wie viel Strom ich maximal aus dem USB-Port ziehen kann, wenn ich daran einen Arduino Nano Klone mit dem CH430 USB-to-Serial IC angeschlossen habe? Da dieser IC kein USB Power Delivery unterstützt und der Chip auch nicht für USB 3.0 spezifiziert ist, kommt ja nur USB 1.0/2.0 Low Power (100mA) oder USB High Power (500mA) in Frage. Zwar steht etwas dazu in einem vermutlich mit Google Translator übersetztem Datenblatt auf Sparkfun, aber da wird nur gesagt, dass USB allgemein 500mA liefern kann. https://cdn.sparkfun.com/datasheets/Dev/Arduino/Other/CH340DS1.PDF So weit ich USB verstanden habe (und davon habe ich fast keinen Plan), bekommt jedes Device erst mal 100mA. Wenn es mehr will (High Power - also 500mA) muss man es das in 2mA Schritten vom Host Controller anfragen. Vermutlich kann es das auch wenn es weniger benötigt in 2mA Schritten. Ich nehme an, das übernimmt der Controller IC des Devices? Sprich der CH430? Daraufhin habe ich versucht in Windows im Gerätemanager zu suchen, wo ich denn die ausgehandelte Strombegrenzung finde - ohne Erfolg. Mit der Software USBDeview von Nirsoft konnte ich dann einen Wert von 98mA für CH430 finden. Das klingt erst mal recht wenig. Ich dachte 500mA wären beim Arduino Nano Klon schon möglich. Weiß jemand mehr? Für mich war USB immer schon ein Mythos. Irgendwie ein super universeller Bus, aber es ist allgemein öffentlich nur sehr wenig darüber zu finden. Es gibt zwar Spezifikationen, aber oft wird sich daran überhaupt nicht gehalten (Kabel, Ladegeräte für Handys, USB Host Controller, die mehr liefern können als 500mA)
Timo N. schrieb: > So weit ich USB verstanden habe (und davon habe ich fast keinen Plan), > bekommt jedes Device erst mal 100mA. Wenn es mehr will (High Power - > also 500mA) muss man es das in 2mA Schritten vom Host Controller > anfragen. Jein. Ein USB-Gerät, das nichts mit dem Host aushandelt, soll nicht mehr als 100mA nehmen. Ein Gerät, das etwas mit dem Host aushandelt, kann das in 2mA Schritten bis 500mA tun und sollte dann ebenfalls nicht mehr nehmen als ausgehandelt. Allerdings sind die meisten Hosts ausgesprochen relaxed, wenn es darum geht wie sie auf eine Überschreitung des Limits reagieren. In der Praxis habe ich bisher nur Geräte gesehen, die bei Überschreitung der 500mA den Port abschalten. Typischerweise Notebooks. Bei Desktop-PCs hängt USB-Power über eine Polyfuse (typisch 2A für 2 USB-Ports) direkt am 5V Strang vom Netzteil. Da kann man dann auch deutlich mehr als 500mA entnehmen. Konkret zu deiner Frage: bei mir meldet der CH340 (tatsächlich ein Arduino nano aus China) einen Strombedarf von 96mA an:
1 | ~ $lsusb -s 1:6 -v |
2 | |
3 | Bus 001 Device 006: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter |
4 | Device Descriptor: |
5 | bLength 18 |
6 | bDescriptorType 1 |
7 | bcdUSB 1.10 |
8 | bDeviceClass 255 Vendor Specific Class |
9 | bDeviceSubClass 0 |
10 | bDeviceProtocol 0 |
11 | bMaxPacketSize0 8 |
12 | idVendor 0x1a86 QinHeng Electronics |
13 | idProduct 0x7523 HL-340 USB-Serial adapter |
14 | bcdDevice 2.54 |
15 | ... |
16 | bmAttributes 0x80 |
17 | (Bus Powered) |
18 | MaxPower 96mA |
Das meinte ich mit mysteriös. Es wird ein Stromverbrauch angemeldet, aber dann macht es nichts, wenn dieser überschritten wird? Das erinnert ja an europäische Politik, bei der Regeln aufgestellt werden, die doch nicht eingehalten werden ;) Die Frage ist auch: Kann ich dem CH430 nun beibringen mehr als 96mA (du hast Recht, bei mir sind es auch 96mA und nicht 98mA) anzufragen? Wie sieht dies eigentlich bei den FTDI Chips aus? Und wie mache ich das bei USB 3.0 Geräten? Hat da irgendwer Infos im Netz, die man sich durchlesen könnte?
Timo N. schrieb: > Ich nehme an, das übernimmt der Controller IC des Devices? Sprich der > CH430? Siehe Datenblatt... Ich kenne das nur von FTDI Chips: Die haben tatsächlich einen IO Pin den man zum Einschalten der "restlichen" Hardware benutzen kann - wenn der Host die 500mA freigegeben hat. Übrigens interessiert sich in der Praxis kaum jemand für den Stromverbrauch, USB HDDs ziehen gerne mal 1A und mehr. Die ganzen USB Lampen, Tassenwärmer und Lüfter melden sich nicht am Bus an. Axel S. schrieb: > In der Praxis > habe ich bisher nur Geräte gesehen, die bei Überschreitung der 500mA den > Port abschalten. Typischerweise Notebooks. Auch das oftmals nur wenn sich die Geräte "anmelden", also USB Protokoll reden. Dort ist der maximale Strombedarf eins der ersten Dinge die ein USB Gerät an den Host sendet. Ich hatte hier mal den Fall das an einer 12-Geräte (a 500mA/Gerät) Lade-und-Daten-Box mal der Netzstecker nicht steckte und der dämlich designte USB Hub dann mal eben versucht hat 6A aus einem Netbook zu saugen. Da gab das Kabel Rauchzeichen! Abhilfe war übrigens Auftrennen der V_Bus vom Host mit 'nem Cutter beim ersten USB Hub.
Jim M. schrieb: > Siehe Datenblatt... Ja, das Datenblatt auf Englisch hilft leider Null. Das chinesische kommt mir Chinesisch vor ;) > Ich kenne das nur von FTDI Chips: Die haben tatsächlich einen IO Pin den > man zum Einschalten der "restlichen" Hardware benutzen kann - wenn der > Host die 500mA freigegeben hat. Und wie erreicht man, dass 500mA freigegeben werden. Wie stellt man das ein? > Übrigens interessiert sich in der Praxis kaum jemand für den > Stromverbrauch, USB HDDs ziehen gerne mal 1A und mehr. Hm. Sprich wenn der USB-Controller im Gerät nur 100mA anfordert, kann man trotzdem alles mögliche raus ziehen in der Praxis. Wie soll man so Geräte entwickeln, wenn man nicht weiß, wie viel man ziehen darf und wenn es bei jedem Host-Controller im PC unterschiedlich sein kann?
Timo N. schrieb: > Das meinte ich mit mysteriös. Es wird ein Stromverbrauch angemeldet, > aber dann macht es nichts, wenn dieser überschritten wird? Mein erster Laptop (mit USB Ports als PCMCIA Karte) hatte das noch beachtet. Wenn ein Gerät mehr Strom aufnahm, als es darf, kam nach einer Weile ein Popup Fenster mit einer Warnmeldung hoch, Da konnte ich dann entscheiden, ob ich es ignorieren oder abschalten will. Das war in den 90er Jahren. Danach habe ich nie wieder einen Rechner gesehen, der die Stromaufnahme überwacht. > Wie soll man so Geräte entwickeln, wenn man nicht weiß, > wie viel man ziehen darf Wie kann man da noch fragen? Wenn man Geräte entwickelt, dann hält man sich an die Spezifikation und nimmt nicht mehr Strom auf, als ausgehandelt wurde. Alles Andere führ potentiell zu einer hohen Retouren Quote. Das soll doch sicher nicht das letzte Produkt sein, dass du an den Markt bringst, oder?
Timo N. schrieb: > Hm. Sprich wenn der USB-Controller im Gerät nur 100mA anfordert, kann > man trotzdem alles mögliche raus ziehen in der Praxis. Wie soll man so > Geräte entwickeln, wenn man nicht weiß, wie viel man ziehen darf und > wenn es bei jedem Host-Controller im PC unterschiedlich sein kann? Wieviel man ziehen darf, steht in der USB-Spezifikation. Wieviel die verschiedenen Host-Controller im PC ggf. darüber hinaus tolerieren, ist für die Geräteentwicklung nicht relevant.
Naja, wir drehen uns jetzt aber im Kreis. Meine Frage war ja, wie ich die 500mA beim Host-Controller anfrage (mit dem CH430). Daran würde ich mich ja bei einer Geräteentwicklung halten. Wenn ich das nicht mache, müsste ich bei der Entwicklung nur von 100mA ausgehen. Eure Aussage war ja, dass es in der Praxis völlig egal ist, da der Port sowieso mehr bereitstellt. Gleichzeitig sagt ihr aber, dass ich mich an die Spezifikation halten sollte. Also: Sagen wir ich möchte mich an die Spec halten und 500mA mit dem CH430 vom Host-Controller anfragen. Wie geht das?
Timo N. schrieb: > Meine Frage war ja, wie ich die 500mA beim Host-Controller anfrage (mit > dem CH430). Laut dem Datenblatt hier: https://www.mpja.com/download/35227cpdata.pdf (auf Seite 4) hat der CH340 ein internes EEPROM, in dem Vendor-ID, Device-ID und eben auch der angeforderte Strom abgelegt sind. Zum Ändern dieses EEPROMs brauchst du ein spezielles Tool vom Hersteller. Für den CH340 konnte ich das auf die Schnelle nicht finden. Aber im Prinzip geht das. Andere USB-UART IC können ein externes EEPROM ansprechen oder es gibt das Tool frei verfügbar (z.B. für FTDI). > Eure Aussage war ja, dass es in der Praxis völlig egal ist, da der Port > sowieso mehr bereitstellt. Gleichzeitig sagt ihr aber, dass ich mich an > die Spezifikation halten sollte. Ja. Das ist der normale Unterschied zwischen Theorie und Praxis. In der Theorie darf ein USB-Host den aufgenommenen Strom des Geräts mA-genau messen und bei Überschreitung des ausgehandelten Limits den Port abschalten. In der Praxis wird bestenfalls das harte obere Limit von 500mA eingefordert und auch das nicht immer. Du hast jetzt die Wahl, ob du ein Gerät bauen willst, daß unter Garantie an allen Hosts funktionieren wird. Oder ob du eins bauen willst, das zwar an den meisten funktioniert aber wo du für nichts garantieren kannst. Deine Entscheidung. Und eigentlich nicht schwierig.
Timo N. schrieb: > Arduino Nano Klone mit dem CH430 USB-to-Serial IC Google nach CH430 zeigt "Cone crusher", Schwermaschinenbau, da ist die Versorgung sicherlich größer als 5 Volt. Da hälst hartnäckig über mehrere Beiträge an Deinem Zahlendreher fest :-( Axel S. schrieb: > bei mir meldet der CH340 (tatsächlich ein > Arduino nano aus China) einen Strombedarf von 96mA an In meinem Windows sehe ich im Gerätemanager drei Mäuse (tatsächlich angeschlossen) und den ChinaNano - alle vier sind mit 98mA angemeldet - scheint wohl eine Art Standardwert zu sein. Jetzt packe ich noch den LogiLink-CardReader dazu, der meldet sich als Massenspeicher mit 500mA an. An meinem Nano hängt einige Peripherie, real braucht der Aufbau um 180mA. Das interessiert meinen Desktop-PC aber garnicht, die 5V der beiden USB sind parallel (kann man im Layout sehen) und direkt aus 5 Volt versorgt. Mit einer elektronischen Last ohne Anmeldung habe ich bei 2,5 A aufgehört, wollte keinen Schaden riskieren. Ich hatte den Arduinoaufbau zuvor an meinem Netbook, auch dem war das egal, es hat einfach versorgt. Ich habe keine Ahnung, ob es aktuell noch Rechner gibt, die den Strom abdrehen - zuletzt habe ich das an einem Toshiba-Laptop mit 333 MHz-CPU erlebt.
Ah ok. Das mit den Zahlendreher hab ich leider gar nicht bemerkt. Das ist halt leider manchmal so, bis man darauf aufmerksam gemacht wird. Danke erstmal. Fazit: Man kann irgendwie mit einem EEPROM Programmer den Wert vom CH340 ändern, aber da gibt es nicht so viele Infos dazu, wie das konkret geht (da China-Hersteller WCH). Vom CH340 gibt es noch dazzu verschiedene Versionen (CH340B/C/E/G/T und R). Wenn mich mein Chinesisch nicht ganz im Stich lässt, dann verfügt nur der B über einen internen EEPROM, den man konfigurieren kann. FTDI-Chips sind ja als Alternative alles andere als günstig (aktuell ca. 3-4€ bei Reichelt für den FT232, wird in hohen Stückzahlen auch nicht viel günstiger). Sonst gibts noch SiLabs und Microchip. Ich mach mich da mal schlauer, was da möglich ist. Auf der anderen Seite interessiert es scheinbar heutzutage keinen PC mehr, wie viel mA das Gerät tatsächlich zieht, sondern es gibt mehr so Erfahrungswerte, was möglich ist. Ich schließe das Thema hier ab.
Timo N. schrieb: > Fazit: Man kann irgendwie mit einem EEPROM Programmer den Wert vom CH340 > ändern, aber da gibt es nicht so viele Infos dazu, wie das konkret geht Kein EEPROM Programmer. Man muß mit dem USB-Device ein undokumentiertes Protokoll reden (respektive ein Tool vom Hersteller benutzen, das das tut) und kann dann u.a. die Power-Anforderung modifizieren. > FTDI-Chips sind ja als Alternative alles andere als günstig FTDI sollte man auch aus anderen Gründen nicht verwenden. > Sonst gibts noch SiLabs und Microchip. Da sind noch mehr. Z.B. Cypress CY-xxx. Oder Prolific PL-xxx. Bei Silabs kann man das Config-Tool herunterladen. Angaben zu FTDI findet man vor allem wegen des Bricking Debakels. > Auf der anderen Seite interessiert es scheinbar heutzutage keinen PC > mehr, wie viel mA das Gerät tatsächlich zieht, sondern es gibt mehr so > Erfahrungswerte, was möglich ist. Eigentlich ist es doch ganz einfach. Es gibt eine Norm. Die sollte man einhalten. Punkt. Daß Abweichungen von der Norm nicht direkt mit der Todesstrafe bedroht sind - nice to know - aber im Zweifelsfall ist es am Ende doch dein Problem, wenn dein Gerät wegen Verletzung der Norm nicht funktioniert. Wenn du Spielkram für den Eigenbedarf oder den engeren Freundeskreis baust, dann ist das egal. Aber wenn auch nur der Hauch der Chance besteht, daß dich jemand für die Nichteinhaltung zugesicherter Produkteigenschaften vor den Kadi ziehen könnte, dann ist die Entscheidung sehr einfach.
Axel S. schrieb: > FTDI sollte man auch aus anderen Gründen nicht verwenden. Ich stimme Dir zu, bin aber froh, dass ich zumindest einen USB auf RS232 mit FTDI habe: Ich habe eine Navilock GPS-Maus mit serieller Schnittstelle. Von Navilock gibt es eine Software, die die empfangenen Satelliten grafisch darstellt. Am CH340 behauptet sie hartnäckig, dass kein COMport verfügbar sei, mit dem FTDI-Adapter spielt die. Fasse ich das Teil per Hyperterm oder Putty an, bekomme ich auch am CH340 korrekte NMEA-Daten, also scheidet ein Hardwareproblem mal aus. Ob nun Navilock oder der Chinese gepfuscht haben kann man nur spekulieren, es ist zum Glück die einzige Anwendung, wo mich der CH340 geärgert hat. Ein Vorteil des CH340 ist, dass der keine Seriennummer hat: Jeder ChinUino oder einer meiner RS232-Adapter erscheinen immer als COM4, während FTDI oder SiLabs stets eine neue COMport-Nummer belegen.
Gibt ein Tool nennt sich CH340CFG, meines Wissens unterstützt aber nur der CH340B das ändern von Konfigurationsdaten. Das Tool kann zumindest in der Version 1.0 aber nicht die Einstellung des Strombedarfs anpassen, auch wenn es laut Datenblatt möglich sein soll.
Manfred schrieb: > Axel S. schrieb: >> FTDI sollte man auch aus anderen Gründen nicht verwenden. > > Ich stimme Dir zu, bin aber froh, dass ich zumindest einen USB auf RS232 > mit FTDI habe: Ich habe eine Navilock GPS-Maus mit serieller > Schnittstelle. Von Navilock gibt es eine Software, die die empfangenen > Satelliten grafisch darstellt. Am CH340 behauptet sie hartnäckig, dass > kein COMport verfügbar sei, mit dem FTDI-Adapter spielt die. Hm. Vielleicht mal den Treiber deinstallieren und neu installieren. Kann auch gut sein, dass ein anderes Programm den Port blockiert. > Ein Vorteil des CH340 ist, dass der keine Seriennummer hat: Jeder > ChinUino oder einer meiner RS232-Adapter erscheinen immer als COM4, > während FTDI oder SiLabs stets eine neue COMport-Nummer belegen. Den COM-Port kannst du für jedes Device im Gerätemanager unter Windows zumindest selbst ändern. Das ist dir aber sicher bekannt. @René F.: Danke. Ich glaub der Standard-CH340 auf dem Arduino Nano Klon ist der CH340G, nicht der B.
Manfred schrieb: > Ein Vorteil des CH340 ist, dass der keine Seriennummer hat: Jeder > ChinUino oder einer meiner RS232-Adapter erscheinen immer als COM4, > während FTDI oder SiLabs stets eine neue COMport-Nummer belegen. Das ist zugleich Vorteil und Nachteil. Denn wenn du mehrere solche Geräte gleichzeitig verwendest, musst du darauf achten, sie immer in der gleichen Reihenfolge anzustecken (oder die Software immer wieder umkonfigurieren).
Axel S. schrieb: > FTDI sollte man auch aus anderen Gründen nicht verwenden. Weil FTDI vor einigen Jahren mal keinen Bock darauf hatte, ihre Devicetreiber für Nachbauten der Chips zur Verfügung zu stellen, und diese Nachbauten mehr oder weniger gewollt mit ihrem Devicetreiber dauerhaft unbrauchbar machte? Den Devicetreiber haben sie nach dem aufkommenden großen Gekreische durch einen ersetzt, der mit den Nachbauten nur nicht funktioniert, sie aber nicht dauerhaft unbrauchbar macht, aber auch das scheint manchen Leuten nicht zu gefallen; es scheint wohl eine selbstverständliche Forderung zu sein, daß Devicetreiber gefälligst auch mit Nachbauten zu funktionieren haben. Klar, deswegen kann man einen Hersteller verdammen, und dann auf einen anderen zurückgreifen, der seine Produkte so unterirdisch schlecht dokumentiert wie WCH. Kann man machen, ist halt nur etwas komisch. Ein anderer Ansatz wäre die Verwendung eines selbstprogrammierten USB-Controllers wie z.B. einem Atmega32U2/U4, auf dem die CDC-Geräteklasse implementiert wird. Aufgrund der freien Programmierbarkeit kann im Devicedescriptor jeder beliebige Wert für den Strombedarf hinterlegt werden, und mit zunehmender Verbreitung von Windows 10 ist auch endlich der Krampf mit den *.inf-Dateien Geschichte.
Rufus Τ. F. schrieb: > Weil FTDI vor einigen Jahren mal keinen Bock darauf hatte, ihre > Devicetreiber für Nachbauten der Chips zur Verfügung zu stellen, und > diese Nachbauten mehr oder weniger gewollt mit ihrem Devicetreiber > dauerhaft unbrauchbar machte? Es ging IIRC eher darum wie sie es umgesetzt haben als darum das sie es taten. Anstatt die Arbeit zu verweigern und den unschuldigen Konsumenten über das warum zu informieren, haben sie heimlich den Datenstrom verfälscht und den Konsumenten mit (erstmal unerklärlichen Fehlfunktionen) im Regen stehen lassen. Erinnere ich mich richtig?
test schrieb: > Erinnere ich mich richtig? Ich habe das anders in Erinnerung aber ebenso verwerflich. Fair wäre eine Meldung gewesen, wie "Dieses nachgemachte Gerät wird vom installierten Treiber nicht unterstützt", und dann nichts kaputt machen. Dann weiss man wenigstens, was los ist.
Rufus Τ. F. schrieb: > Weil FTDI vor einigen Jahren mal keinen Bock darauf hatte, ihre > Devicetreiber für Nachbauten der Chips zur Verfügung zu stellen, und > diese Nachbauten mehr oder weniger gewollt mit ihrem Devicetreiber > dauerhaft unbrauchbar machte? Du scheinst der Meinung zu sein, daß der Zweck die Mittel heiligt. Das tut er nicht. FTDI hat damals seine Streitigkeiten mit irgendwelchen Plagiatoren auf dem Rücken ihrer zumindest potentiellen Kunden ausgetragen. Denn bei weitem nicht jeder, der einen gefälschen FTD-irgendwas in Benutzung hatte, wußte daß es eine Fälschung war. Und FTDI hat auch keinen Finger gerührt, den Leuten das zu sagen. Nein, lieber haben sie Datenströme manipuliert und am Ende sogar Hardware gebrickt. > Klar, deswegen kann man einen Hersteller verdammen Das ist auch eine Frage des Vertrauens. Treiber laufen ja typisch mit System-Privilegien und können somit richtig großen Schaden anrichten. Da überlegt man dreimal, von wem man einen Treiber installiert. FTDI hat damals jedes Vertrauen verspielt. > und dann auf einen > anderen zurückgreifen, der seine Produkte so unterirdisch schlecht > dokumentiert wie WCH. Der CH340 wäre in der Tat auch nicht meine erste Wahl. Aber auf den nano-Klones ist er nun mal drauf. Und funktioniert auch ohne den Hauch eines Problems. Insofern <schulterzuck>
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.