Mehrere V-USB Anwendungen auf einem AVR möglich?

Zum Glück haben wir den ersten April, sonst könnte man meinen, das 
versuchte tatsächlich jemand.

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)

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!?

Das ist vollkommen richtig. :-) für kleinere Dinge bedarf es Weißgott 
kein ARM. Der Mega32u4 ist ja auch nicht gerade Schwachbrüstig.

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

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.

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?!?

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.

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.

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.

PC4... nicht PC9.

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.