Moin! Wenn einer auf die Schnapsidee kommen würde, verschiedene V-USB Anwendungen wie z.B. einen USBasp und einen CDC-232, auf einem AVR-Chip zu kombinieren, wäre das theoretisch machbar? Wären das dann z.B. 2 "Interfaces" mit 2 VID/PID-Paaren?
Zum Glück haben wir den ersten April, sonst könnte man meinen, das versuchte tatsächlich jemand.
Moin, Mal vom Datum abgesehen - iirc gibts im Linuxkernel in der Unterabteilung USB-Gadget so Konstrukte, mit denen man ein "Composite"-Device basteln kann. Also eben z.b. ein Geraet mit 1x USB-Hardwareanschluss, das sich aber beim Host als "mehrere Geraete" anmeldet. So koennt's - wenn ueberhaupt - wahrscheinlich eher funktionieren als mit 2 getrennten USB-Links und den damit verbundenen fiesen Interrupt- und sonstigen Sauereien. Gruss WK
batman schrieb: > Moin! > Wenn einer auf die Schnapsidee kommen würde, verschiedene V-USB > Anwendungen wie z.B. einen USBasp und einen CDC-232, auf einem AVR-Chip > zu kombinieren, wäre das theoretisch machbar? Ja. Dafür sind USB Composite Devices da. Wie die Deskriptoren dafür aufgebaut sind, findest Du im USB-Standard: http://www.usb.org/developers/docs/usb20_docs/#usb20spec Da darfst Du Dir übrigens auch bei der Gelegenheit nachlesen, warum bei Low Speed keine Bulk Endpoints zulässig sind und dass CDC-ACM mit Bastellösungen wie VUSB eben gegen den USB-Standard verstößt. fchk
batman schrieb: > V-USB > Anwendungen wie z.B. einen USBasp und einen CDC-232 Kann vUSB überhaupt CDC? Dachte die können nur HID und für HID gibts kein CDC ...
Ja, hab ich ausprobiert, auf Windows XP braucht man einen kleinen Treiberpatch. Dann können auch Bulk-Transfers verbotenerweise gemacht werden. http://www.recursion.jp/prose/avrcdc/cdc-232.html
Also ich hab jetzt die CDC-232 Firmware auf einen USBasp geflasht und das funktioniert problemlos. Beim Einstecken gibts auf Windows einen COM-Port. Kann man nicht irgendwie die eine Anwendung auf dem AVR runterfahren, USB-Disconnect und dann die jeweils andere starten, Connect mit anderer USB-Konfig?
Mit V-USB würde ich heute garnicht mehr anfangen. Auch Atmel hat schöne USB MC im Angebot die extra für solche Anwendungen gemachte sind. Die AT90USB und die Atmega U2/4 Reihe. Mit einem Atmega32U4 hab ich solch eine Composite Anwendung ohne Probleme zum laufen gebracht, ein USB-HID und ein CDC mit jeweils eigenem Endpoint zeitgleich. (Mit Lufa als USB Stack)
DraconiX schrieb: > Die > AT90USB und die Atmega U2/4 Reihe. Die AT90USB dürften auch bald unter Legacy fallen und/oder sind zu teuer ... DraconiX schrieb: > Mit einem Atmega32U4 hab ich solch eine Composite Anwendung ohne > Probleme zum laufen gebracht Oh, die hab ich wohl übersehen ... Muss ich mir mal anschauen :) *edit*: Gerade gekuckt ... Die gibts wohl noch nicht so lange. Wenn ich dir vorher gesehen hätte, hätte ich mir vmtl die STM32F1-Dingens garnicht angeschaut. Naja, ist nie schlecht sowas in der Toolbox zu haben :)
:
Bearbeitet durch User
Mampf F. schrieb: > DraconiX schrieb: >> Die >> AT90USB und die Atmega U2/4 Reihe. > > Die AT90USB dürften auch bald unter Legacy fallen und/oder sind zu teuer > ... Wenn Du was billiges willst: PIC16F1454. Mit Hardware-USB. Gibts auch in DIL. Als Außenbeschaltung brauchst Du nur einmal 100n zwischen VCC und GND. D+ und D- anklemmen, und das Ding läuft. Ohne Quarz, weil sich die USB-PLL auf den Host-USB-Takt synchronisiert. fchk
Frank K. schrieb: > Wenn Du was billiges willst: PIC16F1454. Mit Hardware-USB. Gibts auch in > DIL. Nana, mit PIC16F fang ich nicht mehr an :D Ich hab früher mit PIC16F84 und PIC16F873 beruflich gearbeitet ... Zu der Zeit, wo es noch keine freien C-Compiler gab. Also in Assembler und mir hat die altertümliche Architektur überhaupt nicht gefallen. Insbesondere, weil ich Hobbymäßig mit den AVRs schon gefühlt weiter war.
Mampf F. schrieb: > *edit*: Gerade gekuckt ... Die gibts wohl noch nicht so lange. Wenn ich > dir vorher gesehen hätte, hätte ich mir vmtl die STM32F1-Dingens > garnicht angeschaut. Naja, ist nie schlecht sowas in der Toolbox zu > haben :) Der F103 kann doch auch USB in Hardware abbilden?! Da brauchst du doch kein V-USB!?
DraconiX schrieb: > Der F103 kann doch auch USB in Hardware abbilden?! Da brauchst du doch > kein V-USB!? Jap richtig :) Aber ich hätte mir den F103 nicht angeschaut, wenn ich Hardware USB für AVRs gehabt hätte. Hab nur meine Kenntnisse Richtung STM32 erweitert, weil vUSB nicht gut funktioniert, wenn man zusätzlich mit Timer-Interrupts arbeiten muss. :) Aber es ist ja kein entweder oder ... Wenn ich eine Applikation habe, wo ein AVR mit Hardware-USB ausreicht, werde ich natürlich den verwenden :)
Das ist vollkommen richtig. :-) für kleinere Dinge bedarf es Weißgott kein ARM. Der Mega32u4 ist ja auch nicht gerade Schwachbrüstig.
DraconiX schrieb: > Der Mega32u4 ist ja auch nicht gerade Schwachbrüstig. leider gibt es nur 32k und keine 64k/128k ein mega 1284u4 wäre nett
Joachim B. schrieb: > DraconiX schrieb: >> Der Mega32u4 ist ja auch nicht gerade Schwachbrüstig. > > leider gibt es nur 32k und keine 64k/128k > > ein mega 1284u4 wäre nett wie wärs damit? http://www.microchip.com/wwwproducts/en/AT90USB1287 fchk
Frank K. schrieb: > wie wärs damit? > > http://www.microchip.com/wwwproducts/en/AT90USB1287 > > fchk nicht übel.... hmmm muss ich mal sehen, der Vorteil meiner mighty mini 1284p ist ja das ich ihn im die Arduino IDE eingebunden habe, der Nachteil eben der FTDI oder CH340 Controller immer extra angesteckt werden muss Das in eine kleinen Platine wäre halt toll, aber das würde ja wieder ein völlig neues eigenes Projekt werden, dazu fehlt mir die Zeit bzw. die Fachinformatik und CAD Erfahrung um das zügig umzusetzen.
Joachim B. schrieb: > der Vorteil meiner mighty mini 1284p ist ja das ich ihn im die Arduino > IDE eingebunden habe, Vorteil?! Das ist genauso wie ein Ferrari mit Diesel zu betanken. :-D
DraconiX schrieb: > Vorteil?! Das ist genauso wie ein Ferrari mit Diesel zu betanken. :-D klar ist das ein Vorteil, ich kann jede Arduino LIB schneller am 1284p nutzen als mir alles selbst zu schreiben und im AVR Studio einzusetzen. Man kann alles mies reden, ich freue mich über gesparte Entwicklungszeit. PS Mythos Ferrari mein Fiesta ist nun (ok fast) so schnell wie ein 308 GTB.
Joachim B. schrieb: > klar ist das ein Vorteil, ich kann jede Arduino LIB schneller am 1284p > nutzen als mir alles selbst zu schreiben und im AVR Studio einzusetzen. > Man kann alles mies reden, ich freue mich über gesparte > Entwicklungszeit. Das hat nichts mit Kürzung der Entwicklungszeit zu tun, ich und mein Chef freut es zum Beispiel wenn ich für die selbe Aufgabe - für die in Arduino notwendigen Overheat - statts dem teuren 1284p ein kleinen billigen Tiny einsetzen kann... Weil der Kosten / Nutzenfaktor da an erster Stelle steht. Und ja, wer einen MC programmiert sollte schon wissen WAS er da eigentlich macht... Da kommen dann auch nicht diese komischen Fragestellungen ala: "Ich möchte einen MP3 Player aus meinem Arduino bauen, natürlich mit Display, I-Net und er soll von der ISS fernsteuerbar sein während ich auf dem Himalaya wandere... Achja: darf nur mit einer Knopfzelle laufen - für immer!" Ich selbe nutze für Protos die China-Arduino-Clone - die Hardware - einfach weil se unverschämt billig sind. Programmiere sie aber über GCC, weil ich da meine Biblios habe, meine Freiheit, und den Flash nicht mit unnötigem Müll zu ballere - so wie es das Arduino Framework macht. Für den "Maker" daheim, sehr gerne, da freue ich mich über die Dinger, weil sie den Markt schön billig halten :-D in der Industrie wird der Arduino oder dessen Umgebung nie Fuß fassen können, alleine schon wegen der Lizenzpolitik.
DraconiX schrieb: > mein > Chef freut es zum Beispiel wenn ich für die selbe Aufgabe - für die in > Arduino notwendigen Overheat - statts dem teuren 1284p ein kleinen > billigen Tiny einsetzen kann... Weil der Kosten / Nutzenfaktor da an > erster Stelle steht. mein Chef freut es wenn es für das Labor innerhalb weniger Tage funktioniert, da kommte es bei Einzelstücken nicht auf 1,-€ oder 10,-€ Hardwarekosten an. > Und ja, wer einen MC programmiert sollte schon wissen WAS er da > eigentlich macht... ich habe ja mit AVR Studio pur AVR angefangen (und früher HEX in den CBM und PC1500 getackert), nun freue ich mich das ich den Lötkram minimiere und die Teile billiger bekommen und vom Steckbrett gleich auf die PCB komme. jedem das seine
:
Bearbeitet durch User
Joachim B. schrieb: > mein Chef freut es wenn es für das Labor innerhalb weniger Tage > funktioniert, da kommte es bei Einzelstücken nicht auf 1,-€ oder 10,-€ > Hardwarekosten an. Korrekt, das ist ein Argument, jedoch kommt bei uns z.b. jährlich jemand ins Labor und prüft alle elektrischen Geräte - da würde jedes "Selbstgebautes" Teil oder ein Arduino oder Konsorten durch die Konformitätsprüfung fallen - mal so am Rande ;-) Nein kein Ding, für den Hausgebrauch, um mal nen paar LEDs blinken zu lassen ist das schon top. Die Hardware ist gut und nutze ich selber ja auch - halt den Softwareframework dahinter nicht. Joachim B. schrieb: >> Und ja, wer einen MC programmiert sollte schon wissen WAS er da >> eigentlich macht... > > ich habe ja mit AVR Studio pur AVR angefangen Bei dir mag das gehen, du scheinst auch die Arbeitsweise hinter einem µC zu verstehen - aber ich verweise da gerne mal auf das neueste "Forumsmitglied mit seinem Problem"... und das ist genau das wo die Geschichte hinführt, alle wollen, irgendwie klappt es dann mal irgendwann mit fremdhilfe, aber eigentlich weiß er garnicht warum das so ist: Beitrag "arduino hysterese mit ds18b20" Weißt du was ich damit meine?!?
DraconiX schrieb: > Weißt du was ich damit meine?!? absolut! immer wieder die Anfragen, "ich will mit dem rasPI zum Mond, habe aber keine Ahnung von Elektronik oder programmieren, kann mir jemand helfen?" da schalte ich dann auch ab! DraconiX schrieb: > jährlich jemand > ins Labor und prüft alle elektrischen Geräte - da würde jedes > "Selbstgebautes" Teil oder ein Arduino oder Konsorten durch die > Konformitätsprüfung fallen - mal so am Rande ;-) PS bei uns auch nur tue ich mir das mit Netzteile bauen nicht mehr an, alles Kleinzeugs bekommt 5V/12V/24V Steckernetzteile, das dürfen die dann prüfen!
:
Bearbeitet durch User
Joachim B. schrieb: > leider gibt es nur 32k und keine 64k/128k > > ein mega 1284u4 wäre nett Habe mal geschaut: Bei den Chinesen kostet ein STM32F103 ziemlich genau das Gleiche wie ein ATMega32U4. Beide sind auf einer kleinen Platine, die man auf ein Steckberett oder Lochraster montieren kann. Zum STM32F1 findet man allerdings viel weniger Infos/Tutorials als für AVR. Damit ist die Einstiegshürde etwas höher. Und dass es ein 3,3V-Controller ist, kommt Einsteigern auch nicht gerade entgegen. Dafür bekommt man beim STM32 einen viel leistungsstärkeren Controller, mit aktuellerem Kern (ARM Cortex M3) und mächtiger Peripherie. Damit haben beide Controller ihre Daseinsberechtigung ;)
Stimmy schrieb: > Habe mal geschaut: Bei den Chinesen kostet ein STM32F103 ziemlich genau > das Gleiche wie ein ATMega32U4. Beide sind auf einer kleinen Platine, > die man auf ein Steckberett oder Lochraster montieren kann. > > Zum STM32F1 findet man allerdings viel weniger Infos/Tutorials als für > AVR. Damit ist die Einstiegshürde etwas höher. > Und dass es ein 3,3V-Controller ist, kommt Einsteigern auch nicht gerade > entgegen. > Dafür bekommt man beim STM32 einen viel leistungsstärkeren Controller, > mit aktuellerem Kern (ARM Cortex M3) und mächtiger Peripherie. > > Damit haben beide Controller ihre Daseinsberechtigung ;) Völlig korrekt. Der ARM ist halt ein mächtiges Werkzeug, mit ihm umgehen will erstmal gelernt sein / werden. Ich mache gerade meine ersten Gehversuche mit dem F103 und es ist schon ein himmelweiter Unterschied zu einem Mega32u4. Die 32k des Mega sehe ich nun nicht so als Hürde, bis jetzt bin ich noch bei keinem Projekt an dessen Grenzen gestoßen, und ich hatte schon viele damit. Der ARM ist halt durch die DMA deutlichst flinker und modularer als ein AVR, sollte man dies brauchen - dann sollte man dies auch nutzen. Und um allein ein Pin zu konfigurieren bedarf es beim ARM schon gefühlte 500 Zeilen Code :-D Beim AVR ist das halt immer noch ein Einzeiler. :-D Halt da wo man den jeweiligen µC braucht soll er auch hin, aber ein Non-Plus-Ultra gibt es nicht - wird es auch nie.
Könnte man nicht einfach zwei Firmware's im AVR haben und einfach zwischen denen umschalten ? prinzipiell müsste das doch gehen.
Matthias W. schrieb: > Könnte man nicht einfach zwei Firmware's im AVR haben und einfach > zwischen denen umschalten ? prinzipiell müsste das doch gehen. Wie möchtest du "umschalten"? Das würde sicherlich nicht ohne Änderungen an vUSB selbst funktionieren und der ist so optimiert, dass das USB-Timing fast exakt eingehalten wird - sogar die Zyklus-Zeiten sind an der Hand abgezählt. Jegliche Änderungen an dem Code würden dazu führen, dass vUSB nicht mehr funktioniert. Das würde schon da anfangen, dass es nur einen Interrupt-Handler für INT0 gibt. Oder wenn man die Adressen auf die USB-Descriptoren dynamisch auslegen würde, würde sich sicherlich auch am Timing etwas ändern. Glaub nicht, dass das funktioniert ...
Imho kann man VUSB jederzeit beenden und mit anderer Konfig. neu starten. Wenn nur jeweils eine Anwendung auf dem AVR aktiv ist, kann ja die andere praktisch alle Hardware-Resourcen (außer etwas belegtem Flash) nutzen. Im Falle CDC/USBasp würde das auch reichen, da die sowieso nie gleichzeitig laufen. Nur wird sich das CDC-Device auf dem Host wohl nicht mal eben sein Backend abschalten lassen, wenn der USBasp laufen will.
DraconiX schrieb: > Und um allein ein Pin zu konfigurieren bedarf es beim ARM schon gefühlte > 500 Zeilen Code :-D Beim AVR ist das halt immer noch ein Einzeiler. :-D Und beim ARM ist es ein Zweizeiler. Und das auch längst nicht bei allen, es gibt auch welche da geht das einfacher als beim AVR. Übertreibungen erhöhen ja manchmal die Anschaulichkeit aber man kanns auch echt übertreiben.
:
Bearbeitet durch User
Bernd K. schrieb: > DraconiX schrieb: > Und um allein ein Pin zu konfigurieren bedarf es beim ARM schon gefühlte > 500 Zeilen Code :-D Beim AVR ist das halt immer noch ein Einzeiler. :-D > > Und beim ARM ist es ein Zweizeiler. Und das auch längst nicht bei allen, > es gibt auch welche da geht das einfacher als beim AVR. > > Übertreibungen erhöhen ja manchmal die Anschaulichkeit aber man kanns > auch echt übertreiben. Nunja, man kann es sich auch schönreden ;-) und so übertrieben ist das garnicht, um PC9 als normalen Ausgang zu definieren bedarf es beim ARM, hier ein STM32:
1 | //GPIOC Clock enable
|
2 | RCC->AHBENR |= RCC_AHBENR_GPIOCEN; |
3 | //GPIOC4 aß Output
|
4 | GPIOC->MODER |= GPIO_MODER_MODER4_O; |
5 | //Push Pull config
|
6 | GPIOC->OTYPER &= ~(GPIO_OTYPER_OT_4); |
7 | //Max speed for Portpin
|
8 | GPIOC->OSPEEDR |= GPIO_OSPEEDER_OSPEEDR4; |
9 | //ensure pu or pd are disable
|
10 | GPIOC->PUPDR &= ~(GPIO_PUPDR_PUPDR4); |
Und beim AVR:
1 | DDRC |= (1<<DDC4); |
Gleiches Ergebnis. Beim AVR sind es ein Takt - beim ARM sind es dann gleich, dank RMW, gleich mal elf Takte dafür. Das ist aber natürlich ganz normal, der Funktionsumfang eines Pins bei einem ARM ist um ein vielfaches höher als bei einem AVR, das will selbstverständlich konfiguriert werden. Aber die Aussage das es deutlich umständlicher ist, ist nicht an den Haaren herbeigezogen.
DraconiX schrieb: > Und beim AVR: > DDRC |= (1<<DDC4); > Und beim ARM:
1 | FGPIOA->PDDR = (1 << 4); |
Um Pin A4 auf Ausgang zu schalten. Wen Du Dir nämlich gezielt den ARM mit der kompliziertesten GPIO-Einheit unter der Sonne als Beispiel nimmst um daraus eine Aussage über ARM zu verallgemeinern (obwohl die Komplexität von STM-Peripherie mit ARM überhaupt nichts zu tun hat), dann nehm ich einfach den ARM mit der einfachsten GPIO um meinen Punkt zu untermauern: Nämlich die beliebte mit 5V betriebene, weniger als 1$ kostende NXP Kinetis E Reihe.
Mampf F. schrieb: > Nana, mit PIC16F fang ich nicht mehr an :D Ich hab früher mit PIC16F84 > und PIC16F873 beruflich gearbeitet ... Zu der Zeit, wo es noch keine > freien C-Compiler gab. Also in Assembler und mir hat die altertümliche > Architektur überhaupt nicht gefallen. Insbesondere, weil ich Hobbymäßig > mit den AVRs schon gefühlt weiter war. Nimms jetzt bitte nicht persönlich, aber im Gegensatz zu Deiner Einstellung hat Microchip (auch) die PIC16 Familien weiterentwickelt. Nur soviel zu "altertümlicher Architektur"... Heutzutage als Gegenargument zu PIC16 den PIC16F84 anzuführen ist fast schon unseriös, die Welt hat sich weitergedreht.
Edson schrieb: > Nimms jetzt bitte nicht persönlich, aber im Gegensatz zu Deiner > Einstellung hat Microchip (auch) die PIC16 Familien weiterentwickelt Auf den ersten Blick ins Datenblatt arbeitet auch der neue PIC16F1454 genauso altertümlich wie der 16F84 ... Ich sehe ein W-Register, das dem altertümlichen Akku-Register beim Z80 entspricht ... Die haben wohl nur die Peripherie aktualisiert, aber von schön in Assembler programmieren sehe ich da immer noch nichts ;-) Für mich wäre auf der PIC16F1454 ein Rückschritt :)
:
Bearbeitet durch User
Mampf F. schrieb: > Die haben wohl nur die Peripherie aktualisiert, aber von schön in > Assembler programmieren sehe ich da immer noch nichts ;-) Wieso auch, wenn es auch in C geht. Ja, auch mit dem frei runterladbaren XC8. Auch hier hat sich die Welt weiter gedreht. fchk
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.