Nabend zusammen, nach langer Zeit und vollständiger Zufriedenheit mit meinem STK600 muss ich mich mal wieder an die AVR Gemeinde wenden. Da man sich ja auch mal weiterentwickeln muss, bin ich nun von den ATMEGAS zu den XMEGAS übergegangen. Aktuell im Test ist ein ATXMEGA128A1 AU und ein 64A1 U. Für ein neues Projekt wollte ich mich mal mit den USB Funktionen dieser Bausteine auseinander setzen. Zu diesem Zweck habe ich ein (nun mehrfach auf Funktion getestetes) MiniUSB Kabel mit der kleinen USB Dose verbunden. VBUS ist dabei abgeklemmt (da ich ja kein Host bin). Nachdem ich in alter ASM Manier an der Konfiguration des Chips gescheitert bin, fand ich es naheliegend, die Beispiele aus dem ASF von Atmel mal anzutesten (die ja genau für diese Chips sind)(CDC, HID, HID Maus, HID Tastatur). Ich habe daraufhin 2 Tage Doku gelesen (leider ziehe ich ASM C immer noch vor und muss auch da jetzt erstmal umsteigen) und dann die Projekte kompiliert und auf den Chip geschoben (Habe auch schon mehrere Chips getestet). Leider war dem USB Port auch bei keinem der Beispiele etwas zu entlocken, daher meine Frage: Muss man noch irgendetwas weiteres auf dem STK600 verbinden (hatte eigentlich im Kopf, dass die Routingkarten das bei den USB Chips durchschieben)? Die USB beschaltung sollte ja mit dem STK600 eigentlich direkt gehen. OSC Fuses gibt es ja bei den XMEGA nicht mehr, das wird ja auch per Register eingestellt (#define CONFIG_SYSCLK_SOURCE SYSCLK_SRC_RC32MHZ). Kann ich mich da anderweitig vertimed haben? Hat jemand einen Tipp? Ober auch eine Testmöglichkeit? Normalerweise bekommt man unter Windoof ja selbst ein Ping, wenn man ne Gabel in den USB Port schiebt, aber hier ist einfach stille... Grüße in großer Verzweifelung, Wolti
Wie heißen die Chips genau? Der "ATXMEGA128A1-AU" hat definitiv kein USB (und ist auch noch ziemlich verbuggt). http://www.atmel.com/devices/atxmega128a1.aspx Was du brauchst ist der "ATXMega128A3U-AU". Einen "ATMega64A1-U" gibt es afaik nicht. Einen ATMega64A1-AU wohl eher, aber auch der hat kein USB. http://www.atmel.com/devices/atxmega64a1.aspx Was du brauchst ist der "ATXMega64A4U-AU". da1l6
Danke, Asche über mein Haupt... Ich denke, die Verzweifelung hat mich etwas betriebsblind gemacht. Hat jemand nen Tipp, wo man so etwas hier in Deutschland bekommen könnte? Das Große R und das große C halten sich in dieser Hinsicht sehr bedeckt... Danke und Grüße, Daniel
Nabend zusammen, nach meinem ersten schon recht dummen Fehler, habe ich daraus gelernt und mir die richtigen Controller besorgt. Arbeite aktuell mit dem ATXMega128A1U. Dieser hat laut Datenblatt seinen USB Anschluss onboard. Leider ist das Resultat exakt gleich geblieben. Beim testen der ASF Examples (und umschiffen einiger STK600 Bugs) musste ich feststellen, dass mein M$ Betriebssystem einfach "nichts" erkennt. Ich habe sowohl das HID Generic, wie auch das HID Tastatur/Maus Beispiel (CDC auch) getestet. Mit gleichem ernüchternden Erfolg. Erster Gedanke: Timing Falsch. Also Flux die LED's dran geklemmt und gesehen, dass das Beispiel anscheinend den internen Oszi mit 16MHz taktet. Eigentlich scheinen für die Beispiele "48MHz" über den USB Host synchronisiert zu werden. Passt also irgendwie nicht. Meine Frage also: Ich bin davon ausgegangen, dass die Beispiele direkt lauffähig sind, da sie extra für den atxmega128A1U+STK600 gemacht sind. Die Routingkarte ist auch richtig gewählt/erkannt und der xmega nutzt den internen Oszi (extern abgeschlatet), wie es vorgegeben ist (mit externer Quelle auch nach Anleitung getestet). Leider ohne irgendeinen Erfolg. Bin daher für jede Idee dankbar, die mein geistiges Versagen aufdecken könnte :-) Grüße, Daniel
Der sollte mit 24 MHz takten und sich mit dem start of frame bei usb sync. sonst wird das nix. Die Beispiele für die dev boards sind direkt lauffähig, sollten die für Stk600 wohl auch sein?! Einfach Samplesource mit richtigem Prozessor wählen und darauf flashen... Grüße Basti
Habe einen eigenen kleinen Atxmega128A1U Board mit USB Schnittstelle gebaut. Im Atmel Studio 6.0 habe ich das User Board – XMEGA AU template für die Projekterstellung verwendet. Im ASF Wizard das USB CDC Modul gewählt ( für meine Anwendung passend). Es sind in conf_usb.h und conf_clock.h einige Ergänzungen nötig. Siehe Beispiel: http://asf.atmel.com/docs/latest/xmegab/html/udi_cdc_quickstart.html Auf meinem Board gibt es einen externen 16MHz Quarz, daher waren bei mir folgende Zeilen im conf_clock.h nötig: #define CONFIG_SYSCLK_SOURCE SYSCLK_SRC_RC32MHZ #define CONFIG_SYSCLK_PSADIV SYSCLK_PSADIV_1 #define CONFIG_SYSCLK_PSBCDIV SYSCLK_PSBCDIV_1_2 #define CONFIG_USBCLK_SOURCE USBCLK_SRC_RCOSC #define CONFIG_OSC_RC32_CAL 48000000UL #define CONFIG_OSC_AUTOCAL_RC32MHZ_REF_OSC OSC_ID_USBSOF Das USB Modul wird nicht automatisch gestartet. Daher sollte in main.c noch folgendes stehen: board_init(); udc_start(); udc_attach(); // Attach USB Device Im Atmel Studio Solution Explorer findest Du ganz am Schluss ein .inf File ( Device Treiber). Wenn die Software auf der MCU ist und Du die USB Verbindung mit dem PC machst, kannst Du diesen Treiber installieren :-). Ich habe unter Windows eine Qt Anwendung für einfachen Datenaustausch über USB geschrieben und dafür die libusbK Library verwendet. Wenn Du diesen Weg einschlägst, musst du mit dem libusbK-inf-wizard den passenden Treiber generieren. Falls Du unter Linux arbeitest, kannst Du mit Wireshark den USB Verkehr mitschneiden ( unter Windows geht das mit Wireshark meines Wissens nicht). Habe stattdessen USBlyzer verwendet ( 30 Tage Evaluation, dann kostenpflichtig). Hoffe das hilft Dir weiter. Gruss, michi
Deine Clock source defines ergeben irgendwie keinen Sinn... Wenn du nen 16 MHz Quartz hast, dann brauchst du keine Autocalibrierung. Außerdem solltest du die 16 MHz irgendwie auf 48 MHz bekommen und nur für den Systemtakt auf 24 MHz runter teilen. Wahrscheinlich gibt es auch noch andere Varianten (16 MHz nur für USB), aber ich weiß nicht inwiefern das die ASF unterstützt. Evtl. musst du da selbst ran... würde erstmal mit dem Internen Takt wie in den Samples arbeiten und dann den nächsten Schritt machen... Grüße Basti
Sry, war noch eine alte Version mit internem Oszi. Bei folgender wird der System Clock mittels PLL und externem Oszi generiert. Der USB Clock wird durch den internen RC Oszi generiert: #define CONFIG_SYSCLK_SOURCE SYSCLK_SRC_PLL // Fpll0 = (Fclk * PLL_mul) / PLL_div #define CONFIG_PLL0_SOURCE PLL_SRC_XOSC #define CONFIG_PLL0_MUL (32000000UL / BOARD_XOSC_HZ) #define CONFIG_PLL0_DIV 1 // Fbus = Fsys / (2 ^ BUS_div) #define CONFIG_SYSCLK_PSADIV SYSCLK_PSADIV_1 #define CONFIG_SYSCLK_PSBCDIV SYSCLK_PSBCDIV_1_1 #define CONFIG_USBCLK_SOURCE USBCLK_SRC_RCOSC #define CONFIG_OSC_RC32_CAL 48000000UL #define CONFIG_OSC_AUTOCAL OSC_ID_RC32MHZ #define CONFIG_OSC_AUTOCAL_REF_OSC OSC_ID_USBSOF In user_board.h musst Du noch folgende defines ausklammern: #define BOARD_XOSC_HZ 16000000 #define BOARD_XOSC_TYPE XOSC_TYPE_XTAL // External oscillator startup time #define BOARD_XOSC_STARTUP_US 100 Findest Du auch unter: http://asf.atmel.com/docs/latest/xmega/html/sysclk_quickstart_use_case_2.html Gruss
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.