mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik uC an USB nicht erkannt ( als wär nichts da )


Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe ein AT90USB647, der soweit Problemlos funktioniert (USB - 
Bootloader, I/O, Timer, etc.).

Nun habe ich das Problem, dass ich gerne eine USB Verbindung zum PC 
herstellen würde und dazu die Firmware von Herrn Salewski raufgespielt 
habe, nur tut sich bei mir am USB leider nichts, kein Piep beim 
einstecken, nichts im Gerätemanager oder anderen USB Browsern.

Hab die Firmware mehrmals (verändert) probiert, unter anderem :
- unverändert
- mit angepasstem Makefile ( MCU, etc.)
- mit angepassten Configs, Interfaces, EP´s, etc.

leider führte bisher kein Weg zum Ziel.
Das Ziel vorläufig ist nur, dass er das Gerät am USB erkennt, keine 
Daten senden etc. ( Nächster Schritt =) )

Board und USB müssten funktionieren, da der USB Bootloader auch 
problemlos funktioniert.

Hat jemand ein Tipp was ich ändern könnte um eine Verbindung 
herzustellen bzw. was ich falsch gemacht habe ?

Danke.
Matthias

PS.: Der Compiler bringt keine Fehler oder so =)

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn sich überhaupt nichts tut, würde ich mal darauf tippen, dass du den 
Widerstand von D+/D- nach Vcc vergessen hast. Sobald man den einbaut 
muss sich irgendwas tun, egal ob da noch irgendwelche Logik dranhängt 
oder nicht.

Autor: günny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei den PICs ist das so, dass - sobald man die USB-Interface-Hardware im 
PIC aktiviert, der Host direkt den Enumerierungsprozess startet (und 
ziemlich schnell eine Fehlermeldung sendet, wenn man nicht rechtzeitig 
richtig antwortet). Bei den PICs gibt es auch eine Option, dass für die 
Datenleitungen interne oder externe Pullups verwendet werden können... 
kein Plan ob der AT90USB647 diesbezüglich auch so komfortabel ist ;-)
...also wie  Philipp Burch schon schrieb, sobald Pullups an den 
Datenleitungen hängen gehts ab... Also würde ich Dir vorschlagen dieser 
Sache mal nachzugehen...

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ja stimmt ich habe keine Pullup Widerstände in D+ bzw. D-, ich hab die 
USB Buchse so angeschlossen, wie es im Datenblatt für 5V Self Powered 
Geräte gestanden ist ( mit 22R Serien Wid. ).

Hab allerdings vorher im Forum auch gerade was bzgl. eines Pullup 
gelesen.

Weisst jem. da genaueres dazu?
Brauche ich den Pullup, ist der nicht intern?
USB-Bootloader funktioniert ja auch(?)
Wenn ich ihn brauche, auf welche Leitung muss ich ihne legen und wie 
groß sollte der ca. sein?

danke für die Hilfe
Matthias

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also einfach D+ und D- über Wid. auf VCC.

wie groß sollte der Wid. sein? ( 10k Pullup )?

sorry, hab vorher deine Antwort grad nicht mehr gesehen =)

danke

Autor: Marco S. (masterof)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Widerstand muss 1K5 groß sein.

Autor: Düsentrieb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>dazu die Firmware von Herrn Salewski raufgespielt

Stimmt die Quarzfrequenz?

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Autor: Philipp Burch (philipp_burch) Datum: 24.03.2008 17:57

>Wenn sich überhaupt nichts tut, würde ich mal darauf tippen, dass du den
>Widerstand von D+/D- nach Vcc vergessen hast.

Der AT90USB benötigt nicht diesen externen Widerstand nach Vcc.

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, danke für die hilfe und den link.

Quarz F stimmt ;)

also wenn ich Lowspeed betreibe, dann 1k5 von D- auf 3V3 und bei 
Fullspeed 1k5 von D+ auf 3V3.

Zusätzlich an beiden Leitungen 15k auf Masse.

Was mach ich nun wenn ich keine 3V3 habe?
Habe 5V Vcc brauch ich da jetzt extra eine Spgregler oder kann ich denn 
Widerstand zw. D+/- und VBUS schalten? ( Betrieb Selfpowered )

Danke soweit.

mfg
Matthias

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>ok, danke für die hilfe und den link.

>Quarz F stimmt ;)

>also wenn ich Lowspeed betreibe, dann 1k5 von D- auf 3V3 und bei
>Fullspeed 1k5 von D+ auf 3V3.

>Zusätzlich an beiden Leitungen 15k auf Masse.

>Was mach ich nun wenn ich keine 3V3 habe?
>Habe 5V Vcc brauch ich da jetzt extra eine Spgregler oder kann ich denn
>Widerstand zw. D+/- und VBUS schalten? ( Betrieb Selfpowered )

>Danke soweit.

???

Nun mal langsam.

Wenn der USB-Bootloader funktioniert, dann ist die Hardware ok.
Und dann sollten wir meine Firmware auch zum laufen bekommen.

Weiters später.

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, dann werd ich da mal nichts überstürzen =)

Also im Sinn von stimmt die Quarzfrequenz meinte ich ob ich Fuses au 
extern habe und VT 0 und so.

Habe 16MHz Quarz, extern, ohne VT.

Oder hast du gemeint die freq. im Makefile ?

Hatte es zuerst im Makefile nicht drinn, dann wusste ich nicht an welche 
Variable ich es "anhängen" sollte und dann hab ichs einfach mal so 
hinten ans cflags rangehängt ( -DF_CPU=16000000UL ).

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias T.

So, ich bin wieder da.

USB-Bootloader funktioniert also?
Du kannst per USB von Deinem PC ein Testprogramm (LED blinken oder so) 
auf den uC übertragen und ablaufen lassen?

Dann ist die (USB) Hardware OK.

Hast Du einen 16 MHz Quarz bzw. Quarz-Ozillator?

Welches Betriebssystem läuft auf Deinem PC?

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und nochmal die Frage:

Welches Betriebssystem läuft auf Deinem PC?

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

USB Bootloader funktioniert mit FLIP, scho mehrfach programmiert.

16 MHz Quarz ( nicht Oszillator ).

WinXP SP2.

danke für die hilfe

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut.

