Gast
#1110126
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?
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).
Gast
#1110154
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?
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.
Gast
#1110253
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
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.
Gast
#1110274
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.
Gast
#1110283
> 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.
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
Gast
#1110315
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" ;)
Gast
#1110338
> 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 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
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 :)
Gast
#1110353
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
Gast
#1110374
> 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.
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.
Gast
#1110406
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.
Gast
#1110414
>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?
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.
Gast
#1110468
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?
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.
Gast
#1110536
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
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.