ATmega32U2 USB-Kommunikation

[Samuel (Gast)]

Hallo zusammen,
ich bin gerade dabei ein Projekt mit einem ATmega32U2 Controller zu 
starten. Der Controller soll über die USB Schnittstelle vom PC aus 
gesteuert werden, Ausgänge setzen und Eingänge abfragen. Im Prinzip 
müssen nur Zahlen übertragen werden, das Programm auf dem Computer und 
im Controller erledigen den Rest. Nun stehe ich leider vor einem 
riesigen Problem wie ich die USB-Schnittstell von dem Controller 
ansprechen kann. Ich habe mich schon etwas eingelesen in die 
USB-Kommunikation und auch das Datenblatt habe ich mir angeschaut. Gibt 
es für die Kommunikation irgend welche Beispiele oder vielleicht sogar 
Anleitungen/Tutorials? Google konnte mir in diesem Fall leider nicht 
weiter helfen.

Vielen Dank

[Simon B. (nomis)]

Samuel schrieb:
> ich bin gerade dabei ein Projekt mit einem ATmega32U2 Controller zu
> starten. Der Controller soll über die USB Schnittstelle vom PC aus
> gesteuert werden, Ausgänge setzen und Eingänge abfragen. Im Prinzip
> müssen nur Zahlen übertragen werden, das Programm auf dem Computer und
> im Controller erledigen den Rest
> Gibt
> es für die Kommunikation irgend welche Beispiele oder vielleicht sogar
> Anleitungen/Tutorials?

Du willst die LUFA-Library verwenden:

  http://www.fourwalledcubicle.com/LUFA.php

Viele Grüße,
        Simon

[Klaus (Gast)]

Was für ein Gerät soll das werden? HID, CDC?

[Samuel (Gast)]

HID, an LUFA stört mich ein bisschen die Lizens und das sehr viel 
"Kruscht" dabei ist den ich gar nicht brauchen werde.

[Samuel (Gast)]

Es scheint so wie als würde kein Weg an LUFA vorbei führen, zumindest 
kein "einfacher" ...

Vielleicht könnt ihr mir aber noch bei einem anderen Problem helfen. Ich 
programmieren den Controller über die USB-Schnittstelle und Flip, 
funktioniert auch super so lange kein Programm auf dem Controller ist, 
so bald ein Programm darauf ist muss man jedoch über den HWB Pin den 
Bootloader aktivieren, sonst läuft das Programm. Da ich auf meiner 
Platine Platz sparen möchte und den HWB Pin für andere Aufgaben 
vorgesehen habe suche ich nun eine Möglichkeit die Hardware Aktivierung 
zu umgehen. Bei anderen Bootloadern habe ich schon davon gelesen das 
diese nach einem Reset für eine gewisse Zeit (ca. 5sec) warten ob der 
Bootloader eine Verbingung bekommt und wenn nicht ein das Programm 
sprigen. Ist so etwas auch bei dem ATmega32U2 möglich?

[Simon B. (nomis)]

Samuel schrieb:
> Bei anderen Bootloadern habe ich schon davon gelesen das
> diese nach einem Reset für eine gewisse Zeit (ca. 5sec) warten ob der
> Bootloader eine Verbingung bekommt und wenn nicht ein das Programm
> sprigen. Ist so etwas auch bei dem ATmega32U2 möglich?

Du kannst zumindest bei Auftreten einer bestimmten Situation wieder aus 
deiner Applikation in den Bootloader springen - also z.B. wenn du über 
USB-HID einen bestimmten Report bekommst oder über USB-CDC ein 
bestimmter string reinkommt (oder irgendeine Tastenkombination gedrükct 
ist oder whatever).

Meine Funktion dafür sieht so aus:

static void
bootloader_start (void)
{
  /* jump into the boot loader */
  USB_Detach ();
  _delay_ms (200);
  USB_ShutDown ();
  _delay_ms (200);
  TIMSK0 = 0x00;
  TIMSK1 = 0x00;
  cli ();
  __asm__ ("jmp 0x7000;");
}

Viele Grüße,
         Simon

[Samuel (Gast)]

Daran hatte ich auch gedacht, danke für das Beispiel.
Hoffe ich halt mal das mein erstes Programm dann auch gleich 
funktioniert, sonst muss ich die Konatakte irgendwie provisorisch 
brücken :)

[Klaus (Gast)]

Wenns HID wird, dann bekommst Du hier eine kostenlose Anwendung für die 
PC-Seite: http://embedded24.net

[Samuel (Gast)]

Hat schon mal jemand versucht LUFA im Atmel Studio zu verwenden?
Ich habe jetzt schon zwei verschiedene Anleitungen versucht, ein mal die 
direkt von LUFA und noch eine ältere und beides mal habe ich fehler 
bekommen das Dateien fehlen oder das make File hat Probleme gemacht.