16 MHz hatte ich für meine Platinen auch verwendet, soweit braucht man 
nichts verändern.

Ich hatte allerdings den AT90USB1287, im Makefile solltest Du die Zeile

MCU = at90usb1287

durch

MCU = at90usb647

ersetzen.

Ich persönlich habe meine Firmware bisher nur unter Linux eingesetzt.
Aber es sollte im Prinzip schon unter Windows funktionieren.

Hast Du die Möglichkeit mal mit Linux zu Testen?

Bei Windows kann man sich nie so recht sicher sein was es macht. Evtl. 
erkennt es das Gerät, versucht es anzusprechen -- das schlägt fehl und 
dann meldet Windows das Gerät sofort ab? Wäre eine Vermutung, ich habe 
mit Windows nichts an Hut. Soweit ich mich erinnere hatten mir einige 
Leute geschrieben, dass Sie meine Firmware auch unter Windows einsetzen, 
aber ich weiß nicht was sie genau verändert haben. Ein Test unter Linux 
wäre daher gut.

Es könnte natürlich auch sein, dass sich der AT90USB647 doch anderes 
verhält als der AT90USB1287. Glaube ich aber nicht.

Welche Compiler-Version setzt Du ein?

Hast Du an den Fuses irgend etwas umgestellt?

Hat Dein Board eine Serielle Schnittstelle für Debugging?

Wie ist Dein Kenntnisstand bezüglich uC und USB?

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich habe mal Windows XP gebootet, mich als normaler Nutzer 
angemeldet  und eine meiner Platinen angestöpselt:

Wie erwartet öffnet sich ein Fenster "Neue Hardware gefunden..." und im 
Gerätemanager wird ein unbekanntes USB-Gerät mit VID_03EB (Atmel) 
angezeigt.

Der VID-Code 03EB stammt von meiner Firmware (Atmel Code), d.h. Windows 
kann mit dem Gerät kommunizieren.

Nun ist es aber so: Ich nutze Windows praktisch nie, so dass auf meinem 
Windows XP praktisch keinerlei zusätzliche Treiber installiert sind.

Bei Dir wird es anders aussehen, Du hast vermutlich AVR-Studio und FLIP 
installiert. Nun wäre meine Vermutung, dass bei Dir Windows den VID_03EB 
liest und dann das Gerät mit irgend einem Treiber ansprechen will. Das 
geht nicht und Windows meldet das Gerät ab. Von all dem bekommst Du 
evtl. nichts mit.

Ich habe die Atmel VID einfach verwendet, da es ja ein Atmel uC ist.
Im Prinzip hätte ich mir eine VID kaufen können, aber da ich keine 
Platinen mit dem AT90USB kommerziell vertreibe werde ich keine 2000 
Dollar dafür ausgeben. Und mit Linux gibt es ja eh keine Probleme.

Wenn dies die Ursache für das Problem ist, könntest Du einfach mal eine 
andere VID ausprobieren (Datei com_def.h). Allerdings: Prinzipiell wäre 
es möglich, dass Windows Deine Platine dann für ein anderes Gerät hält, 
und evtl. abstürzt oder andere schlimme Dinge macht.

Wenn Du wenig USB Kenntnisse hast, eh nur Windows nutzen willst und es 
Dir auch egal ist, ob die Software frei (GPL) ist oder nicht, solltest 
Du vielleicht doch lieber Atmels USB-Software nutzen.

Gruß

Stefan Salewski

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Danke für die Antworten.

Also die MCU im Makefile hatte ich ersetzt.
Hab mom. leider nicht die Möglichkeit unter Linux zu testen ( bei mir ).
Habe mir die aktuellste Version vom AVR Studio und WinAVR 
heruntergeladen ( vor 2 Wochen ).
Momentan hab ich leider nicht die Möglichkeit zum Debuggen, hab das aber 
auf der nächsten Platine schon vorgesehen ( MAX232 ).

Fuses hab ich glaub nur den Clockvorteiler rausgenommen.

Hab natürlich schon Treiber installiert, aber es müsste ja nach 
Anstecken des Geräts mindestens ein "Tüdüt" kommen.

Werd das mit der VID morgen mal probieren und stecks mal zum schauen an 
einen älteren Computer an, der nur Grundprogramme installiert hat.
Ich probiers morgen bei einem Kolleg auch mal unter LINUX, brauch ich da 
bestimmten Treiber oder so ?
Die LibUsb oder so brauch ich dann ja nur zum Datenaustausch, oder, bin 
mit Linux leider nicht so vertraut.

Würde gerne eine freie Firmware wie deine verwenden, da es mich auch 
interessiert was im Hintergrund abläuft.

danke
gruß
Matthias

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Würde gerne eine freie Firmware wie deine verwenden, da es mich auch
>interessiert was im Hintergrund abläuft.

Gut, dann sollten wir das auch hinbekommen. Notfalls können wir ja 
unsere Platinen per Post tauschen.

>Fuses hab ich glaub nur den Clockvorteiler rausgenommen.

Das könnte evtl. das Problem sein. Meine Firmware funktioniert mit den 
AT90USB so wie sie ausgeliefert werden. Der AT90USB sollte intern mit 16 
MHz laufen. Es wäre schon gut zu wissen das er das tut. Man kann ihn 
irgendwie so programmieren, dass er den Takt ...

Ah, da fällt mir gerade was ein: Das alte Datenblatt des AT90USB1287 
hatte ja eine Reihe von Fehlern. Drin stand auch, dass der uC 
vorgabemäßig auf internen Takt eingestellt ist. Das ist natürlich 
offensichtlich Unfug (sonst würde der USB-Bootloader nicht 
funktionieren), aber dass hat dich evtl. dazu bewogen an den Fuses zu 
drehen...

Seit einigen Wochen ist aber ein neues Datenblatt verfügbar.

Wie gesagt, den Takt sollte man überprüfen. Man kann den uC so 
programmieren, dass er den Takt an einem Pin ausgibt, dann kann man ihn 
mit einem Frequenzzähler oder Oszilloskop messen.

>Hab natürlich schon Treiber installiert, aber es müsste ja nach
>Anstecken des Geräts mindestens ein "Tüdüt" kommen.

Weiß ich nicht. Wenn Windows meint das Gerät sei defekt?

