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! -.-)
Angehängte Dateien:
-
HID_2_Schematic.JPG
210 KB
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.
Gerd E. schrieb: > 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. Richtig. Wie ich schrieb, ist der Code suboptimal. Das kann man besser machen. Man muss halt auf C verzichten, um 100%ige Einhaltung der Constraints zu erreichen. Aber klar: Es darf auch dann auch nur einen einzigen Interrupt im System geben, den für USB-Rx, sonst wird das nix. Für ein HID-Device ist das aber kein Problem, zum Abfragen von Tastern und ggf. ADC braucht man keine Interrupts. Taster kommen sowieso "on the fly", für ADC gibt es den AutoTrigger-Mechanismus, der in regelmäßigen Abständen einen neuen Messwert bereitstellt, den man nur abholen muss, was dann auch wieder "on the fly" geht. Der Rest sind eigentlich nur die üblichen Asm-Tricks: reservierte Register und Verschachteln von Code. Letzteres ist insbesondere für Prüfsummenroutinen nötig. Die müssen zumindest teilweise bereits während des Empfangs der Bits laufen, also mit den Bitroutinen verschachtelt werden, sonst reicht's am Ende halt nicht, um die Antwortzeit einzuhalten. Ich hänge mal die relevanten Routinen an, die ich verwende. Die sind extra dafür geschrieben, sich möglichst gut mit dem Bitcode verschachteln zu lassen.
Niklas G. schrieb: > 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. Ich hatte seinerzeit™ mal aus Interesse gemessen. Ein AVR 8-Bitter hatte (bei einer maximalen USB Polling** Frequenz von 1000Hz) noch ca. 87% (WIMRE) seiner CPU cycles für das eigentliche Programm zur Verfügung. Da konnte man noch parallel die Mondlandung berechnen. **Volle Polling Frequenz nur unter Linux möglich, Windows hat das von sich aus völlig unnötigerweise auf ca. ¼ reduziert.
Norbert schrieb: > noch ca. 87% > (WIMRE) seiner CPU cycles für das eigentliche Programm zur Verfügung. Interessant, auch wenn man kontinuierlich Daten überträgt?
Gerd E. schrieb: > 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. Im Datenblatt des CH552E habe ich keinen Pull-Down Widerstand finden können.
Norbert schrieb: > Ich hatte seinerzeit™ mal aus Interesse gemessen. Ein AVR 8-Bitter hatte > (bei einer maximalen USB Polling** Frequenz von 1000Hz) noch ca. 87% > (WIMRE) seiner CPU cycles für das eigentliche Programm zur Verfügung. Das ist richtig, nützt aber bezüglich der Problematik der Antwortzeiten leider rein garnichts. > **Volle Polling Frequenz nur unter Linux möglich, Windows hat das von > sich aus völlig unnötigerweise auf ca. ¼ reduziert. Das ist FUD. Natürlich pollt Windows LowSpeed mit maximaler Frequenz, also einmal pro USB-Frame. Zumindest, solange nicht ein kaputter Descriptor was anderes festlegt.
Loco M. schrieb: > Im Datenblatt des CH552E habe ich keinen Pull-Down Widerstand finden > können. gut gesehen! Das sollte der TO dann wirklich ändern. Wieder ein Grund mehr modernere Mikrocontroller zu verwenden...
Niklas G. schrieb: > Interessant, auch wenn man kontinuierlich Daten überträgt? Das war auch ein HID, da gab's ja kaum etwas zu übertragen.' Acht physikalische Axen, vier virtuelle, und entweder 64 oder 96 Tasten (die Erinnerung verblasst) Also acht oder zwölf Bytes für die Tasten plus 15 Bytes (12×10Bit) für die Achsen. Plus einige wenige Bytes 'drumherum'. Und da sich nicht ständig alles ändert, kann man ja auch noch selektiv über verschiedene ReportIDs nur die geänderten Werte übertragen. Die Tasten alle 10ms reicht aus, woraus sich da schon mal ein zehntel des Datenvolumens ergab. Die Achsen in vier ultraschnelle (volle Pulle), viel schnelle (alles 10ms) und vier mäßig schnelle (alle 50ms) unterteilt hat noch einmal reichlich gespart. Obwohl's eigentlich nur dem Programmierer-Spieltrieb diente, denn am Ende des Tages hatte man lediglich den stets überreichlich vorhandenen CPU Leerlauf noch um einige Prozent angehoben.
Ob S. schrieb: > Das ist richtig, nützt aber bezüglich der Problematik der Antwortzeiten > leider rein garnichts. Welche Antwortzeiten erwartest du den bei einem 1ms Polling Intervall? Genau das (1ms) ist dann bei einem HID auch die Antwortzeit. Ob S. schrieb: > as ist FUD. Natürlich pollt Windows LowSpeed mit maximaler Frequenz, > also einmal pro USB-Frame. Zumindest, solange nicht ein kaputter > Descriptor was anderes festlegt. Ist das deine Meinung, dein Gefühl, dein Glaube oder hast du es tatsächlich auf dem Mikrocontroller nachgemessen? Ich hab's nämlich und zumindest Win 7 hat sich seinerzeit genau wie von mir beschrieben verhalten. Ob S. schrieb: > Zumindest, solange nicht ein kaputter > Descriptor was anderes festlegt. Ich halte es für recht schwierig, alles aber auch wirklich alles korrekt zu beschreiben und dann den Wert für das Polling Intervall zu verbocken. Zumal Linux dann anscheinend auch noch mit diesem verbockten Intervall genau das Richtige getan hat.
:
Bearbeitet durch User
Norbert schrieb: > Das war auch ein HID, da gab's ja kaum etwas zu übertragen.' Hmm, interessant. Allerdings wird man wohl während der 13% belegten CPU-Zeit auf keinen Fall unterbrechen dürfen um das Timing nicht durcheinander zu bringen. Dürfte aber für viele Anwendungen hinkommen. Spannend wäre es noch den Stromverbrauch mit einem Hardware-USB zu vergleichen 😉
Norbert schrieb: > Ist das deine Meinung, dein Gefühl, dein Glaube oder hast du es > tatsächlich auf dem Mikrocontroller nachgemessen? Ich habe es unter Windows nachgemessen. Ist ja simpel: statt echter Tastendrücke läßt man auf dem Device einfach bei jedem Frame einen Counter incrementieren (den gibt's in meinem Code sowieso) und benutzt ein Bit davon als "Taste". Unter Windows zählt man dann einfach die übertragenen Tastendrücke/s. > Ich hab's nämlich und > zumindest Win 7 hat sich seinerzeit genau wie von mir beschrieben > verhalten. Ich hab's ursprünglich mit WindowsXP gemacht, hab' aber die Sache in jeder von mir benutzten weiteren Windows-Version (also 7 und 10) erneut getestet. Funktionierte immer wie erwartet. > Ich halte es für recht schwierig, alles aber auch wirklich alles korrekt > zu beschreiben und dann den Wert für das Polling Intervall zu verbocken. Es gibt noch einige andere Möglichkeiten, im Device-Code etwas so zu verbocken, dass zumindest der Anschein entsteht, dass nicht bei jedem Frame gepollt wird. Ich vermute mal: Es war für dich schlicht einfacher, Windows die Schuld anzulasten, statt das tatsächliche Problem zu suchen...
Ob S. schrieb: > 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.. Das ist nicht ganz korrekt. Im Paket sind Assemblermodule für diverse Frequenzen enthalten. Die niedrigste ohne Quarz ist 12,8MHz. Das ist ausserhalb der Spec aber typisch gut erreichbar. Die CLock justiert sich zudem selbst auf den vorhandenen USB-Takt. Rechenleistung und Timing sind für die Erkennung eines Tastendrucks völlig ausreichend. Das funktioniert alles sehr zuverlässig. Welchen Lösungsweg man geht hängt stark von den vorhandenen Möglichkeiten und Fähigkeiten ab. Nicht jeder ist Mister Superschlau und hat alle denkbaren Prozessoren und Toolketten fertig installiert liegen und ist der weltbeste Programmierer.. Die Lösung mit dem CH552 gefällt mir sehr gut. Danke für die Inspiration.
Norbert schrieb: > Welche Antwortzeiten erwartest du den bei einem 1ms Polling Intervall? > Genau das (1ms) ist dann bei einem HID auch die Antwortzeit. Du verstehst offensichtlich die Details von USB nicht wirklich. Es genügt nicht, irgendwann im Frame zu antworten. Du musst dann antworten, wenn die Frage fertig eingetroffen ist. Und du musst, um auch interaktiv negativ antworten zu können (nämlich dann, wenn die Prüfsumme nicht stimmt oder dann, wenn keine Daten vorliegen), diese Antwort sehr zeitnah nach Ende der Frage senden können. V-USB in der Standardimplementierung trickst hier ganz erheblich rum. Es wird nämlich immer positiv geantwortet und es wird dann immer mit einem fertig vorbereiteten Block von Daten geantwortet.
Gerd E. schrieb: > gut gesehen! Das sollte der TO dann wirklich ändern. Loco M. schrieb: > Im Datenblatt des CH552E habe ich keinen Pull-Down Widerstand finden > können. Ahh super! Danke! Ja habe ich gleich geändert.
Christian schrieb: > Das ist nicht ganz korrekt. Im Paket sind Assemblermodule für diverse > Frequenzen enthalten. Die niedrigste ohne Quarz ist 12,8MHz. Das ist > ausserhalb der Spec aber typisch gut erreichbar. Die CLock justiert sich > zudem selbst auf den vorhandenen USB-Takt. Ja, das ist richtig. Aber reicht nicht für die Verschachtelung des Prüffsummencodes. Im Bitcode ist dann schlicht nicht genug Luft frei, um den dort mit rein zu bringen.
Ob S. schrieb: > Du verstehst offensichtlich die Details von USB nicht wirklich. Ja, das wird's bestimmt sein! > Es > genügt nicht, irgendwann im Frame zu antworten. Du musst dann antworten, > wenn die Frage fertig eingetroffen ist. Und du musst, um auch interaktiv > negativ antworten zu können (nämlich dann, wenn die Prüfsumme nicht > stimmt oder dann, wenn keine Daten vorliegen), diese Antwort sehr > zeitnah nach Ende der Frage senden können. Nein, du erstellst den Report Block und wenn das HID gepollt wird, dann wird dieser übertragen. Man hat also eine ganze Millisekunde Zeit, um seine Daten zusammen zu raffeln. Das ist bei HID und bei V-USB nicht anders als bei einem Hardware USB. Und ob bei einem HID (HUMAN! Interface) nun die letzte Abfrage einer Potiachse nun 100µs oder 900µs her ist, das ist nun wirklich egal. Außer vielleicht bei einem Goldfinger (vgl. Goldöhrchen bei Audiophilen)
Ob S. schrieb: > Es > wird nämlich immer positiv geantwortet und es wird dann immer mit einem > fertig vorbereiteten Block von Daten geantwortet. Hmm, das macht Hardware-USB doch auch so. Man schreibt einen fertigen Block in den Hardware-Puffer, und die Peripherie schickt diesen beim nächsten Frame ab. Live während innerhalb des Frames das Datenpaket zusammenzustellen dürfte mit den gängigen Mikrocontrollern mit USB-Peripherie kaum/gar nicht möglich sein.
Norbert schrieb: > Ob S. schrieb: >> Du verstehst offensichtlich die Details von USB nicht wirklich. > > Ja, das wird's bestimmt sein! Ganz offensichtlich ist das so. > Nein, du erstellst den Report Block und wenn das HID gepollt wird, dann > wird dieser übertragen. Genau. Selbst dann, wenn schon die Frage nicht verstanden wurde. Oder wenn das Device festgestellt hat, dass irgendwas im Argen ist und deswegen kein gültiger Report erstellt werden konnte. In beiden Fällen darf man nach den USB-Standards eigentlich nicht positiv antworten. V-USB (Standardimplementierung) tut es aber.
Niklas G. schrieb: > Hmm, das macht Hardware-USB doch auch so. Man schreibt einen fertigen > Block in den Hardware-Puffer Ja klar. Aber: die prüfen die Frage des Hosts und antworten gar nicht, wenn deren Prüfsumme nicht stimmt. Und die Anwendung kann ihnen auch sagen, dass sie negativ antworten sollen, wenn keine gültigen Daten für die Anwort verfügbar sind. Beides ist mit V-USB (Standimplementierung) halt nicht möglich. Mit meinem Code hingegen schon. Dass er nebenbei auch noch in der Lage ist, Antwortpakete "on the fly" mit einer Prüfsumme zu versehen, wäre sicher nicht unbedingt nötig gewesen, ist aber zumindest ein nettes Zusatzfeature. Ist halt bei der Implementierung der Empfangsseite quasi nebenbei mit abgefallen.
Ob S. schrieb: > Ganz offensichtlich ist das so. Uns allen ist natürlich klar, dass eure Hoheit des Morgens die Hose in die Luft wirft und mit einem doppelten Salto hinein springt ohne den Stoff auch nur zu berühren. Und alle anderen hier im Forum und auch sonstwo auf der Welt sind dazu verdammt, sich die Hosen unter schwierigsten Bedingungen immer wieder mit der Kneifzange anzuziehen. Zumindest scheint das deine Wahrnehmung zu sein. Da gratuliere ich einfach mal.
Norbert schrieb: > Uns allen ist natürlich klar, dass eure Hoheit des Morgens die Hose in > die Luft wirft und mit einem doppelten Salto hinein springt ohne den > Stoff auch nur zu berühren. Ach hör doch auf mit der schwachsinnigen Polemik und lies statt dessen lieber die USB-Specs. Wenn du zu doof oder zu faul dazu bist, suche ich dir auch gern die passenden Punkte raus. Naja, nicht wirklich, das wäre mir dann doch zu viel Arbeit. Ich habe sie aber zur Erinnerung für mich selber als Kommentare in meiner V-USB-Implentierung notiert, brauch' sie also nicht wirklich zu suchen...
Gerd E. schrieb: > Wieder ein Grund mehr modernere Mikrocontroller zu verwenden... Man kann sich auch an die altbewährte Praxis halten und mit Pull-Up und Taster nach Gnd arbeiten. Das hat den Vorteil, dass man die Versorgungsspannung nicht unnötigerweise hart auf irgendwelchen herausgeführten Leitungen liegen hat.
Ob S. schrieb: > Stuss. Reichlich Es reicht dir nicht, dich wie ein Arsch zu verhalten. Du musst auch noch allen hier beweisen, dass du tatsächlich einer bist. Ich spare mir weitere Worte für dich und konversiere lieber mit den sich anständig benehmenden Menschen hier. Das ist nicht nur angenehmer, sondern auch zielführender.
Christian schrieb: > Das ist nicht ganz korrekt. Im Paket sind Assemblermodule für diverse > Frequenzen enthalten. Die niedrigste ohne Quarz ist 12,8MHz. Das ist > ausserhalb der Spec aber typisch gut erreichbar. Die CLock justiert sich > zudem selbst auf den vorhandenen USB-Takt. > > Rechenleistung und Timing sind für die Erkennung eines Tastendrucks > völlig ausreichend. Das funktioniert alles sehr zuverlässig. Das mit dem "zuverlässig" ist relativ. Ich habe relativ lange meinen Umsetzer PS/2++ auf USB mit einem Digispark und VUSB betrieben, aber das ist immer wieder mal kaputt gegangen, insbesondere an Windows Hosts. Also "kaputt" im Sinne, daß das Ding sich irgendwann, nach suspend/resume oder so nicht mehr am USB gemeldet hat und nur noch mit neuaufspielen des micronucleus Bootloaders wiederbeleben ließ. Meine Vermutung ist, daß diese Autojustage der Clock unter ungünstigen Umständen derart falsche Korrekturwerte geschrieben hat, daß die USB Kommunikation nicht mehr funktioniert hat. Außerdem haben sich die Digispark auch durch solche Sachen wie "Chrome starten" unter Windows aus dem Konzept bringen lassen und mussten dann manchmal resetted oder halt aus- und wieder angesteckt werden. Suspend und resume Handling war auch nicht trivial und ein Windows aus dem Suspend damit aufwecken war nicht möglich (nicht daß ich das gewollt hätte, aber mir fiel es halt nach dem Umstieg auf den ATMega32u4 auf, daß ich das dort aktiv verhindern musste ;-) Am Ende habe ich dann die Digispark durch "CJMCU Beetle" mit ATMega32u4 drauf ersetzt, die Bauform ist ähnlich, und da es nur um eine Handvoll Module gehandelt hat war es auch egal ob die 1,50€ oder 5,10€ kosten... Die Baugröße war wichtig, weil das Modul in die "Maus" mit rein sollte.
Doch, das hat bei mir sehr zuverlässig funktioniert. In meiner Anwendung in Verbindung mit einem Handy und auch am Windows PC. Gelegentlich einen Tastendruck übertragen ist doch keine Mondrakte. Und wenn V-USB angeblich "dreckig" ist und trotzdem immer funktioniert stört mich das wenig. Dafür ist sowas am Wochende mit Teilen aus der Schrottkiste aufgebaut. Die Diskussion scheint hier (wie üblich) wegzudriften in "wer hat die beste und Standardkonforme Lösung". Gefolgt von den üblichen Beleidigungen..
Stefan S. schrieb: > Das mit dem "zuverlässig" ist relativ. Ich habe relativ lange meinen > Umsetzer PS/2++ auf USB mit einem Digispark und VUSB betrieben, aber das > ist immer wieder mal kaputt gegangen, insbesondere an Windows Hosts. > Also "kaputt" im Sinne, daß das Ding sich irgendwann, nach > suspend/resume oder so nicht mehr am USB gemeldet hat und nur noch mit > neuaufspielen des micronucleus Bootloaders wiederbeleben ließ. Wäre durchaus denkbar. Der Umgang von V-USB mit USB-Suspend/Resume läßt deutlich zu wünschen über. Oft ist das aber nur ein L8-Problem (des Programierers und/oder Hardware-Entwicklers). Self-Powered vs. Bus-Powered im Descriptor. Und natürlich: entsprechendes Design der Hardware. Ist überhaupt ein Hauptproblem: Viele V-USB-Anwender haben schlicht keine Ahnung vom USB-Standard und machen so ziemlich alles falsch, was man nur falsch machen kann... Sie machen also Fehler, die nicht mal durch die Unvollkommenheit von V-USB selber zwingend in Kauf zu nehmen sind, sondern bei korrekter Benutzung von V-USB durchaus vermeidbar wären. Man muß halt die Standards lesen, um zu wissen, wie die Sache korrekt (im Rahmen ihrer Möglichkeiten) zu verwenden ist. Und das ist letztlich sogar bei Hardware-USB nicht anders. Auch hier muß der Descriptor zu den Fähigkeiten der Hardware passen und die Hardware (also der µC insgesamt) muss das tun, was der Host von ihr erwartet. Der eigentliche Witz ist: mindestens ca. 10% der real existierenden käuflichen Geräte tun das auch nicht (man erkennt sie am fehlenden USB-Logo). Die Hosts wissen das und setzen den USB-Standard gerade in Hinsicht auf das Energie-Management eher relaxed um. Wäre das nicht so, würden viele dieser Geräte nicht vernünftig funktionieren noch sehr viel mehr Bastler-Kram gnadenlos scheitern...
Das will ich nicht ausschließen, also daß der Fehler auch in meinem Code lag. Mein Code hat halt, in der Zeit nach dem USB-Transfer, die PS2++ Maus gepollt und die dort gewonnenen daten an die Standard Digispark Mausklasse übergeben. Das Pollen war auch vor dem nächsten USB-Transfer beendet. Wenn das Windows aber "beschäftigt" war (morgens, nach dem resume, wenn die gesammelten Virenscanner und Inventarisierungsdienste die IT uns auf die Kisten prügelt sich um die CPU stritten), dann gab es gerne mal Fehlerkennungen und wenn dann noch der Chrome irgendwas am USB durchprobiert hat, dann war öfters ab- und wieder anstecken angesagt. Das suspend etc. war auch eher egal, was mich halt gestört hat war, daß ich die dinger öfters mal neu mit Software bespielen musste, weil sie irgendwann die Arbeit komplett eingestellt haben. Da ich mich nicht hauptamtlich mit USB auseinandersetzten wollte habe ich halt die Hardwareplattform gewechselt ;-) Aber seitdem bin ich vorsichtig, wenn nicht-Experten VUSB als Lösung empfohlen wird.
Christian schrieb: > Und > wenn V-USB angeblich "dreckig" ist und trotzdem immer funktioniert Genau das tut es halt konzeptbedingt nicht, kann es nicht tun. Es müssen immer alle günstige Umstände zusammenkommen, damit es immer erwartungsgemäß funktioniert. Nur leider hält die bitterböse Realität zumindest gelegentlich auch die weniger günstigen Umstände bereit. Genau deswegen gibt es Standards, die auch für diese Fälle ein geordnetes Verhalten zur Schadensbegrenzung regeln. Und die werden halt von V-USB nur eingeschränkt oder garnicht implementiert.
Angehängte Dateien:
-
out.png
130 KB
Niklas G. schrieb: > Interessant, auch wenn man kontinuierlich Daten überträgt? Hatte mich (nach all den Jahren) mit den Angaben geringfügig vertan. Tatsächlich sind es 10 Achsen, 1 HAT, 80 Tasten. Das ›jstest-gtk‹ zeigt den HAT als zwei separate Achsen (9+10) an.
STM32F042F6P6, TSSOP20, kein Quarz (CRS), Außenbeschaltung 1..2 100nF, Software fällt fast fertig aus CubeMX raus.
Harald A. schrieb: > STM32F042F6P6, TSSOP20, kein Quarz (CRS), Außenbeschaltung 1..2 100nF, > Software fällt fast fertig aus CubeMX raus. Danke, wirklich interessanter Controller. Da ich für ihn aber noch einen VR von 5 auf 3.3V brauche (Der CH552e bringt den bereits "mit"), fällt dieser (für dieses Projekt) leider aus. Ich behalte mir den dennoch mal in der Hinterhand.
:
Bearbeitet durch User
Okay, kann ich verstehen. Ich habe auch schon ein paar Sachen mit dem CH552 gemacht. Sicher gibt es irgendwelche Debug-Möglichkeiten auch für den CH552, die sind aber beim STM32 um ein Vielfaches bequemer zu erreichen. Vor allem die gute Integration in die CubeIDE hilft enorm. Kann gerade bei USB ungemein helfen. Übrigens, 5/3.3V LDOs gibt es als SOT23 für 3ct. Und noch etwas: der CH552 hat einen LDO mit drin, den kannst Du sparen. Dafür brauchst Du den Quarz, beim STM32 nicht. Sehe gerade, der CH552e hat ja keinen Quarz-Anschluss, der Core hat aber kein CRS. Muss man darauf hoffen, dass die 48MHz für USB „irgendwie“ passen?
:
Bearbeitet durch User
Harald A. schrieb: > Sehe gerade, der CH552e hat ja keinen Quarz-Anschluss, der Core hat aber > kein CRS. Muss man darauf hoffen, dass die 48MHz für USB „irgendwie“ > passen? Nun, die 48Mhz für die USB werden mit Sicherheit "irgendwie" passen, da er ja nun auch mal darüber programmiert wird. Aber das müsstest du ja wissen da du ja "schon ein paar Sachen mit dem CH552 gemacht" hast.
Harald A. schrieb: > STM32F042F6P6, TSSOP20, kein Quarz (CRS), Außenbeschaltung 1..2 100nF, > Software fällt fast fertig aus CubeMX raus. Harald A. schrieb: > Okay, kann ich verstehen. Ich habe auch schon ein paar Sachen mit dem > CH552 gemacht. Sicher gibt es irgendwelche Debug-Möglichkeiten auch für > den CH552, die sind aber beim STM32 um ein Vielfaches bequemer zu > erreichen. Vor allem die gute Integration in die CubeIDE hilft enorm. > Kann gerade bei USB ungemein helfen. Beim STM32F042F6P6 ist das Problem aber, daß wenn man den USB-Code fürs Debuggen übersetzt, der Flash voll ist. Zum Glück gibt es inzwischen den STM32C071FBP6: ebenfalls TSSOP-20 mit USB, aber 128 KB Flash statt 32 KB. Der Nachteil ist, daß man den neuen USB-Stack von Microsoft benutzen muß (sofern man nicht alles von Hand machen möchte), der funktioniert nicht auf Anhieb, z.B. muß man für CDC ACM dies machen:
1 | HAL_PCDEx_PMAConfig(&hpcd_USB_DRD_FS, 0x00, PCD_SNG_BUF, 0x0040); |
2 | HAL_PCDEx_PMAConfig(&hpcd_USB_DRD_FS, 0x80, PCD_SNG_BUF, 0x0080); |
3 | HAL_PCDEx_PMAConfig(&hpcd_USB_DRD_FS, 0x81, PCD_SNG_BUF, 0x00c0); |
4 | HAL_PCDEx_PMAConfig(&hpcd_USB_DRD_FS, 0x03, PCD_SNG_BUF, 0x0100); |
5 | HAL_PCDEx_PMAConfig(&hpcd_USB_DRD_FS, 0x82, PCD_SNG_BUF, 0x0140); |
was völlig undokumentiert ist. Im Netz findet man verschiedene Varianten davon, diese hier funktioniert für mich.
Rene K. schrieb: > Harald A. schrieb: >> Sehe gerade, der CH552e hat ja keinen Quarz-Anschluss, der Core hat aber >> kein CRS. Muss man darauf hoffen, dass die 48MHz für USB „irgendwie“ >> passen? > > Nun, die 48Mhz für die USB werden mit Sicherheit "irgendwie" passen, da > er ja nun auch mal darüber programmiert wird. Aber das müsstest du ja > wissen da du ja "schon ein paar Sachen mit dem CH552 gemacht" hast. Ja, es waren exakt zwei Projekte auf Kundenwunsch. Wahrscheinlich passt es „irgendwie“ bei Raumtemperatur ODER die haben eine undokumentierte CRS-Funktion. Über eine genauere Spezififikation schweigt sich das Datenblatt leider aus. Aufgrund dessen habe ich einen Quarz am CH552 (ohne e) drangehängt. Es gibt übrigens auch im STM32-Bereich z.B. einen mit CAN-FD, der sich aber in einem gewissen Package nicht nutzen lässt, nur weil die Pins für den Quarz fehlen. Der interne Oszillator ist für CAN zu schlecht, es würde nur bei bestimmten Betriebsbedingungen zufällig funktionieren. Also selbst bei den „Etablierten“ gibt es unsinnige Varianten. Nicht falsch verstehen oder zickig werden, ein Forum dient lediglich dem Meinungsaustausch (dachte ich). Es steht Dir völlig frei alles so zu machen wie Du möchtest. Der Einwand mit dem Speicher beim STM32F042 ist IMHO nicht berechtigt. Das ist wahrlich kein Speichermonster aber für einfache Sachen reicht es dicke.
:
Bearbeitet durch User
Harald A. schrieb: > Der interne Oszillator ist für CAN zu schlecht, Hat der keine andere Möglichkeit? Externen Oszillator? LSE Quarz und MSI mit PLL vom LSE stabilisieren? MSI/HSI per Software über einen Timer kalibrieren?
Niklas G. schrieb: > Harald A. schrieb: >> Der interne Oszillator ist für CAN zu schlecht, > > Hat der keine andere Möglichkeit? Externen Oszillator? LSE Quarz und MSI > mit PLL vom LSE stabilisieren? MSI/HSI per Software über einen Timer > kalibrieren? Ich müsste genauer nachschauen, es war einer aus der STM32C092-Reihe mit hübschen superkleinen Packages. Musste dann mit dem (für diese Anwendung) riesengroßen 4x4mm vorlieb nehmen, es ging nicht anders. Nach Rücksprache mit FAEs kommt das bei ST häufiger vor, da die fabless nur eingekaufte IP-Cores zusammennageln. Das führt dazu, dass die Serien verkaufen, die mehr beinhalten als sie versprechen (gleicher Die) ODER das manchmal gewisse Features nicht sinnvoll nutzbar sind.
:
Bearbeitet durch User
Angehängte Dateien:
-
eject.jpg
38 KB
Sooo... Platine ist bestellt. Wahnsinn, bei JLCPCB für fünf Platinen, fertig Bestückt mit CH552E und dem Hühnerfutter gerade mal 12€ incl. Versand. Die Hardware habe ich auch fertig gemacht und geht dann ab morgen in den Druck.
Harald A. schrieb: > da die fabless nur eingekaufte IP-Cores zusammennageln Ja ist bekannt. Cleverer wär's wohl bei dem Gebäude den CAN nicht zu bewerben und auch die CAN Lizenzgebühr zu sparen...
Sehr schön. Zeig bitte mal Bilder wenn die Platine angekommen ist. Magst du auch noch mehr Teilen, für Leute die interessiert sind sowas nachzubauen? Ist die SW eine (abgewandelte) aus dem Fundus von WCH? Noch eine Frage aus Neugier. Warum verwendest du USB und kein Bluetooth-HID?
Christian schrieb: > Magst du auch noch mehr Teilen, für Leute die interessiert sind sowas > nachzubauen? Ja ich stelle dann alles auf GitHub bereit. Auch die STL Druckdaten gebe ich dann frei wenn alles so funktioniert wie es soll. Es werden auch Halterungen für 4040 Schienen dabei sein. Christian schrieb: > Noch eine Frage aus Neugier. Warum verwendest du USB und kein > Bluetooth-HID? Wer funkt kennt - nimmt Kabel! :-D Nein, das ist einfach eine praktische Entscheidung, der Rechner steht etwas entfernt vom SimPit und da ich an Ort und Stelle sowieso mehrere USB Hubs habe, ist es halt Kabel geworden. Das PCB ist auch ein klein wenig abgewandelt wurden, es werden nun zwei Tasten abgefragt. Ich brauchte noch eine Taste um den Hebel "scharf" zu stellen.
Prima Sache mit dem GitHub. Rene K. schrieb: > Wer funkt kennt - nimmt Kabel! :-D > Als alter "Funker" sehe ich das genau so :) Ich verwende ein BLE-HID am Motorrad wo ich mit Tasten am Lenker mein Navi steuere. Das ist ein umgebautes Shelly.
Thread beobachten
Seitenaufteilung abschalten
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.