[xfr (Gast)]

Ich habe die Dateien, die kompiliert werden müssen, als Link in mein 
Projekt eingefügt. Also Add -> Existing Item und in dem Dialog statt 
"Add" auf "Add as Link" klicken. Sinnvollerweise nimmst Du dafür einen 
eigenen Unterordner. Du kannst auch die Verzeichnisstruktur der LUFA 
nachbilden, dann weist Du, woher welche stammt. Ist aber nicht unbedingt 
nötig.

In meinem Fall sind das alle c-Dateien aus:
LUFA/Drivers/USB/Class/Device
LUFA/Drivers/USB/Core
LUFA/Drivers/USB/Core/AVR8

Dann in den Projektoptionen unter C-Compiler -> Directories den Ordner 
"LUFA/Drivers/USB" (als relativer oder absoluter Pfad) hinzufügen. Das 
muss der Ordner sein, in dem die Dateien tatsächlich auf der Festplatte 
liegen, nicht der Unterordner in Deinem Projektverzeichnis, in dem nur 
die Links sind.

Die Dateien LUFAConfig.h und Descriptors.c/h aus dem Beispiel kopierst 
Du in Dein Projekt. Dann sollte es ohne externes Makefile kompilieren.

[Samuel (Gast)]

Damit bin ich eindeutig schon mal etwas weiter gekommen, zur Zeit habe 
ich "nur" noch 4 Errors und zwei Warnings. Hier mal die Errors:

Error  1  conflicting types for 'CALLBACK_USB_GetDescriptor'  ...\USB-IO 
Programme\USB-IO (LUFA)\USB-IO (LUFA)\Descriptors.h  73  12  USB-IO 
(LUFA)

Error  3  'FIXED_CONTROL_ENDPOINT_SIZE' undeclared here (not in a 
function)  ...\USB-IO Programme\USB-IO (LUFA)\USB-IO 
(LUFA)\Descriptors.c  80  28  USB-IO (LUFA)

Error  4  'FIXED_NUM_CONFIGURATIONS' undeclared here (not in a function) 
...\USB-IO Programme\USB-IO (LUFA)\USB-IO (LUFA)\Descriptors.c  90  28 
USB-IO (LUFA)

Error  5  conflicting types for 'CALLBACK_USB_GetDescriptor'  ...\USB-IO 
Programme\USB-IO (LUFA)\USB-IO (LUFA)\Descriptors.c  202  10  USB-IO 
(LUFA)

[xfr (Gast)]

Ich habe bei mir noch folgendes gegenüber den Dateien aus dem Beispiel 
geändert:

In LUFAConfig.h einfügen:

#define F_USB F_CPU

In Descriptors.h statt:

#include <LUFA/Drivers/USB/USB.h>

habe ich:

#include <USB.h>

Vielleicht fehlt Dir das ja. Ansonsten poste mal den Code ...

[Samuel (Gast)]

Die Änderungen habe ich auch schon gemacht.
Die Frequenz habe ich jedoch über die Compiler Symbole definiert, sollte 
aber keinen Unterschied machen.

http://www.fourwalledcubicle.com/files/LUFA/Doc/120730/html/AS5_AS6_Import_Step5_1.png

Ich verwende die Version 120730, hast du da vielleicht eine andere?

Ich habe mal beide Dateien angehängt, der Konflikt wird vermutlich 
dadruch hervor gerufen das in der Descripors.c und in der Descripors.h 
zwei mal "CALLBACK_USB_GetDescriptor" definiert wird.

[xfr (Gast)]

Ah, glaube ich weiß, was noch fehlt. Definiere in den Compilersymbolen 
noch USE_LUFA_CONFIG_HEADER, also -DUSE_LUFA_CONFIG_HEADER.

[Samuel (Gast)]

Jetzt werden die Fehler noch misteriöser, ich habe einfach mal ein Bild 
gemacht sonst wird das mir wohl keiner glauben ^^

[xfr (Gast)]

Der Ordner, in dem LUFAConfig.h liegt, ist wohl in den 
Projekteinstellungen unter C-Compiler -> Directories nicht eingetragen.

[Samuel (Gast)]

Genau das war es, vielen Dank :)
Jetzt "nur" noch die Dateien finden in denen alles konfiguriert wird, 
für meinen Controller und Board anpassen, herausfinden wie ich LUFA 
verwede, den Takt von meinem Controller über die Software auf den 
externen Quarz legen und den Frequenzteiler deaktivieren und dann kann 
ich endlich anfangen mit programmieren :)

[xfr (Gast)]

Da muss jetzt eigentlich nichts mehr konfiguriert werden, der 
Beispielcode sollte direkt laufen (also die USB-Aufrufe, ohne die 
zusätzlichen I/O-Libs). Viel Erfolg. :)