>Ich probiers morgen bei einem Kolleg auch mal unter LINUX, brauch ich da
>bestimmten Treiber oder so ?

Treiber brauchst Du nicht (der PC/Linux sollte aber USB unterstützen)
Wenn Du die Platine eingestöpselt hast (und natürlich auch mit Strom 
versorgt, wenn self-powered), gib mal in der Shell das Kommando "dmesg" 
ein. Ganz unten als neuer Eintrag sollte dann zu lesen sein etwas wie:

usb 1-8.1: new full speed USB device using ehci_hcd and address 6
usb 1-8.1: configuration #1 chosen from 1 choice

Mehr Informationen bekommst Du mit (musst aber evtl. als 
root/Administrator angemeldet sein):

lsusb

oder

cat /proc/bus/usb/devices

liefert etwas wie

T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  6 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=ff(vend.) Sub=ff Prot=ff MxPS= 8 #Cfgs=  1
P:  Vendor=03eb ProdID=0001 Rev= 0.01
S:  Manufacturer=SALEWSKI
S:  Product=AT90USB
S:  SerialNumber=001
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS=   8 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS=   8 Ivl=0ms


>Die LibUsb oder so brauch ich dann ja nur zum Datenaustausch

Ja. Unter Linux ist LibUSB meist eh installiert, unter Windows wird man 
LibUSB wohl separat installieren müssen. Ich weiß leider nicht, ob 
LibUSB unter Vista funktioniert -- unter XP schon.

Gruß

Stefan Salewski

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das könnte evtl. das Problem sein. Meine Firmware funktioniert mit den
> AT90USB so wie sie ausgeliefert werden. Der AT90USB sollte intern mit 16
> MHz laufen. Es wäre schon gut zu wissen das er das tut. Man kann ihn
> irgendwie so programmieren, dass er den Takt ...

intern mit RC Osz. oder halt die Freq. im Baustein ?
Hab ext. Osz. 16 MHz ohne Prescaler ( CKDIV8 deaktiviert ).
Habs mal einen Pin Toggeln lassen - der "blinkt" mit 1Mhz also Toggelt 
mit 2 MHz, könnte ja passen, 8 Befehle für Schleife Port setzen etc., 
oder ?


> Weiß ich nicht. Wenn Windows meint das Gerät sei defekt?

Ok, das Teste ich morgen mit der anderen VID


danke für die Hilfreichen Tipps und Infos
werde morgen wieder von mir hören lassen.

Grub
Matthias Trieb

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir fiel gerade noch etwas ein, evtl. habe ich die Lösung:

Dein AT90USB647 hat ja nur 4kByte RAM, mein AT90USB1287 8kByte.

Ich habe ja einen Haufen Debugging Code mit Textausgaben drin, die RAM 
belegen. Außerdem einen Pufferspeicher für die Datenerfassung.

Mit 4 kByte RAM muss es eigentlich Probleme geben.

Evtl. gibt avr-gcc keine Warnung wenn der Speicher überläuft.

Probier mal den Debugging-Code abzuschalten: Ersetze in defines.h

#define DEBUG // send debug messages over serial port
//#undef DEBUG

//#define NOUART // do not use usart_drv.c at all
#undef NOUART

durch das Gegenteil

//#define DEBUG // send debug messages over serial port
#undef DEBUG

#define NOUART // do not use usart_drv.c at all
//#undef NOUART


und in ringbuffer.h

#define BufElements 1024

durch

#define BufElements 256

Weiteres morgen.

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Morgen,

habs kurz vorm Weggehen nochmal probiert mit der Debug aus und so => Hex 
File 2/3 kleiner.

Sonst hat sich aber leider nichts getan, auch der kleinere Buffer nicht.

Habs dann noch schnell mit der VID probiert => keine Reaktion.

Werde in diesem Fall nachher noch den LINUX test durchführen.

danke
Matthias

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Sonst hat sich aber leider nichts getan

Schade.

Der Debugging-Code muss in jedem Fall für den AT90USB647 abgeschaltet 
werden, sonnst reicht der RAM nicht aus.

Als ich im Herbst 2006 die Firmware geschrieben habe war nur der 
AT90USB1287 verfügbar und ich habe nicht dran gedacht, dass der 
AT90USB647 nur halb so viel RAM hat. Das Problem sind die Text-Strings, 
die ich normal definiert habe, wie es in C üblich ist. Dann belegen sie 
aber RAM. Man kann sie irdend wie anders anlegen -- das müsste ich 
vielleicht mal umschreiben.

Wenn das Gerät mit meiner Firmware unter Linux auch nicht erkannt wird 
gibt es zwei mögliche Ursachen:

- Dein Gerät ist self-powered (meins Bus-powered)
- Du hast den AT90USB647 (ich den AT901287)

Ich wüsste zwar nicht, dass das einen Unterschied macht, aber wäre ja 
möglich.

Naja, warten wir mal ab was Linux sagt (bei abgeschalteten 
Debugging-Code)

Gruß

Stefan Salewski

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so, habs grad getestet.

Leider hat sich die Platine auch unter Linux nicht gemeldet.

Hab für die nächste Platine ein Umschalter zw. Self und Bus Powered 
vorgesehen.

Soll ich mir dann eher ein at90usb128 zulegen, kann es echt an den nur 
4KB Ram liegen, bei amgeschaltetem Debugging.

Kann man den RAM über den Programmer auslesen? ( zum größe feststellen ) 
oder so.

danke
Matthias

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias T. (maette) schrieb am 25.03.2008 um 12:53 Uhr:

>Leider hat sich die Platine auch unter Linux nicht gemeldet.

Ich habe es schon befürchtet.

Meine Vermutung ist, dass es am self-powered liegt.
Da ist das Timing wohl etwas anders. Ich vermute, dass der ganze Kram 
zur Aktivierung der USB-Einheit bei Dir gar nicht erst ausgeführt wird.
Das Datenblatt, zumindest das Alte, erklärt die Aktivierung nicht sehr 
genau. Daher war ich damals froh, dass ich es hin bekommen hatte, und 
habe nicht weiter darüber nachgedacht, dass es bei self-powered anders 
sein könnte. Mir haben zwar einige Leute geschrieben, dass meine 
Firmware bei ihnen funktioniert, aber vermutlich war das stets 
Bus-Powered Betrieb.

