Hallo an alle. Ich verwende den VUSB-Treiber um einen Encoder als Tastatur zu emulieren und diesen an einem PC als Pfeil-runter und Pfeil-rauf Taste nutzen zu können. Ansich funktioniert das auch. Mein Problem ist aber, dass das Teil nicht vom PC erkannt wird, wenn es am PC angeschlosen ist, wenn dieser Hochfährt. Nehme ich ihn dann wieder ab und stecke ihn neu ein, läuft wieder alles. Ich habe leider noch nix gefunden, was mir bei dem Problem helfen kann... Hat jemand eine Idee woran das liegen kann? Bzw. was ich dagegen machen kann? Ich habe hier Windows XP an meinem Testrechner. Bei Windows7 soll es auch auftreten. Gruß und schon mal danke fürs drüber nachdenken. ;-) bpie
Zeig mal deine Hardwareumsetzung, schon alleine dort gibt es viele Möglichkeiten. z.B. gesammte Schaltung auf 3,3V oder auf 5V und dann die D+ und D- mit Z-Dioden auf 3,3V gebracht?
Versuch mal die Z-Dioden auf 3,6V zu erhöhen. habe auch schon Schaltungen mit 3,9V gesehen bei gleichen Widerstandswerten (R4, R5). z.B. http://www.ulrichradig.de/home/index.php/avr/usb-avr-prog
Hi Studentle schrieb: > Versuch mal die Z-Dioden auf 3,6V zu erhöhen. Bei der Gelegenheit sollte auch der USB-Shield auf GND "gebandpasst" werden. 1MOhm und 4.7nF sind wohl dafuer empfohlen. Ist zwar fuer XMega Serie - aber man kann bestimmt etwas daraus verwenden: http://www.atmel.com/Images/doc8388.pdf MfG
Du könntest deine Versorgungsspannung auch auf 3.3V reduzieren, dann benötigst du keine Z-Dioden mehr und R9 darf dann nur noch 1k Ohm groß sein.
Zusaetzliche Anmerkung: Wenn Hardwareanmerkungen bisher nichts bringen, koenntest du vielleicht fuer uns einmal kurz Linux (Knoppix?) per LIVE-CD auf dem betreffenden Rechner booten? Dann den Stick reinstecken und uns das Log posten? MfG
:
Bearbeitet durch User
Mal ne Frage von nem USB-Unwissenden. Sollten die Z-Dioden nicht hinter R4/5 liegen?
Birgit Pie schrieb: > Mein Problem ist aber, dass das Teil nicht vom PC erkannt wird, wenn es > am PC angeschlosen ist, wenn dieser Hochfährt. Nehme ich ihn dann wieder > ab und stecke ihn neu ein, läuft wieder alles. Hast du mal ausprobiert, nur den ATtiny45 anzuschließen und alle anderen USB-Geräte abzustöpseln? Manchmal behindern die sich gegenseitig.
Hi Teo Derix schrieb: > Mal ne Frage von nem USB-Unwissenden. > Sollten die Z-Dioden nicht hinter R4/5 liegen? Nein - denn die Dioden sollen das 5V Potential aus dem Mikrocontroller auf 3.3V reduzieren. Ohne Widerstand wuerden da theoretisch "unendliche" Stroeme fliessen - praktisch geht vermutlich der PIN am AVR kaputt. Vom USB her kommen bereits 3.3V Kommunikationsspannung, welche durch die hohe Eingangstoleranz im AVR als korrekte Logikpegel erkannt werden. MfG
:
Bearbeitet durch User
Teo Derix schrieb: > Sollten die Z-Dioden nicht hinter R4/5 liegen? Weil die 5V ja von AVR kommen und die USB-Datenleitungen mit 3.3V arbeiten. Die Widerstände begrenzen den Strom auf (5-3.3)/68 = 25mA.
Stephan B. schrieb: > Ohne Widerstand wuerden da theoretisch "unendliche" Stroeme fliessen - > praktisch geht vermutlich der PIN am AVR kaputt. Der geht praktisch lange nicht kaputt. So einen (einzelnen) AVR Pin kannst du problemlos sogar an Vcc legen und gegen Masse schalten oder andersrum...
Hallo Lothar Miller schrieb: > Der geht praktisch lange nicht kaputt. So einen (einzelnen) AVR Pin > kannst du problemlos sogar an Vcc legen und gegen Masse schalten oder > andersrum... Okay, gut zu wissen das die Dinger so robust sind. Bei der Versorgung ueber USB fuhert das dann aber vermutlich dazu, das die Vcc absinkt und der BrownOut den AVR abschaltet. Richtig funktionieren tut's USB dann auch nicht. MfG
Birgit Pie schrieb: > Ich verwende den VUSB-Treiber um einen Encoder als Tastatur zu emulieren > und diesen an einem PC als Pfeil-runter und Pfeil-rauf Taste nutzen zu > können. > Ansich funktioniert das auch. > Mein Problem ist aber, dass das Teil nicht vom PC erkannt wird, wenn es > am PC angeschlosen ist, wenn dieser Hochfährt. Nehme ich ihn dann wieder > ab und stecke ihn neu ein, läuft wieder alles. Was passiert, wenn du im BIOS den "USB legacy support" abschaltest? (Sofern das bei deinem BIOS/UEFI überhaupt noch möglich ist)
Hans Jelt schrieb: > Weil die 5V ja von AVR kommen und die USB-Datenleitungen mit 3.3V > arbeiten. Danke! (Hatte die 5V dem USB zu geschrieben, wie peinlich :-} )
Hallo. Zunächst danke für die vielen Antworten und sorry für meine späte Antwort, die Grippe hat mich erwischt...aber jetzt kann es weiter gehen. So, dann zu euren zahlreichen Ideen: 1. Versuch mal die Z-Dioden auf 3,6V zu erhöhen. -> Das dauert leider noch etwas, da ich diese Z-Dioden nicht da habe, nur 4,7V und das ist dann wohl etwas zu hoch, oder? Sobald der Test mit den 3,6V gelaufen ist, gebe ich Bescheid. 2. Bei der Gelegenheit sollte auch der USB-Shield auf GND "gebandpasst" werden. 1MOhm und 4.7nF sind wohl dafuer empfohlen. -> Das brachte bei dem aktuellen Problem keine Besserung, war aber wohl auch eher "allgemein" gemeint. 3. Wenn Hardwareanmerkungen bisher nichts bringen, koenntest du vielleicht fuer uns einmal kurz Linux (Knoppix?) per LIVE-CD auf dem betreffenden Rechner booten? Dann den Stick reinstecken und uns das Log posten? -> Dazu muss ich sagen, dass ich mit Linux bisher noch nicht so viel gemacht habe...die Live-CD kann ich mir vermutlich downloaden...aber wie komme ich dann zu dem Log? Ich habe in einer VM Linux (Ubuntu) installiert. Das sollte doch auch als Test funktionieren, oder? Wenn ja, kann mir jmd. sagen, wie ich zu dem Log komme? 4. Hast du mal ausprobiert, nur den ATtiny45 anzuschließen und alle anderen USB-Geräte abzustöpseln? Manchmal behindern die sich gegenseitig. -> Ja. Sowohl an dem ersten Testrechner (Laptop) als auch an dem zweiten (normaler PC auch mit Windows XP) waren nur der ATMEGA angeschlossen, mit dem gleichen Ergebnis, dass er nicht gefunden wurde. 5. Was passiert, wenn du im BIOS den "USB legacy support" abschaltest? (Sofern das bei deinem BIOS/UEFI überhaupt noch möglich ist) -> Beim Laptop gibt es diese Einstellung im BIOS nicht. Beim PC war es bereits abgeschaltet. Habe es versuchsweise mal angeschaltet, brachte aber auch nichts. Ich bin echt ratlos, hoffe, dass die 3,6V Z-Dioden helfen…
Birgit Pie schrieb: > -> Das dauert leider noch etwas, da ich diese Z-Dioden nicht da habe, > nur 4,7V und das ist dann wohl etwas zu hoch, oder? > Sobald der Test mit den 3,6V gelaufen ist, gebe ich Bescheid. Falls du auch "normale" Dioden da hast, könntest du jeweils eine Z-Diode und eine normale in Reihe schalten (entgegengesetzte Polung natürlich). Damit kommst du auf ca. 3,9 Volt, was wahrscheinlich auch ok ist.
Markus Weber schrieb: > Birgit Pie schrieb: >> -> Das dauert leider noch etwas, da ich diese Z-Dioden nicht da habe, >> nur 4,7V und das ist dann wohl etwas zu hoch, oder? >> Sobald der Test mit den 3,6V gelaufen ist, gebe ich Bescheid. > > Falls du auch "normale" Dioden da hast, könntest du jeweils eine Z-Diode > und eine normale in Reihe schalten (entgegengesetzte Polung natürlich). > Damit kommst du auf ca. 3,9 Volt, was wahrscheinlich auch ok ist. Da waere ich vorsichtig! Fuer Details lese bitte: http://forums.obdev.at/viewtopic.php?f=8&t=8751&sid=6a19b063a258fd8271fe62f46af5f646 MfG
Stephan B. schrieb: > Da waere ich vorsichtig! Fuer Details lese bitte: > http://forums.obdev.at/viewtopic.php?f=8&t=8751&sid=6a19b063a258fd8271fe62f46af5f646 Halt, das war wohl ein Missverständnis. :-) Die "normalen" Dioden jeweils in Reihe zu den Z-Dioden und natürlich nicht so, wie in deinem Link gezeigt.
So, die Z-Diode ist da, getauscht...das gleiche Ergebnis, Problem also nicht behoben. Ich habe das ganze mal noch an einem anderen Rechner probiert, auf dem Windows7 installiert ist. Da hat es erstaunlicherweise funktioniert. Allerdings muss ich dazu sagen, dass alle 3 Rechner unterschiedliche Hardware haben. >Wenn Hardwareanmerkungen bisher nichts bringen, koenntest du vielleicht >fuer uns einmal kurz Linux (Knoppix?) per LIVE-CD auf dem betreffenden >Rechner booten? >Dann den Stick reinstecken und uns das Log posten? Wenn mir hierzu jemand sagen kann, wie ich an das Log komme und ob das ganze auch mit Linux in der VR-Umgebung funktioniert (denke schon), würde ich auch diese Infos gern noch bereit stellen. Danke.
Birgit Pie schrieb: > So, die Z-Diode ist da, getauscht...das gleiche Ergebnis, Problem also > nicht behoben. :-( > Allerdings muss ich dazu sagen, dass alle 3 Rechner unterschiedliche > Hardware haben. 100 µF an USB zu hängen, hab ich mich bisher nicht getraut, aber das sollte eigentlich trotzdem gehen. > Wenn mir hierzu jemand sagen kann, wie ich an das Log komme und ob das > ganze auch mit Linux in der VR-Umgebung funktioniert (denke schon), > würde ich auch diese Infos gern noch bereit stellen. Aus einer VR-Umgebung ist der Zugriff auf die Hardware immer nicht so einfach – oder er wird gar umgeleitet, und man nutzt dann die Treiber des Wirts-Systems, was dir dann natürlich nicht viel nützt. Warum erzeugst du dir nicht einfach eine Linux-DVD (Ubuntu oder Knoppix oder Debian) und bootest den Windows-PC von dieser? Linux ist sehr flexibel, man muss es gar nicht installieren, man kann es auch von einer DVD aus oder von einem USB-Stick aus verwenden. Dann läuft es natürlich langsamer, aber in diesem Fall stört das sicher nicht. Und vielleicht gefällt es dir am Schluss doch so gut, dass du umsteigst. ;-)
Es gibt da noch etwas an das es liegen könnte ... hänge das V-USB-Gerät mal nicht direkt an den USB-Port des Rechners sondern hänge einen Hub dazwischen. Wenn du noch einen USB 1.1 Hub hast wäre das natürlich ideal. Was ich auch noch machen würde: Versorgungsspannung auf 3.3V reduzieren (Z-Dioden entfernen) -> R9 von 1.5k Ohm auf 1k Ohm verkleinern
Hans Jelt schrieb: > Es gibt da noch etwas an das es liegen könnte ... hänge das V-USB-Gerät > mal nicht direkt an den USB-Port des Rechners sondern hänge einen Hub > dazwischen. > Wenn du noch einen USB 1.1 Hub hast wäre das natürlich ideal. Gute Idee, finde ich. > Was ich auch noch machen würde: > Versorgungsspannung auf 3.3V reduzieren (Z-Dioden entfernen) > -> R9 von 1.5k Ohm auf 1k Ohm verkleinern Hmmm... aber prüfen, ob der ATtiny45 dann noch läuft. Für V-USB ohne eigenem Quarz wird meist eine Taktfrequenz von 16,5 MHz verwendet (interner RC-Oszillator). Dafür könnten 3,3 Volt dann zu wenig sein. Muss man probieren.
Angehängte Dateien:
-
VUSB_1.JPG
68 KB -
VUSB_2.JPG
59 KB -
VUSB_3.JPG
81 KB
Hallo. Nach längerer Pause "muss" ich mich nun wieder mit diesem Problem beschäftigen. ;-) Das heißt, es ist leider noch nicht erledigt. > Es gibt da noch etwas an das es liegen könnte ... hänge das V-USB-Gerät > mal nicht direkt an den USB-Port des Rechners sondern hänge einen Hub > dazwischen. > Wenn du noch einen USB 1.1 Hub hast wäre das natürlich ideal. Das habe ich getestet, leider nur mit einem 2.0 Hub. Der Fehler ist genau der gleiche. >Wenn Hardwareanmerkungen bisher nichts bringen, koenntest du vielleicht >fuer uns einmal kurz Linux (Knoppix?) per LIVE-CD auf dem betreffenden >Rechner booten? >Dann den Stick reinstecken und uns das Log posten? Ich habe das mit einer Ubuntu (12.04) Live CD probiert. Nun ist es so, dass an dem einen Laptop prinzipiell das gleiche Verhalten zu sehen war, wie bisher. Davon habe ich die 2 LogFiles bei getan. Eins nach dem Hochfahren, wo es nicht funktioniert hat. Das zweite nachdem ich das Gerät nochmal abgezogen und wieder angesteckt habe und es dann funktionierte. An einem anderen Laptop funktioniert es im Ubuntu auch direkt nach dem Hochfahren. Aber bei beiden Laptops funktioniert es nicht im Windows. Von der Windows-Variante habe ich gestern mal noch ein paar Screenshots der Datensignale gemacht. Vielleicht sagt das jemandem etwas. USB-Gerät wird NACH dem Hochfahren angeschlossen: VUSB_3.PNG: ständige Signalwechsel USB-Gerät wird VOR dem Hochfahren angeschlossen: VUSB_1.PNG: zu Beginn noch ein paar korrekte(?) Signalwechsel VUSB_2.PNG: Dauersignal, Gerät wird nicht erkannt Danke an alle, die drüber nachdenken. Gruß. bpie
Hängen da 100 µF am USB? Also, ich habe ähnliche Probleme oft mit einem USBASP. Wenn ich den an den PC stecke und danach eine Platine zum Programmieren anschließe, kackt der USB-Kram oft erstmal ab (durch den Ladevorgang am Elko). Da half dann nur rausziehen und neu anstecken... bis ich der Firmware von USBASP mal eine kleine Änderung verpasst und außerdem den Brownout Detektor aktiviert habe. Jetzt passiert folgendes ganz am Anfang: - Watchdog aktivieren - usbDeviceDisconnect() aufrufen, wichtig, damit das Gerät bei einem Fehler (-> Reset) definiert getrennt wird - dann die ganzen Port-Inits - 500 ms Wartezeit - dann erst usbDeviceConnect() - ...
Ich könnte mir vorstellen, dass V-USB den vom Host ausgelösten Device-Reset nicht korrekt implementiert hat (ich kenne V-USB zwar nicht, aber das USB-Protokoll dafür etwas mehr). Beim Starten eines kompletten PCs ist es durchaus wahrscheinlich, dass der USB-Bus mehrfach neu enummeriert wird, obwohl die USB-Versorgungsspannung die ganz Zeit eingeschaltet bleibt. Das ist aus Sicht des USB-Devices eine vollkommen andere Situation als das anstecken an den Bus. Dein VUSB_2.JPG zeigt schön das Reset-Signalling ... allerdings sind die Phasen mit High-Signal an der D- Leitung (ich nehme mal an Ch1 ist D-) zu kurz. Die Reset-Recovery-Time sollte eigentlich mindestens 10ms sein. ( siehe USB2.0 Spec, 7.1.7.5 Reset Signaling, http://www.usb.org/developers/docs/usb20_docs/ ) Dazu passt dann auch gut die Linux-Fehlermeldung: hub 2-0:1.0: connect-debounce failed, port 1 disabled Du könntest mal schauen, ob V-USB den Tiny in dieser Situation auch alle ca. 20ms resettet? Dann würde evtl. schon helfen, vorm ersten usbDeviceDisconnect() etwas länger zu warten.
Markus Weber schrieb: > Hmmm... aber prüfen, ob der ATtiny45 dann noch läuft. Für V-USB ohne > eigenem Quarz wird meist eine Taktfrequenz von 16,5 MHz verwendet > (interner RC-Oszillator). Dafür könnten 3,3 Volt dann zu wenig sein. > Muss man probieren. @ Birgit Pie (bpie) Vielleicht könntest du den ATTiny45 mal mit einem 12MHz Quarz bestücken und probieren ob es so besser läuft.
Angehängte Dateien:
-
P1190248.JPG
420 KB
Lass mal die Z-Dioden weg! Ich arbeite schon mehreren Jahren mit dieser Schaltung und die Funktioniert ohne Probleme. Es gibt 3 Arten der Beschaltung . Hatte das gleiche Problem mit einem ATMega 8. Außerdem sollte man einen ATMega verwenden der eine eigenen Quartz benutzt. Dann ist man auf der sicheren Seite. Habe so mehrere usbisp aufgebaut und eine Schaltung mit der man einen Atmega 32 als Schnittstelle für den i2c Bus verwenden kann.
Nein. Wenn der AVR mit 5 Volt betrieben wird, müssen die Z-Dioden rein. Der Standard sieht vor, dass gewisse Pegel eingehalten werden müssen. Es gibt auch Systeme, bei denen die Geräte sonst nicht erkannt werden (selbst getestet und stundenlang nach dem Fehler gesucht!)
Chris schrieb: > Ich könnte mir vorstellen, dass V-USB den vom Host ausgelösten > Device-Reset nicht korrekt implementiert hat (ich kenne V-USB zwar > nicht, aber das USB-Protokoll dafür etwas mehr). Beim Starten eines > kompletten PCs ist es durchaus wahrscheinlich, dass der USB-Bus mehrfach > neu enummeriert wird, obwohl die USB-Versorgungsspannung die ganz Zeit > eingeschaltet bleibt. Das ist aus Sicht des USB-Devices eine vollkommen > andere Situation als das anstecken an den Bus. Der erste Beitrag, der ein tatsächliches Problem anspricht! Die ganzen Vermutungen zur Beschaltung passen nicht zur Reproduzierbarkeit des Problems. Meine Vermutung wäre auch, dass der Reset nicht erkannt wird. Bisher wurde noch nichts über die Software gesagt? In V-USB wird der Reset "manuell" über usbpoll() gepollt. Wenn diese Funktion nicht häufig genug aufgerufen wurden, wird ein Reset nicht erkannt und die Enumeration funktioniert nur direkt nach dem Kaltstart des Controllers. Kannst Du die Hauptschleife Deines Codes posten?
Sven Schwiecker schrieb: > Lass mal die Z-Dioden weg! Ich arbeite schon mehreren Jahren mit dieser > Schaltung und die Funktioniert ohne Probleme. Es gibt 3 Arten der Ja toll. Es enstpricht aber trotzdem nicht der Spezifikation und kann, je nach Bauart des Host-Controllers, diesen zerstören.
Angehängte Dateien:
-
screenshot.png
21 KB
So sieht ein Reset mit Enumeration auf dem Bus auf. Das sollte irgendwann auftauchen und dann auch korrekt interpretiert werden.
Hallo. Der Code der Hauptschleife ist folgender:
1 | int main(void) |
2 | {
|
3 | uchar i; |
4 | uchar calibrationValue; |
5 | |
6 | calibrationValue = eeprom_read_byte(0); /* calibration value from last time */ |
7 | if(calibrationValue != 0xff){ |
8 | OSCCAL = calibrationValue; |
9 | }
|
10 | odDebugInit(); |
11 | usbDeviceDisconnect(); |
12 | for(i=0;i<20;i++){ /* 300 ms disconnect */ |
13 | _delay_ms(10); |
14 | }
|
15 | usbDeviceConnect(); |
16 | DDRB |= 1 << BIT_LED; /* output for LED */ |
17 | PORTB |= 1 << BIT_KEY; /* pull-up on key input */ |
18 | PORTB |= 1 << BIT_ENC_DIR; /* pull-up on "key" input */ |
19 | wdt_enable(WDTO_1S); |
20 | timerInit(); |
21 | init_encInt(); //Initialisierung Encoder |
22 | usbInit(); |
23 | sei(); |
24 | for(;;){ /* main event loop */ |
25 | wdt_reset(); |
26 | usbPoll(); |
27 | |
28 | if(usbInterruptIsReady() && nextDigit != NULL){ /* we can send another key */ |
29 | buildReport(); |
30 | usbSetInterrupt(reportBuffer, sizeof(reportBuffer)); |
31 | if(*++nextDigit == 0xff) /* this was terminator character */ |
32 | nextDigit = NULL; |
33 | }
|
34 | timerPoll();//Drucktaster des Encoders abfragen |
35 | if(enc_changed) { evaluateENC(); enc_changed=0; }//oo |
36 | |
37 | }
|
38 | return 0; |
39 | }
|
Ich habe testweise nach "odDebugInit();" ein "_delay_ms()" mit verschiedenen Zeiten eingefügt. So, dass am Oszi ca. 10ms zu sehen waren, leider hat auch dann das Erkennen nicht funktioniert.
Noch ein Test mit der for-Schleife wie folgt:
1 | for(;;){ /* main event loop */ |
2 | wdt_reset(); |
3 | usbPoll(); |
4 | |
5 | }
|
6 | }
|
Also nichts weiter drin als das usbPoll() führte zu dem gleichen Problem... Auch mit der Wartezeit vor usbDeviceDisconnect().
:
Bearbeitet durch User
Wie verhält sich denn ein anderes VUSB-Bastelgerät am Rechner? Zum Beispiel ein USBASP?
Eventuell läuft ja auch deine Oszillatorkalibrierung Amok, wenn der PC bootet und Versorgungsspannung da ist, aber kein brauchbares Signal. Ein richtiger Quarz wäre sicher mal eine Idee.
Birgit Pie schrieb: > Der Code der Hauptschleife ist folgender: Sieht soweit eigentlich ok aus, so lange nicht einer der Funktionsaufrufe hängen bleibt. Ich würde das Problem jetzt weiter angehen, in dem ich mir einen Debugausgang schaffe, z.B. ein pin mit soft-UART, und mir anzeigen lasse, wann ein Reset erkannt wird. Den Bus mit dem Oszi zu beobachten ist schwierig, da ist ein Logikanalyzer besser geeignet. Bla schrieb: > Eventuell läuft ja auch deine Oszillatorkalibrierung Amok, wenn der PC Könnte man auch gleich über den Debugausgang ausgeben.
:
Bearbeitet durch User
usbDeviceDisconnect() und usbDeviceConnect() vor dem usbInit() kommt mir persönlich seltsam vor, steht allerdings auch so in diesem Wiki: http://vusb.wikidot.com/driver-api Man könnte mal im V-USB sourcecode nachschauen, ob das ernst gemeint oder ein Versehen ist. Was soll das Programm bei einem Bus-Reset machen? Die Neukalibrierung wie bei http://vusb.wikidot.com/examples unter "Clocking the AVR from the RC oscillator with auto-calibration" beschrieben? Dann würde ich mal in der USB-Spec und mit dem Scope schauen, ob die Annahme mit dem Frame-Clock auch wirklich stimmt, oder ob das nur beim ersten mal anstecken passiert. Ansonsten musst Du Dich an den Fehler herantasten. Debug-Ausgang wie von Tim vorgeschlagen wär natürlich klasse. Als Vorstufe dazu könnte man auch erstmal die Pins für den Encoder vorübergehend als Status-Anzeigen verwenden.
Chris schrieb: > usbDeviceDisconnect() und usbDeviceConnect() vor dem usbInit() kommt mir > persönlich seltsam vor, steht allerdings auch so in diesem Wiki: > http://vusb.wikidot.com/driver-api Man könnte mal im V-USB sourcecode > nachschauen, ob das ernst gemeint oder ein Versehen ist. Die Reihenfolge ist ziemlich egal, da die Macros fast nichts machen :) Chris schrieb: > Was soll das Programm bei einem Bus-Reset machen? Die Neukalibrierung > wie bei http://vusb.wikidot.com/examples unter "Clocking the AVR from > the RC oscillator with auto-calibration" beschrieben? Dann würde ich mal > in der USB-Spec und mit dem Scope schauen, ob die Annahme mit dem > Frame-Clock auch wirklich stimmt, oder ob das nur beim ersten mal > anstecken passiert. Wenn am Bus ein Reset ohne anschließendes Keepalive/Framsignal ausgelost wird, wird calibrateosc den RC-Oscillator komplett dekalibrieren, da die Routine keinen Sanity-Check hat. Edit: Es ist sogar noch schlimmer: Die mitgelieferte Routine hat einen Timeout, verabeitet diesen aber nicht. Evtl. funktioniert meine Alternative in Assembler besser - die hängt einfach so lange, bis wieder ein Keepalive kommt: https://github.com/micronucleus/micronucleus/blob/master/firmware/osccalASM.S
:
Bearbeitet durch User
Die Fehlermeldung deutet auf irgentwelche Lowlevel-Probleme hin, der USB-Port an der Maschine ist wohl nicht tolerant wie an den anderen Maschinen. Ändere dein Design auf 3,3V mit Quartz und dann taste dich an dein Zieldesign ran.
Buchhalter schrieb: > Ändere dein Design auf 3,3V mit Quartz und dann taste dich an dein > Zieldesign ran. Du kannst ja PB3 als externen Takteingang nehmen, entweder du nimmst 12MHz einen Oszillator oder einen 12MHz Quarz mit Verstärkerschaltung. http://elektroniktutor.de/signalkunde/quarzosz.html http://www.rn-wissen.de/index.php/Quarzoszillator
Bla schrieb: > Wie verhält sich denn ein anderes VUSB-Bastelgerät am Rechner? Zum > Beispiel ein USBASP? Kann ich leider nichts zu sagen, habe kein anderes Gerät mit VUSB.
Ich habe mal nach "usbDeviceDisconnect();" und vor "for(i=0;i<20;i++)" ein LED_TOGGLE eingefügt. Wenn man diese dann mit dem Osci beobachtet, sieht man das der Pin ständig toggelt. Also wird anscheinend ständig ein Reset ausgeführt...aber warum? Der Watchdog? Ganz am Anfang der Routine habe ich anschließend ein "wdt_disable()" eingefügt...ohne Erfolg. Willkürlich gesetzte "wdt_reset()" brachten auch keinen Erfolg. Wenn ich die Datenleitung D- aus dem USB-Kabel raus nehme erfolgt zwar logischerweise keine Kommunikation, aber die LED toggelt auch nicht. Kann es sein, das der Reset vom PC ausgeführt wird?
Dein Gerät bekommt keinen richtigen Kontakt zum PC. Wie sieht denn die Resetbeschaltung bei dir aus? Im Schaltplan ist das scheinbar eine LED, ist nicht wirklich passend. Ein 10k bis 100k Ohm Widerstand nach Vcc und ein 100nF Kondensator nach Masse sind die Standardbeschaltung. Wenn alles okay ist liegt während des Betriebs am Reset-Pin die Versorgungsspannung an. Es könnte auch an der Methode "buildReport()" liegen, aber an deiner Stelle würde ich erst mal nicht bei der Software suchen, sondern bei der Hardware. Kopiere dein Projekt, schreibe die Software so um dass zwei oder ein Pin frei sind und nutze den 12MHz Takt. Da das bei 3.3V läuft könntest du vielleicht auch die Spannung auf 3.3V stellen. Du versuchst weiter bei der Software obwohl der Fehler woanders liegt.
Birgit Pie schrieb: > Ich habe mal nach "usbDeviceDisconnect();" und vor "for(i=0;i<20;i++)" > ein LED_TOGGLE eingefügt. Wenn man diese dann mit dem Osci beobachtet, > sieht man das der Pin ständig toggelt. Also wird anscheinend ständig ein > Reset ausgeführt...aber warum? Auf welchem Pegel liegt denn der Reset-Pin? Ist die Spannungsversorung stabil, oder cycled der PC diese beim hochfahren? Kannst Du den Watchdog auch einfach ausbauen?
Birgit Pie schrieb: > Also wird anscheinend ständig ein Reset ausgeführt...aber warum? Nun, wir können da nur in die Glaskugel schauen, während Du alle Möglichkeiten hast das herauszubekommen. ;-) Auch der Tiny selbst kann Dir dabei helfen: Siehe MCU Status Register (MCUSR). Möglichkeiten gibt es sooo viele ... ich tippe ja eher auf Softwarefehler, da die Schaltung beim normalen Anstecken an den Bus ja funktioniert. Man kann den RC-Oszillator auch so übel oder so schnell verstimmen, dass die CPU des Tiny hängen bleibt und dann vom Watchdog resettet werden muss. (siehe Oscillator Calibration Register (OSCCAL) aus dem Tiny45 Datenblatt) Tim schrieb: > Ist die Spannungsversorung stabil, oder cycled der PC diese > beim hochfahren? Embedded Hosts machen sowas manchmal um ein vollkommen abgestürztes USB-Device wiederzubeleben, aber bei einem PC habe ich sowas noch nie gesehen. Nachmessen schadet aber nie und ein Scope ist ja auch vorhanden.
Mich überrascht, wie groß der Anteil der "Herumprobierer" hier ist. Ich finde es nicht zielgerichtet bei einem Problem einfach mal die Schaltung zu verändern, ohne das Problem vorher analysiert zu haben.
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.