[Samuel (Gast)]

Die HIDClassDevice.c ist für mein "Haumptprogramm" zuständig wenn ich 
das richtig sehe oder? Ich kann meinen Controller leider nur über Flip 
programmieren und damit kann man ja keine Fuses setzen, also muss ich 
den externen Quarz über die Software aktivieren und das möglichst bevor 
das Programm startet :)

[xfr (Gast)]

Das Programm schreibst Du immer noch selber. Erst wenn Du USB_Init() 
aufrufst, macht die Library etwas. Nimm am besten das Beispielprogramm 
GenericHID.c als Ausgangspunkt und pass es an Deine Bedürfnisse an.

[Samuel (Gast)]

Ich danchte eigentlich es gibt auch eine Möglichkeit den Frequenzteiler 
(CKDIV8) über das Programm zu deaktivieren (temporär), weil der ja 
standardmäßig aktiviert ist, kann aber gerade irgendwie nichts finden. 
Weiß zufällig jemand etwas davon? Über den Bootloader kommt man ja so 
weit ich weiß nicht an die fuses ran ...

[Samuel (Gast)]

Habs doch noch raus gefunden, wen's interessiert:

  //Deaktiviert den Frequenzteiler
  CLKPR = (1 << CLKPCE); //Aktivierung für die Änderung am Frequenzteiler
  CLKPR = 0; //Frequenzteiler auf 1 setzen (keine Teilung)

[Samuel (Gast)]

Ich habe jetzt fast alles 1:1 aus dem Beispielprojekt übernommen, aber 
mein Pc erkennt immer noch kein USB Gerät -.-
Wär echt nett wenn sich jemand mal mein Programm anschauen könnte.

[Samuel (Gast)]

Ich habe jetzt das Demo Beispiel mit WinAVR compiliert und auf den 
Controller übertragen und da passiert genauso wenig. Das komische ist ja 
das der Bootloader funktioniert, also kann es an der Hardware schon mal 
nicht liegen oder? Gibt es irgend welche Fuses die man vorher noch 
umstellen muss? Oder muss ich in LUFA noch irgend etwas anpassen außer 
den Controller und die Frequenz?

[Peter (Gast)]

>#define F_USB F_CPU
Warum das denn? Das ist doch viel zu schnell!

mach lieber

#define F_USB F_CPU / 2

oder

#define F_USB F_CPU /4

[Samuel (Gast)]

Ich denke das passt schon, wenn man sich den Programmcode dazu anschaut:

#elif (F_USB == 16000000)
      #if (defined(__AVR_AT90USB82__) || defined(__AVR_AT90USB162__) || \
           defined(__AVR_ATmega8U2__) || defined(__AVR_ATmega16U2__) || \
           defined(__AVR_ATmega32U2__))
        #define USB_PLL_PSC                (1 << PLLP0)

[Potter (Gast)]

>Warum das denn? Das ist doch viel zu schnell!
Was ich damit sagen wollte: wenn Du an irgendeiner Schraube drehst, ohne 
zu wissen was Du machst, dann hast Du vermutlich noch einige weitere 
Schrauben vor Dir - das kann dauern.

>also kann es an der Hardware schon mal nicht liegen oder?
Das scheint so, wenn der Bootloader funktioniert.

Ich kenne dieses LUFA nicht, wenn die aber ihre Software für 
verschiedene Controller vorgesehen haben, dann sollte es auch eine 
Anleitung geben, was man wo umzustellen hat.

Ansonstens wär es halt gut zu wissen, was auf dem USB abgeht. Kommen 
Pegel oder nicht? Wo hängts bei der Enumeration?

[Samuel (Gast)]

Ja es gibt eine Art Anleitung in der steht was man verändern muss.
Ist eigentlich so weit ich weiß nur fie Frequenz, das Board, der 
Controller und ggf. die Architektur. Habe ich auch alles geändert so wie 
es sein sollte. An der USB-Frequenz muss man normal nichts ändern, bei 
den meisten Controllern ist F_CPU = F_USB.

Gibt es eine Software mit der man die Pegel "messen" kann oder 
wenigstens ein Programm das die "Befehle" anzeigt die ankommen? Ich habe 
bisher leider nur Programme gefunden die nur Devices auslesen können, 
also ein Gerät nach der Enumeration. Ein Oszilloskope habe ich leider 
nicht -.-

[Pit (Gast)]

Vor der Enumeration ist das meist Hardware, die man da verwendet.

Z.B.:
http://www.basic.io/index.php/category-analyzers/alogic-analyzer-detail
http://www.totalphase.com/products/beagle_usb12/

[Samuel (Gast)]

Habe eigentlich nicht vor noch extra Geld für irgend welche Diagnose 
Geräte auszugeben ...