Ich hatte schon dran gedacht, eine meiner Platinen auf self-powered 
umzubauen, aber leider befinden sich die Versorgungsleitungen unter dem 
Prozessor. Und ich habe derzeit auch nur bestückte Platinen.

>Hab für die nächste Platine ein Umschalter zw. Self und Bus Powered
>vorgesehen. Soll ich mir dann eher ein at90usb128 zulegen

Bus-Powered mit AT90USB1287 sollte ich jedem Fall funktionieren, 
zumindest mit Linux. Wenn Du eh noch eine Platine machen willst, würde 
ich sie in der Tat umschaltbar self/bus-powered machen und mit einem 
AT90USB1287 bestücken, möglichst auch mit MAX232 für serielle 
Schnittstelle. Als Alternative könnte ich Dir leihweise eine meiner 
Platinen (entsprechend meiner Internetseite) schicken. Vielleicht kannst 
Du Deine Platine ja auch einfach umbauen -- externe Spannungsversorgung 
abklemmen und durch einen Draht von VBUS ersetzen?

Ich werde mich um die Probleme mit self-powered bzw. AT90USB647 kümmern, 
aber das kann etwas dauern, evtl. auch etwas länger.

>Kann man den RAM über den Programmer auslesen? ( zum größe feststellen )
>oder so.

Unter Linux/avr-gcc gibt es ein Kommando "avr-size file.hex" oder 
ähnlich, bei WinAVR weiss ich nicht. Aber wenn der Debugging-Code 
deaktiviert ist hast Du mit der RAM-Größe ganz sicher keine Probleme. Es 
könnte natürlich sein, dass sich 647 und 1287 noch in anderen Punkten 
unterscheiden, das glaube ich aber nicht.

Gruß

Stefan Salewski

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, dann werde ich mal mit einem Draht brücken ( von VBUS auf VCC ), 
hatte eigentl. vor den AT90USB647 von der alten Platine auszulöten, dass 
ich nicht einen neuen kaufen muss, scheint aber erforderlich zu sein, 
oder ?

Was mache ich wenns gebrückt auch nicht geht ?

gruß
Matthias T.

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so gerade schnell getestet ... ( VBUS auf VCC )

Es funktioniert !! =)

Windows meldet ein Unbekanntes USB - Gerät :D

Wie verfahre ich nun weiter, wenn ich die USB mit der USBLibrary.dll per 
C# ansprechen möchte ? (http://www.codeproject.com/KB/cs/USB_HID.aspx)

USB hat sich beklagt, dass das USB Device zu viel Strom verbraucht und 
deshalb abgehängt werden sollte. Jetzt erkennt ers nicht mehr, warsch. 
mit anderer VID wieder.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias T. (maette) schrieb  am 25.03.2008 um 14:14 Uhr:

>so gerade schnell getestet ... ( VBUS auf VCC )

>Es funktioniert !! =)

Gut!

Übrigens, mir fiel gerade ein: Self- oder Bus-powered sollte ja nur 
einen Unterschied machen, wenn das Gerät neu eingesteckt wird. Wenn es 
schon eingesteckt ist und man dann per Reset-Taster einen Reset macht, 
sollte es eigentlich auch Self-powered funktionieren

Aber egal, nun wissen wir, dass sich ein AT90USB self-powered beim 
Aktivieren des USB-Teils anders verhält. Ich werde das untersuchen.


>USB hat sich beklagt, dass das USB Device zu viel Strom verbraucht und
>deshalb abgehängt werden sollte. Jetzt erkennt ers nicht mehr, warsch.
>mit anderer VID wieder.

Der AT90USB selbst sollte doch nur einige 10 mA verbrauchen? USB liefert 
zunächst maximal 100, später wenn sich das Gerät korrekt angemeldet hat 
bis zu 500 mA. Naja, evtl. baust Du wieder auf self-powered zurück und 
löst dann einen Reset per Taster aus. Achtung: beim Reset muss Pin PE2 
(HWB) auf Vcc liegen (über einen Widerstand), sonst springt er in den 
Bootloader, siehe meine HTLM-Seite.

Du müsstest im Gerätemanager oder so eigentlich alles zurücksetzen 
können, so dass er das Gerät wieder erkennt. (Einige Leute hängen an den 
USB-Port sogar Kaffeewärmer oder Leuchten ohne korrekte Anmeldung -- bei 
einigen PCs geht das, bei einigen nicht.)

>Wie verfahre ich nun weiter, wenn ich die USB mit der USBLibrary.dll per
>C# ansprechen möchte ? (http://www.codeproject.com/KB/cs/USB_HID.aspx)

Da kann ich Dir nicht helfen. Mit LibUSB sollte es auch unter Windows 
recht einfach sein, da kannst Du dich an den Funktionsaufrufen in meinem 
Beispielprogramm orientieren. HID wird aber von meiner Firmware (noch) 
nicht unterstützt.

Gruß

