Forum: Compiler & IDEs AT90USB Software Library für avr-gcc?


von avrfan (Gast)


Lesenswert?

Hi,
hat irgend jemand schonmal mit den AT90USB und dem GCC gearbeitet? Gibt 
es vielleicht einen Port der Library von Atmel auf den avr gcc?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Die Frage verstehe ich nicht.  Wenn ich mir die Zipfiles aus den
Appnotes auspacke, dann gibt's da überall ein Verzeichnis "iar"
und ein Verzeichnis "gcc" drin.  Das gcc-Verzeichnis enthält dabei
außer einem Makefile und einem .aps-File (für AVR Studio) auch noch
die Compilate, also ist das Ganze offensichtlich auch mal damit
compiliert worden. ;-)

Außerdem gibt's noch Dean Cameras "myUSB".

Eine Implementierung für den RZRAVEN-USB-Stick gibt es in der
"RES" (radio evaluation software):

http://www.atmel.com/dyn/resources/prod_documents/AVR2002.zip

Schließlich und endlich habe ich dem µracoli-Projekt:

https://savannah.nongnu.org/projects/uracoli/

noch eine CDC-Implementierung für AT90USB1287 & Co. spendiert, die
einen eher minimalistischen Ansatz verfolgt (ca. 1500 Zeilen C-Quelle
und knapp 500 Zeilen Header), während die anderen Projekte eher
umfassend sind (Host- und/oder Device-Implementierung, beliebige
USB-Klassen, adaptierbar für alle möglichen USB-Controller).

von avrfan (Gast)


Lesenswert?

Ich habe gerade herausgefunden das die Library anscheinend so ausgelegt 
ist das sie für IAR und GCC funktioniert. Ich muss da Atmel echt mal 
loben.

Jetzt muss ich nur noch durchsteigen. Hat das schonmal jemand verwendet? 
Erfahrungen?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

avrfan wrote:

> Jetzt muss ich nur noch durchsteigen.

Das ist genau der Punkt, warum ich das CDC (Emulation eines seriellen
Geräts) für µracoli neu geschrieben habe. ;-)  Die Komplexität der
anderen Implementierungen ist mehr als erschlagend.  Natürlich habe
ich es nicht neu geschrieben, ohne dabei auf den existierenden Code
zu schielen, man will ja schließlich nicht alle Fahrräder neu
erfinden.

Leider müsste man für eine Portierung auf AT90USB82/162 aber nochmal
einiges darin umschreiben, da diese Lowcost-Controller eine ziemlich
abgerüstete Variante des USB-Makros enthalten.

von avrfan (Gast)


Lesenswert?

Hi Jörg,
da haben wir wohl zeitgleich gepostet :)

>Leider müsste man für eine Portierung auf AT90USB82/162 aber nochmal
>einiges darin umschreiben...

Meinst du damit deine eigene Implementierung? Ich will nämlich den 
USB162 verwenden. Brauch den nur als Device. Host ergibt irgendwie wenig 
Sinn bei dem.

Naja, mal durch die Doku und die Sourcen schlagen

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

avrfan wrote:

> Meinst du damit deine eigene Implementierung?

Ja.

> Ich will nämlich den
> USB162 verwenden. Brauch den nur als Device. Host ergibt irgendwie wenig
> Sinn bei dem.

Hat nicht viel mit Host und Device zu tun: es gibt auch die ,,großen''
USB-AVRs in einer Version, die nur Device sein kann (AT90USB646 und
AT90USB1286).  Bei den ,,kleinen'' ist allerdings nochmals einiges
im Bereich des Businterfaces abgerüstet worden, da gibt es beispiels-
weise keine automatische Behandlung von Vbus-Änderungen mehr und sowas,
soweit ich das in Erinnerung habe.  Meine µracoli-Implementierung
benutzt aber diese Features im AT90USB64x/128x allesamt mit, daher
müsste ich sie umschreiben für den AT90USB162.

von Nico (Gast)


Lesenswert?

Also die Lib von Dean kann ich nur empfehlen. Früher hiess die MyUSB, 
seit kurzem LUFA. http://www.fourwalledcubicle.com/LUFA.php

Die ist deutlich aufgeräumter und einfacher nutzbar als die Atmel-"Lib" 
und auf GCC ausgelegt. Ausserdem ist sie durchgängig kommentiert und 
durch ein wenig preprocessor-magic auch auf allen USB-fähigen AVRs ohne 
grosse Anpassungen(nur ein paar defines) nutzbar.

von Nico (Gast)


Lesenswert?

> Bei den ,,kleinen'' ist allerdings nochmals einiges
> im Bereich des Businterfaces abgerüstet worden, da gibt es beispiels-
> weise keine automatische Behandlung von Vbus-Änderungen mehr und sowas,
> soweit ich das in Erinnerung habe.

Was meinst du mit "automatischer Behandlung von VBUS-Änderungen? 
Interrupt oder so wenn man es vom USB-Bus trennt?

Ich hab halt momentan das problem das ich versuche einen AT90USB162 fest 
an einem Board anzuschliessen. Nur bisher hab ich noch keinen weg 
gefunden einen Reset des Boards zu erkennen um dann auch den Chip zu 
resetten.

von Stefan B. (stefan) Benutzerseite


Lesenswert?

avrfan wrote:
> Hi,
> hat irgend jemand schonmal mit den AT90USB und dem GCC gearbeitet? Gibt
> es vielleicht einen Port der Library von Atmel auf den avr gcc?

Hast du dir schon LUFA angesehen?
http://www.mikrocontroller.net/articles/USB#Spezielle_USB-.C2.B5C

von avrfan (Gast)


