Ich bin auf der Suche nach einem passenden MC für meine Anwendung. Grund der Anwendung: ich möchte einen Pin abfragen und diesen, am liebsten, als Game-Controller zum PC schicken. Quasi wie ein Joystick / Gamepad mit nur einer Taste. Gibt es da etwas auf dem Markt, vielleicht etwas aus WCH Ecke? Mit geringen Hühnerfutter? Danke für eure Hilfe. 😊
Fiel mir jetzt ein: https://github.com/obdev/v-usb Ob das für die passt, weiß ich nicht. Suchst du was fertiges oder was zum Selberbauen?
Was zum selber bauen, ich würde mir die Platine selbst machen. Ja VUSB werde ich mir mal anschauen. Danke dafür.
Warum ist möglichst geringer PIN Count eine Anforderung? Preis, OK lass ich gelten. Hat aber eher was mit Hersteller zu tun, gerade wenn die Chinesen in Rennen sind. Platz, OK bekommt man aber über Package so klein dass viele es nicht mehr löten wollen. Aus der WCH Ecke fällt mir spontan der CH32X035 ein. Gibt's in QFN20. Kosten sind eher gering. Könnte auch noch USB-PD falls man es braucht. Wenn man auf deren Seite sucht findet man bestimmt auch noch einen kleineren. Ansonsten, von denen gibt es auch noch ein paar: Beitrag "low-pin-count µC mit integriertem USB" Da hast du die Frage ja schonmal gestellt.
:
Bearbeitet durch User
N. M. schrieb: > Da hast du die Frage ja schonmal gestellt. o.O Okay... Das ist fünf Jahre her :-D Ja, das war noch vor dem Schlaganfall. Aber wie ich sehe, habe ich mich damals für denn CH552 entschieden. Ich werde meine Daten nach dem Projekt durchforsten (Und ich habe echt mal absolut keine Ahnung was ich da gebastelt habe! -.-)
Den Vorschlag von V-USB habe ich erfolgreich nachgebaut: https://www.obdev.at/products/vusb/index.html https://www.obdev.at/Images/vusb/circuit-zoomed.gif Den AtMega168/328 habe ich verwendet weil ich ihn liegen hatte. Ein Tiny soll auch ausreichend sein.
STM32C071FBP6 USB ohne Quarz, 20 Pins, 1,18 € Heutzutage noch V-USB zu nutzen find ich nicht so sinnvoll, weil es Massen an leicht beschaffbaren und programmierbaren MCUs mit Hardware-USB gibt. Das vereinfacht die Sache enorm und ist natürlich viel flexibler.
:
Bearbeitet durch User
Ein Äquivalent von V-Usb gibt es auch für den CH32V003 von WCH. Für HID ist das ausreichend, und das geht sogar mit der Variante im SO-8. https://github.com/cnlohr/rv003usb Allerdings, wenn man damit leben kann, doch etwas größere Gehäuse zu verwenden, dann gibt es für wenig mehr Geld von WCH auch µCs mit USB-Hardware, die mehr als Low-Speed-USB zulässt. Für die ist das hier ein guter Anlaufpunkt https://github.com/cnlohr/ch32fun
Frank K. schrieb: > Hardware USB Niklas G. schrieb: > Hardware-USB Selbstverständlich Hardware-USB, genauso wie Hardware-SPI, Hardware-I²C, Hardware-UART, Hardware-CAN, Hardware-LIN, Hardware-IrDA, Hardware-DALI, Hardware-AES128/256, Hardware-TRNG, Hardware-LCD-Controller... Oder was ist der Unterschied zwischen einem Mikrocontroller und einem Mikroprozessor?
Georg M. schrieb: > Frank K. schrieb: >> Hardware USB > > Niklas G. schrieb: >> Hardware-USB > > Selbstverständlich Hardware-USB, genauso wie Hardware-SPI, Hardware-I²C, > Hardware-UART, Hardware-CAN, Hardware-LIN, Hardware-IrDA, Hardware-DALI, > Hardware-AES128/256, Hardware-TRNG, Hardware-LCD-Controller... > Oder was ist der Unterschied zwischen einem Mikrocontroller und einem > Mikroprozessor? Hä? V-USB ist kein Hardware-USB, das halte ich nicht für besonders sinnvoll.
Auch rv32usb ist eine per "bitbanging" in Software erreichte Nachbildung. Für Low-Speed-USB reicht das, wie auch schon seit Ewigkeiten v-usb auf den 8-Bit-AVRs. Übrigens sind Software-UART, Software-SPI und auch Software-I2C gar nicht so unüblich ...
Niklas G. schrieb: > Hä? V-USB ist kein Hardware-USB, das halte ich nicht für besonders > sinnvoll. Für ein einfaches, nicht kommerzielles HI-Device im 1.5MBit LS-Modus ist das schon fast Overkill.
Das V-USB auf den Atmegas und Attinys kann die CRC nicht prüfen, dafür reicht die erlaubte Antwortzeit nicht. Das ist also Schönwetter-USB. Vor 15 Jahren, als Mikrocontroller mit echtem Hardware-USB noch richtig teuer waren, ist man diese Kompromisse eingegangen. Wenn man sich aber mal anschaut was Mikrocontroller mit echtem Hardware-USB, mit CRC-Prüfung und allem drum und dran, heute kosten, dann lohnt es sich nicht mehr darauf zu verzichten es richtig zu machen. Also z.B. STM32C071, STM32F070 oder CH32X035 wären geeignete Kandidaten. Wenn man wirklich nur minimales HID machen will, geht natürlich auch der CH552. Ist aber nen 8051. Wenn man das nicht in riesigen Stückzahlen braucht, wäre mir das die Unbequemlichkeit in der Entwicklung im Vergleich zu nem deutlich moderneren RISC-V wie dem CH32X035 nicht wert, zumal die preislich ziemlich nah beieinander liegen.
:
Bearbeitet durch User
FT232 oder CH340 und per UART z.B. CTS abfragen, geht in Lunux sogar auf der Bash. alternativ Python mit Serial. Der CH340K oder E hat 10 Pins und CTS
:
Bearbeitet durch User
AVR16DU14 (SOIC-14) ist z.B. ein AVR-Mikrocontroller mit USB. https://www.microchip.com/en-us/product/AVR16DU14 (Ich sage nicht "mit Hardware-USB", weil das ein Pleonasmus ist)
Stephan S. schrieb: > FT232 oder CH340 Nutzen keine Standard-Geräteklasse, also kein CDC, und schon gar nicht HID.
Ich habe mich für den CH552E entschieden. Leicht zu handeln und wenig "Drumrum", integrierter 3V3 Wandler, keine externe USB-Beschaltung. Danke für eure Infos. :-D
Harald K. schrieb: > Stephan S. schrieb: >> FT232 oder CH340 > > Nutzen keine Standard-Geräteklasse, also kein CDC, und schon gar nicht > HID. xdraconix schrieb nichts von HID. Kein Problem, es reicht der Standard-UART-Treiber: bei Linux wird der CH340 sofort als /dev/ttyUSBx erkannt (Treiber ist im Kernel), bei Win muss halt ein COM-Treiber installiert werden. Dito FT232.
:
Bearbeitet durch User
Stephan S. schrieb: > xdraconix schrieb nichts von HID Doch, sogar in der Überschrift. Und als Joystick / Pad, bleibt nurmal eigentlich nur die HID übrig, wenn man keine Treiber will.
ok, hatte wohl meine Brille nicht auf ;-) Soll er halt mit HID glücklich werden, geht aber auch ohne HID völlig simpel.
:
Bearbeitet durch User
Gerd E. schrieb: > Das V-USB auf den Atmegas und Attinys kann die CRC nicht prüfen, dafür > reicht die erlaubte Antwortzeit nicht. Das stimmt nicht. In V-USB ist meines Wissens nach auch ein (allerdings suboptimales) Beispiel für die Prüfssumenbildung enthalten. Bei reinem Assemblercode für die gesamte Anwendung geht das deutlich besser, insbesondere wird so auch die 100%ige Einhaltung der USB-Timing-Constraints möglich. Allerdings: für die meisten "classic"-AVR8 (mit Ausnahme derer, die PLL-Takt bieten) erfordert es zwingend einen Quarz, weil die sonst nicht auf den dafür nötigen Takt (mindestens ca. 16MHz, idealerweise 18MHz), kommen. Und klar: man muss wirklich gut Assembler programmieren können. Wohl eher nix für den TO...
Norbert schrieb: > Niklas G. schrieb: >> Hä? V-USB ist kein Hardware-USB, das halte ich nicht für besonders >> sinnvoll. > > Für ein einfaches, nicht kommerzielles HI-Device im 1.5MBit LS-Modus ist > das schon fast Overkill. Und die Datenrate ging es mir dabei gar nicht. Software USB ist halt relativ komplex zu handeln, der Prozessor ist dann einen signifikanten Teil der Zeit mit Bitbanging beschäftigt und kann kaum was anderes machen. Da muss man bei der eigenen Anwendung aufpassen dem USB nicht dazwischen zu funken. Bei Hardware USB passiert das alles vollautomatisch im Hintergrund, man schreibt/liest die gewünschte Daten in den Puffer und die Peripherie erledigt den Rest. Bei der Enumeration muss man zwar gewisse Timeouts einhalten, das ist aber total unkritisch, und bei der weiteren Kommunikation kann die Software beliebig langsam sein bzw. irgendwas anderes machen. Das ist vom Handling her sehr praktisch, fast schon einfacher als UART... Konkret die STM32 haben den Vorteil dass es gute Entwicklungsumgebungen und Mengen an Beispielen/Tutorials gratis gibt, sowie günstige Eval Boards. Übrigens ist man nicht auf HID angewiesen außer es ist wirklich ein Eingabegerät (Custom Tastatur oder so); dank WinUSB, dem WinUSB Deskriptor und libusb kann man sehr einfach auch komplett eigene USB Protokolle umsetzen und mit eigenen PC-Anwendungen abfragen, ohne eigene Treiber zu haben und auch ohne die Treiber Problematik von Windows (braucht nichtmal Admin Rechte).
Rene K. schrieb: > Ich habe mich für den CH552E entschieden. Leicht zu handeln und wenig > "Drumrum", integrierter 3V3 Wandler, keine externe USB-Beschaltung. > > Danke für eure Infos. :-D Bist du sicher, dass dein BTN im gezeigten Schaltplan richtig erkannt wird? Üblicherweise aktiviert man doch den internen Pull-Up und zieht mit dem Taster den Eingang gegen GND.
Ob S. schrieb: > Gerd E. schrieb: >> Das V-USB auf den Atmegas und Attinys kann die CRC nicht prüfen, dafür >> reicht die erlaubte Antwortzeit nicht. > > Das stimmt nicht. > > In V-USB ist meines Wissens nach auch ein (allerdings suboptimales) > Beispiel für die Prüfssumenbildung enthalten. Bei reinem Assemblercode > für die gesamte Anwendung geht das deutlich besser, insbesondere wird so > auch die 100%ige Einhaltung der USB-Timing-Constraints möglich. Der CRC-Code ist zwar da, aber wenn Du ihn aktivierst, funktioniert es nur mit manchen USB-Hosts da das nötige Timing nicht eingehalten wird. Ist zwar zum Glück schon ein paar Jahre her, aber hab ich selbst mit Atmega328 bei 20 MHz ausgemessen und getestet.
:
Bearbeitet durch User
Loco M. schrieb: > Bist du sicher, dass dein BTN im gezeigten Schaltplan richtig erkannt > wird? Üblicherweise aktiviert man doch den internen Pull-Up und zieht > mit dem Taster den Eingang gegen GND. Ja, das ist der übliche Weg. Hier müsste man ein Pulldown im Controller aktivieren. Wenn der Taster gedrückt wird, bildet der dann einen Spannungsteiler mit dem 4.7k Widerstand nach 3V3. Wird vermutlich gehen, ist aber nicht schön da der Eingangspegel dann niedriger ist als nötig.
Bitte 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.