Stefan Salewski

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Müssten/sollten nicht die Einträge im InterfaceDescriptor für 
bInterfaceClass auf vendor-specific voreingestellt werden (oder gleich 
für's ganze Gerät)?
"A value of zero is reserved for future standardization."
"If this field is set to FFH, the interface class is vendor-specific.
All other values are reserved for assignment by the USB-IF"

> Wie verfahre ich nun weiter, wenn ich die USB mit der USBLibrary.dll per
> C# ansprechen möchte ? (http://www.codeproject.com/KB/cs/USB_HID.aspx)

Wenn LibUSB verwendet wird: Beitrag "C# .lib (libusb) Libary einbinden"

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Müssten/sollten nicht die Einträge im InterfaceDescriptor für
> bInterfaceClass auf vendor-specific voreingestellt werden (oder gleich
> für's ganze Gerät)?
> "A value of zero is reserved for future standardization."
> "If this field is set to FFH, the interface class is vendor-specific.
> All other values are reserved for assignment by the USB-IF"

wie meinst du das bzw. um was zu erreichen, allgemein oder als hid?

>> Wie verfahre ich nun weiter, wenn ich die USB mit der USBLibrary.dll per
>> C# ansprechen möchte ? (http://www.codeproject.com/KB/cs/USB_HID.aspx)
>
> Wenn LibUSB verwendet wird: Beitrag "C# .lib (libusb) Libary einbinden"

Danke für den Link, sieht sehr gut aus.


>Du müsstest im Gerätemanager oder so eigentlich alles zurücksetzen
>können, so dass er das Gerät wieder erkennt.

Weisst du zufällig wie das geht, brings irgendwie net her, hab self und 
bus powered nochmal getestet und mit anderer VID, nicht funktioniert.

Bootloader mit der Atmel VID funktioniert einwandfrei...

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Autor: Arc Net (arc) Datum: 25.03.2008 16:29

>Müssten/sollten nicht die Einträge im InterfaceDescriptor für
>bInterfaceClass auf vendor-specific voreingestellt werden (oder gleich
>für's ganze Gerät)?

Ich habe in meinem Code:

#define UsbNoInterfaceClass  0xFF
#define UsbNoInterfaceSubClass  0xFF
#define UsbNoInterfaceProtokoll  0xFF
#define UsbNoDeviceClass  0xFF
#define UsbNoDeviceSubClass  0xFF

d->bDeviceClass = UsbNoDeviceClass;
d->bDeviceSubClass = UsbNoDeviceSubClass;
i->bInterfaceClass = UsbNoInterfaceClass;
i->bInterfaceSubClass = UsbNoInterfaceSubClass;

Und
cat /proc/bus/usb/devices
liefert
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)

Soweit sollte das schon ok sein.
Aber Windows wird wohl versuchen, jedes neue USB-Gerät als HID 
anzusprechen oder einen Treiber dafür zu laden.

Aber wie wir schon herausgefunden haben ist das nicht das eigentliche 
Problem des Threadstarters. Derzeit wird der USB-Teil des AT90USB nicht 
korrekt gestartet, wenn zunächst der uC mit Strom versorgt wird, und 
erst dann der USB-Stecker eingesteckt wird (self-powered). Wie ich schon 
schrieb, ich werde das untersuchen.

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab auch scho alle möglichen Varianten Durchprobiert, mit Self/Bus 
Powered, Strom zuerst, dann anstecken, Reset´s und so.

Hab grad am anderen Laptop angesteckt ( auch WinxP ) und da hat sich 
auch nichts getan, also liegt nicht daran, dass ich bei mir im 
Gerätemanager verstellt habe, sondern dass wieder am Programm was nicht 
stimmt.

Seits funktioniert hat, hab ich aber eigentl. nichts neus runtergeladen.

Wo könnte das Problem liegen?

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Soweit sollte das schon ok sein.
Hatte nur diesen Teil http://www.ssalewski.de/USB-Sources/usb_spec.c 
überflogen...

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias T. (maette) schrieb am 25.03.2008 um 17:37 Uhr:

>Hab auch scho alle möglichen Varianten Durchprobiert, mit Self/Bus
>Powered, Strom zuerst, dann anstecken, Reset´s und so.

>Hab grad am anderen Laptop angesteckt ( auch WinxP ) und da hat sich
>auch nichts getan, also liegt nicht daran, dass ich bei mir im
>Gerätemanager verstellt habe, sondern dass wieder am Programm was nicht
>stimmt.

>Seits funktioniert hat, hab ich aber eigentl. nichts neus runtergeladen.

>Wo könnte das Problem liegen?

Also das verstehe ich jetzt nicht mehr:
Du hattest geschrieben, dass es Bus-Powered funktioniert hatte, bloß das 
Windows über zu hohe Stromentnahme gemeckert hatte.

Wenn Du natürlich noch andere große Stromverbraucher auf der Platine 
hast ist es klar das Windows meckert -- hättest evtl abklemmen sollen.

Aber die Firmware im uC ändert sich ja nicht von allein -- wenn es 
einmal funktioniert hat sollte es auch wieder funktionieren. Wie man ein 
deaktiviertes USB-Gerät unter Windows wieder aktiviert weiß ich nicht, 
da musst Du die Windows-Leute fragen. Das Problem gibt es aber öfter mit 
USB-Festplatten an Notebooks.

Ich werde versuchen eine meiner Platinen auf self-powered umzubauen und 
dann berichten.

Zum Schluss noch ein wichtiger Hinweis:
Kürzlich habe ich von einem anderen USB-Projekt für AT90USB erfahren:

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

Ich habe mir das noch nicht näher angesehen, macht aber einen guten 
Eindruck. Das unterstützt wohl auch HID und ist damit für Dich und 
andere Windows-Fans vielleicht besser geeignet.

Gruß

Stefan salewski

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Salewski wrote:
> Aber die Firmware im uC ändert sich ja nicht von allein -- wenn es
> einmal funktioniert hat sollte es auch wieder funktionieren. Wie man ein
> deaktiviertes USB-Gerät unter Windows wieder aktiviert weiß ich nicht,
> da musst Du die Windows-Leute fragen. Das Problem gibt es aber öfter mit
> USB-Festplatten an Notebooks.

Geräte-Manager -> Eintrag auswählen -> "Deinstallieren" (Oder einfach 
auf Delete hauen)
Beim nächsten Einstecken sollte es dann wieder korrekt enumieriert und 
installiert werden.

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Stromverbrauch war glaub nur kurz, hab nicht viel mehr dran als denn 
uC, braucht sicher nicht mehr als 100 mA.

Was für einen Eintrag soll ich denn auswählen? Die Platine wird mir ja 
nicht angezeigt? Ist ja sonst nur noch Root Hub da, aber es funktioniert 
ja ma anderen PC auch nicht ???

Das Projekt MyUSB hab ich mir auch schon ein wenig angeschaut gehabt, 
aber nachdem ich die DLL nicht in C# einbinden konnte habs ichs 
gelassen, hoff eigentl. immer noch, dass das hier funktioniert. HID oder 
nicht HID ist kein Problem.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Autor: Matthias T. (maette) Datum: 25.03.2008 18:21

>Der Stromverbrauch war glaub nur kurz, hab nicht viel mehr dran als denn
>uC, braucht sicher nicht mehr als 100 mA.

Hast Du evtl. einen dicken Kondensator auf der Platine?
Für den USB-Bus sind maximal 10uF erlaubt, sonst ist der Strom beim 
Einstecken zu groß.

>Was für einen Eintrag soll ich denn auswählen? Die Platine wird mir ja
>nicht angezeigt? Ist ja sonst nur noch Root Hub da, aber es funktioniert
>ja ma anderen PC auch nicht ???

Der Atmel-USB-Bootloader funktioniert aber weiterhin?
Da müsstest Du die Plaine ja im Gerätemanager sehen.

>Das Projekt MyUSB hab ich mir auch schon ein wenig angeschaut gehabt,
>aber nachdem ich die DLL nicht in C# einbinden konnte habs ichs
>gelassen, hoff eigentl. immer noch, dass das hier funktioniert. HID oder
>nicht HID ist kein Problem.

Ich bin momentan etwas ratlos. Fehler, wo es mal geht, dann wieder 
nicht, sind mit die unangenehmsten. (Bei meiner Platine muss ich leider 
einen Pin hochbiegen für den Umbau auf self-powered, daher ist meine 
Begeisterung nicht so groß. Ich werde es aber probieren, evtl. aber erst 
am Wochenende.

Bist Du denn sicher, dass Du LibUSB mit C# verwenden kannst? Sonst nützt 
Dir die funktionierende Hardware ja eh nicht viel. Wie ich weiter oben 
schon schrieb, ich könnte Dir eine meiner Platinen schicken (ich habe 
zur Zeit zwei im Schrank liegen die ich nicht benötige.).

Gruß

Stefan Salewski

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hast Du evtl. einen dicken Kondensator auf der Platine?
> Für den USB-Bus sind maximal 10uF erlaubt, sonst ist der Strom beim
> Einstecken zu groß.

hatte einen 3,3uF vom 7805 noch dra, aber der ist jetzt auch weg und es 
hat sich nichts geändert.

> Der Atmel-USB-Bootloader funktioniert aber weiterhin?
> Da müsstest Du die Plaine ja im Gerätemanager sehen.

Habe den Bootloader nicht Standardmäßig drauf, lade ihn nur hin und 
wieder rauf zum schauen ob USB funktioniert.
Programmiere normal InSystem mit SPI.

> Ich bin momentan etwas ratlos. Fehler, wo es mal geht, dann wieder
> nicht, sind mit die unangenehmsten. (Bei meiner Platine muss ich leider
> einen Pin hochbiegen für den Umbau auf self-powered, daher ist meine
> Begeisterung nicht so groß. Ich werde es aber probieren, evtl. aber erst
> am Wochenende.

Ich gaube das heute morgen war auch keine wirkliche Erkennung der 
Hardware sondern eher ein kurzer Abrutscher von mir und dadurch ein 
Kurzschluss am USB, weshalb dann auch die Fehlermeldung kam. Habs grad 
nochmal probiert => gleiche Meldung.

> Bist Du denn sicher, dass Du LibUSB mit C# verwenden kannst? Sonst nützt
> Dir die funktionierende Hardware ja eh nicht viel. Wie ich weiter oben
> schon schrieb, ich könnte Dir eine meiner Platinen schicken (ich habe
> zur Zeit zwei im Schrank liegen die ich nicht benötige.).

Die USB Verbindung ist ein Teil eine Projektes das ich mom. in der 
Schule mache, sollte es deshalb schon selber machen, aber danke für das 
Angebot - sehr nett =)


Wenn ich Probleme mit ESD hätte ( Statische Aufladung hat dem uC was 
getan ), dann würde der ganze uC nicht gehen, oder? Oder kann es sein, 
dass es nur Teile ( z.b. USB ) zerstört hat oder dass dies halt nun 
fehlerhaft funktioniert.
Werde mir nun ein AT90USB1287 bestellen und auf der neuen Platine 
aufbringen, MAX hab ich natürlich nun integriert.

danke für die ausführliche hilfe

gruß
Matthias T.

Autor: Michael Kentschke (mad_axe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das Projekt MyUSB hab ich mir auch schon ein wenig angeschaut gehabt,
>aber nachdem ich die DLL nicht in C# einbinden konnte habs ichs
>gelassen, hoff eigentl. immer noch, dass das hier funktioniert. HID oder
>nicht HID ist kein Problem.

Es gibt auch eine .net Implementierung von libUSB, nennt sich 
LibUsbDotNet. Hab ich selber schon verwendet mit meinem at90usb162 ...

Aber so schwer isses auch nicht das ganze in C++ direkt zu machen ...

Gruß
Micha

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich verwende auch die LibUsbDotNet. Das Problem ist ja nicht ein 
feriges Programm in C++ ein wenig anzupassen, sondern da kommt dahinter 
ja ein größeres Programm mit Auswertung, Diagrammen, Tabellen etc., da 
möchte ich gerne bei der vertrauten Programmiersprache bleiben =)

Das Problem ist nach wievor, dass es den Controller nicht annähernd am 
USB erkennt.

gruß

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du eine Möglichkeit, das Geplänkel auf den Datenleitungen zu 
verfolgen? Damit könntest du wenigstens mal überprüfen, ob sich 
überhaupt was tut wenn du das Teil einsteckst, oder ob evtl. die 
Pull-Ups deaktiviert sind, bzw. die Pins vom Controller aktiv auf Low 
gezogen werden. Komisch ist ja, dass der Bootloader funktioniert, also 
scheint die USB-betreffende Hardware ja durchaus in Ordnung zu sein. Ein 
Defekt durch ESD wäre aber natürlich durchaus denkbar, damit können die 
seltsamsten Fehler produziert werden (Daher ist es ja auch so 
problematisch - manchmal). Hast du denn nur diesen einen Chip?

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
werd mir mal ein oszi besorgen un "schauen".
hab leider kein anderen chip, bestelle aber auf die nächste platine ein 
at90usb1287 der müsste ja layout und programm mäßig voll kompatibel zum 
64-er sein, oder ?
die PullUp´s/Down´s müssten ja eigentl. durch die Firmware gesteuert 
werden und die funktioniert ja.

mfg

Autor: Michael Kentschke (mad_axe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du mal die Beispiele von Atmel probiert (z.B. HID und MS Device). 
Die ließen sich bei mir ohne Probleme kompilieren und wurden auch 
korrekt unter WIndows erkannt etc. Manchmal sind die Beispiele von Atmel 
nicht so toll, aber in dem Fall haben Sie wie gesagt alle ohne Probleme 
geklappt.

Gruß
Micha

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Matthias T. (maette)

Ich habe mal eben ein Hexfile für den AT90USB647 erzeugt und auf

www.ssalewski.de/tmp

abgelegt. Du kannst ja mal testen ob das funktioniert.

Das ist meine Firmware, mit deaktiviertem Debugging-Code für AT90USB647.

Und probier sonst mal, wie Michael Kentschke schrieb, ob Du den Atmel 
Code zum laufen bekommst.

Gruß

Stefan Salewski

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

danke für das File, hat leider nicht funktioniert. Dein sudd.hex und 
mein sudd.hex sind fast exakt gleich groß ( 16Byte unterschied ). Hab 
ein paar kleine Unterschiede beim Port.

Das mit den Atmel Programmen hatte ich davor schon vergeblich versucht 
und habs jetzt nochmal probiert, leider keine Reaktion.

Autor: Michael Kentschke (mad_axe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ich nur nicht so richtig verstehe ist, das es mit dem Bootloader 
über Flip funktioniert. Das weißt doch eindeutig auf eine 
funktionierende Hardware hin.
Dementsprechend ist es wirklich komisch das selbst die einfachsten 
Beispiele von Atmel nicht erkannt werde.

Hast du es mal an einem anderen Rechner probiert ???

Gruß
Micha

P.S. hab jetzt nich alles im Detail gelesen .. aber bei Software USB 
(obdev) hatte ich früher auch immer mal die Meldung von Windows wecken 
überspannungsschutz ... soll heißen da reicht schon der kleinste Wackler 
... :) .. und z.b. reicht ja schon der widerstand an d+ (oder d-, je 
nach dem ob full oder low speed) das windows sagt "unbekanntes gerät" 
...

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das mit den Atmel Programmen hatte ich davor schon vergeblich versucht
>und habs jetzt nochmal probiert, leider keine Reaktion.

Na dann liegt es ja wohl nicht an meiner Firmware.

Gut für mich, insbesondere gut für mich, dass ich noch nicht versucht 
habe, eine meiner Platinen mit Gewalt auf self-powered umzubiegen.

Passen würde jetzt noch, dass Dein Takt nicht 16 MHz ist. Denn Atmels 
Bootloader past sich dem Takt an, meine Firmware nicht. Bei den 
Atmel-Beispielen weiss ich es nicht, aber ich würde denken, dass man 
dort auch die richtige Taktfrequenz einstellen muss. Daher meine Frage 
nach Taktfrequenz ganz zu Anfang. Aber Du sagst ja 16 MHz, was ok wäre. 
Du schreibst was wie "LED toggled mit 2 MHz" -- naja, kommt drauf an wie 
die Schleife programmiert ist. Könnte auch mit 8 MHz gehen. Wenn der 
Quarz falsch bedruck wäre? Oberwellenquarz wird es wohl nicht sein, da 
hat man ja 8 statt 24 MHz. Vielleicht doch ein exotischer 
Hardwaredefekt, der aus irgend welchen Gründen beim Bootloader nicht 
auftritt?

Ich habe jetzt keine weiteren Ideen mehr. Solche Ferndiagnosen sind 
schon recht schwierig.

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hast du es mal an einem anderen Rechner probiert ???

Ja, habs an einem anderen Laptop und unter Linux probiert.

> P.S. hab jetzt nich alles im Detail gelesen .. aber bei Software USB
> (obdev) hatte ich früher auch immer mal die Meldung von Windows wecken
> überspannungsschutz ... soll heißen da reicht schon der kleinste Wackler
> ... :) .. und z.b. reicht ja schon der widerstand an d+ (oder d-, je
> nach dem ob full oder low speed) das windows sagt "unbekanntes gerät"

Windows meldet eben nicht unbekanntes Gerät, sondern zu hoher 
Energieverbrauch, das kommt auch schon wenn nur was Kabel dort hängt und 
man einen Kurzen macht.

>Passen würde jetzt noch, dass Dein Takt nicht 16 MHz ist.

Ich werde das heute nochmal mit dem Oszi betrachten, es gibt ja ein Port 
an dem man den Clock ausgeben lassen kann.

Ferndiagnosen sind in der Tat sehr schwirig, aber danke für die hilfe.

Habe mit jetzt den 128-er bestellt und werde den auf mein neues Board 
montieren. Vielleicht wars einfach nur ein blöder Fehler.

Danke an alle für die Hilfe
Matthias

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, habe heute mit dem Oszi am Usb geschaut, da tut sich einfach nichts.
Schätze ein Hardware defekt, oder sonst was verzwicktes =)

Habe heute meinen neuen at90usb1287 bekommen, der wird gleich morgen 
Verbaut und dann teste ich das ganze nochmal ;)

danke nochmal für die Hilfe
melde mich morgen wieder.

gruß
Matthias

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

hab jetzt das Board mit dem AT90USB1287 aufgebaut, eingesteckt und hat 
sofort einwandfrei funktioniert =)

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias T. (maette) schrieb am 29.03.2008 um 12:47 Uhr:

>hallo,

>hab jetzt das Board mit dem AT90USB1287 aufgebaut, eingesteckt und hat
>sofort einwandfrei funktioniert =)

Das freut mich (für Dich).

Es wäre natürlich schon interessant, herauszufinden was das Problem mit 
dem anderen Board/Chip war. Das Atmels USB-Bootloader funktioniert hat, 
alles andere aber nicht, ist schon höchst eigenartig.

Es gibt ja eine Reihe von Berichten (auch hier im Forum) von Leuten, die 
mit selbst gebauten Boards für AT90USB1287 seltsame Probleme hatten. 
Leider haben die dann nichts mehr von sich hören lassen.

Gruß

Stefan Salewski

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
puh, schwierig zu sagen, vielleicht wars ja ein seltsamer Hardware 
defekt ?

Noch eine neue Frage kann es sein, dass ich für meinen uC einen 
Kühlkörper brauche, ich weiss klingt komisch, aber hab ihn grad ( 
ausversehen ) ein paar  Stunden laufen lassen und der war so heiss, dass 
man ihn nicht mehr angreifen konnte.
Wie gehts euch wenn er mehrere Stunden läuft ? Schätze sind so um die 12 
std gewesen.

gruß
Matthias

Autor: Michael Kentschke (mad_axe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich kann nur für den AT90USB162 reden, und der wird auch nach 
einigen Tage nicht annähernd warm, so wie man es von fast allen AVRs 
gewohnt ist ;-). Soll heißen irgendwas stimmt da bei dir nicht, weswegen 
vielleicht auch der 64er ne Macke bekommen hat :)