Lesenswert?

Also ich sag mal so, auf der Seite gibt es Demo Sourcen für das STK526, 
also für AT90USB162

http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4440

Sollte also kein Thema sein. Bin aber noch am "durchsteigen" ;)

von Hmm... (Gast)


Lesenswert?

> Jetzt muss ich nur noch durchsteigen. Hat das schonmal jemand verwendet?
> Erfahrungen?

Ja, hab vor einiger Zeit basierend auf der Lib ein HID-konformes Gerät 
aufgesetzt. Im groß und ganzen kann man sich an einem langen Nachmittag
mit der Lib anfreunden.

Allerdings ist mir damals an einigen Stellen ein Problem mit der Größe 
von Datentypen aufgefallen. Konkret erinnere ich mich an diese 
Konstrukte:
1
...
2
..
3
#define Usb_get_dev_desc_length()         (sizeof (usb_dev_desc))
4
...
5
...
6
U8    data_to_transfer;
7
...
8
...
9
case DESCRIPTOR_DEVICE:
10
11
  data_to_transfer = Usb_get_dev_desc_length(); //!< sizeof (usb_user_device_descriptor);
12
13
  pbuffer          = Usb_get_dev_desc_pointer();
14
15
  break;
16
17
...
18
...

Das Problem mit der Variable data_to_transfer zieht sich durch die 
gesamte Lib, es werden munter 16 Bit Werte in die Variable geschrieben. 
Das macht sich allerdings erst bei großen USB-Packeten (>255 Byte) 
bemerkbar. Wenn ich damals nicht einen recht dicken Report-Deskriptor in 
der Anwendung gehabt hätte, wer mir das vielleicht noch nicht einmal 
aufgefallen.

Von diesem Bug und der etwas eigenwilligen Datentyp-Bezeichnungen (U8 
statt uint8_t) sind mir jetzt gerade aber keine größeren Probleme in 
Erinnerung.

Viel Erfolg :)

von avrfan (Gast)


Lesenswert?

Hi Hmm...
hast du den "Bug" bei dir gerade gebogen oder hast du es so gelassen?

Ich bin gerade dabei die Demo mal mit dem GCC zu compilieren. Mal 
schauen wo ich rauskomme

von Hmm... (Gast)


Lesenswert?

> Hi Hmm...
> hast du den "Bug" bei dir gerade gebogen oder hast du es so gelassen?

Da der Report-Deskriptor knapp 600 Byte groß war, bin ich nicht drum 
herum gekommen. Ansatz war, die betreffende Variable auf U16 
umzustellen. Inwiefern noch weitere Änderungen notwendig waren, hab ich 
jetzt nicht mehr in Erinnerung.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Nico wrote:

> Was meinst du mit "automatischer Behandlung von VBUS-Änderungen?
> Interrupt oder so wenn man es vom USB-Bus trennt?

Genau, bei den großen USB-AVRs bekommt man einen "Vbus transition
interrupt", wenn sich der Vbus-Pegel (bei aktiviertem Vbus, ähem,
OTG-Pad) ändert (und man den Interrupt freigeschaltet hat).  Das
muss man sich wohl auf den kleinen USB-AVRs irgendwie mit
Externinterrupts emulieren, wenn ich das richtig verstehe.

von avrfan (Gast)


Lesenswert?

Das mit dem U8, U16 usw hat anscheinend was mit Little/Big-Endian zu 
tun. Hab gerade in der compiler.h die entsprechenden Defines gesehen.

von avrfan (Gast)


Lesenswert?

>Genau, bei den großen USB-AVRs bekommt man einen "Vbus transition
>interrupt", wenn sich der Vbus-Pegel (bei aktiviertem Vbus, ähem,
>OTG-Pad) ändert (und man den Interrupt freigeschaltet hat).

Klingt als bräuchte man das nur für den OTG Host. Als Bus Powered Device 
kann man damit eh nix anfangen, oder?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

avrfan wrote:

> Als Bus Powered Device
> kann man damit eh nix anfangen, oder?

Das stimmt, aber auch ein Device kann ja self-powered sein, muss ja
nicht gleich ein Host sein dafür.

von avrfan (Gast)


Lesenswert?

Hm, ich nehme an Atmel sieht in den USB162 in erster Linie Bus Powered 
Devices. Zielgruppe sind eben HID Geschichten, da juckt das 
normalerweise nicht.

Auf der andere Seite, was passiert, wenn man ein Self Powered Device hat 
und man zieht den USB Stecker, ohne den Fall zu behandeln?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

avrfan wrote:

> Auf der andere Seite, was passiert, wenn man ein Self Powered Device hat
> und man zieht den USB Stecker, ohne den Fall zu behandeln?

Wichtiger ist der umgekehrte Fall: wenn man wieder angestöpselt wird,
dann muss man die ganze connect-Prozedur einleiten.

Beim Abziehen will man aus diesem Grunde natürlich alles ,,erden'',
was noch irgendwie mit USB zu tun hat.

von avrfan (Gast)


Lesenswert?

Ich habe gerade einen Schaltplan von Olimex ausgegraben. Da wurden 
einfach zwei 47k Widerstände zwischen VCC und GND geschaltet und 
dazwischen geht's weiter auf PC4. Ist nur dummerweise kein INT sondern 
höchstens ein PCINT.

Einziger Vorteil von dem Pin, er hat ansonsten keine Sonderfunktion. Der 
Rest ist dann wohl Sache der Software

Naja, mal weiterstricken. Komme gut vorwärts. Hab nur ein Problem, hab 
keine USB162 hier zum Testen :-(. Hoffe die kommen morgen

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
Noch kein Account? Hier anmelden.