Gruß
Micha

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Noch eine neue Frage kann es sein, dass ich für meinen uC einen
>Kühlkörper brauche

Nein. Bei mir wird der AT90USB1287 nicht merklich warm. P=20mA*5V=100mW, 
damit sollte er nicht warm werden.

Wenn permanent Datenübertragung über USB stattfindet wird er evtl. etwas 
wärmer werden, aber heiß sollte er nicht werden.

Da stimmt etwas in Deiner Schaltung nicht.

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wird deiner nicht warm weil er quasi von der umgebungsluft gekühlt wird 
oder sollte allgemein nicht war werden?
Meiner ist auf der unterseite der Platine und hat ein paar Millimeter 
Abstand zur Unterlage, kann das sein, dass das zu wenig ist ?

mfg

PS.: Daten sollten nicht gesendet worden sein - normal hat er dann genug 
abstand, ist mom nur zu test zwecken.

Autor: Michael Kentschke (mad_axe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich würde mal sagen der wird einfach nicht warm. Ich kann mir nicht 
vorstellen das das io ist wenn deiner so warm wird das man ihn fast 
nicht mehr anfassen kann, egal wieviel platz da nach unten oder oben 
ist. Da stimmt meiner Meinung nach irgendwas nicht.
Meiner läuft wie gesagt Tage im Dauerbetrieb mit Aktivitäten und da wird 
nie irgendwas warm. Wie auch bei allen anderen AVRs die ich benutze.

Gruß
Micha

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wie kann ich eigentl. einfach 64 Byte über EP02 schicken, also wenn ich 
die Daten auf einmal zur Verfügung habe und sie nicht durch einen Timer 
gefüllt werden?

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann es sein, dass die Temperatur stark von der aktivität abhängig ist?

Ich weiss nicht genau wann, aber abundzu ist er einfach so heiss, dass 
man ihn nicht mehr angreifen kann ( kurz nach dem einstecken ) und 
manchmal einfach nur lauwarm.

Hat jemand eine Idee, kann das mit der USB auslastung zusammenhängen ?

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich weiss nicht genau wann, aber abundzu ist er einfach so heiss, dass
>man ihn nicht mehr angreifen kann ( kurz nach dem einstecken ) und
>manchmal einfach nur lauwarm.

>Hat jemand eine Idee, kann das mit der USB auslastung zusammenhängen ?

Was der USB Datentransfer an zusätzlicher Leistung verbraucht weiß ich 
so aus den Kopf nicht.

Aber ich denke wie Michael Kentschke, dass in deiner Schaltung ein 
Fehler sein wird.

Hast Du wie im Datenblatt angegeben auch den AVCC Pin angeschossen (an 
VCC)?

Wird er im self- oder im Bus-powered Betrieb so heiß?

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Er wird im Bus-Powered betrieb so heiss, den AVCC hab ich über den LC 
Tiefpass angeschlossen.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Er wird im Bus-Powered betrieb so heiss, den AVCC hab ich über den LC
>Tiefpass angeschlossen.

Du hast ihn also angeschlossen wie im Datenblatt angegeben (bzw. so wie 
auch meine Platine beschaltet ist) und Du hast auch sonst nichts auf der 
Platine, das für den uC eine große Last darstellen könnte?

Dann sollte er wie gesagt nicht sehr warm werden.

Möglich wäre, dass er intern einen Fehler hat, oder dass Du einen Pin 
als Ausgang programmiert hast und diesen irgendwie kurz geschlossen 
hast. Wenn Eingangspins auf undefinierten Potential liegen ist das auch 
ungünstig. Aber wenn Du sie nicht explizit anders programmiert hast, 
sollten die IO-Pins als Eingang mit aktiviertem Pullup programmiert 
sein, das sollte unkritisch sein.

Eigentlich hat das heiß-werden nicht direkt etwas mit USB Funktionalität 
zu tun -- vielleicht suchst Du mal selbst nach Stichworten wie "AVR 
heiß" oder startest einen neuen Thread zum Thema. (Hier lesen wohl nicht 
mehr so viele mit.)

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
  
RB_Init();
    uint16_t w = 2007;
  for(uint8_t j = 0; j <= 64(32); j++)
  {    
  
        RB_Write(w);
      

  UsbDevSelectEndpoint(2);
  if (UsbDevTransmitterReady())
  {
   
        w = RB_Read();
        //w = cnt; dump counter to FIFO for testing
        UsbDevWriteByte(LSB(w));
        UsbDevWriteByte(MSB(w));

      if ( j == 64(32) )
    {
        UsbDevClearTransmitterReady();
        UsbDevSendInData();
    }
    
  }
  
}

müsste das so eigentl. nicht funktionieren Daten über EP02 zu schicken? 
ist ungefähr das von daq_dev.c nur hab ich eben auf einmal zur 
Verfügung.
Dass es nicht stimmt und warsch. ziemlicher blödsinn ist, was ich da 
geschrieben habe weiss ich, kann mir jemand bitte kurz ein Anhaltspunkt 
geben, wie ich mehr daten ( > 40 Byte ) über EP02 schicken kann.
Es sollte ja am PC auch ein Recived Event erzeugen oder? EP01 
funktioniert einwandfrei.

danke für jede Hilfestellung

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
EDIT:

hab oben das switch innerhalb vom if transmready vergessen :
switch (UsbDevGetByteCountLow())
    {
      default:
        w = RB_Read();
        UsbDevWriteByte(LSB(w));
        UsbDevWriteByte(MSB(w));
        break;
      case 64:
        UsbDevClearTransmitterReady();
        UsbDevSendInData();
    }

ändert aber nichts :(

Autor: Mätte T. (maette)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
da kann ich lang probieren, problem lag software seitig beim 
OnDataReceivedDelegate, tztz =)

danke, danke
jetzt funzts
grüße

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.