Hallo, ich habe drei Geräte (2x Atmega8 und 1xAttiny) in meinem VDR. Den Attiny will ich gerade "umbauen". Nun musste ich feststellen, dass sowohl das Originalprojekt als auch mein Projekt ein Problem hat. Nach einem Neustart wird das Gerät nicht mehr erkannt. Ich vermute einen Firmware-Fehler. Was wird denn bei einem Neustart benötigt? Wird irgendwie das USB-Device neu initialisiert, wenn keine Kommunikation stattfindet? Da muss es ja Richtlinien geben... Gruß, Sven
Ich sehe exakt 0.0 Sinn in der Frage. Auch wenn ich manchmal ziemlich begriffsstutzig bin, gehe ich mal davon aus, daß es nicht nur an meiner Blödheit liegt. Was um alles in der Welt willst du eigentlich wissen?
Ist ÜSB eine türkische Variante von USB? Ich glaube du solltest deine Frage etwas anders formulieren. Oder einfach mehr Infos geben.
Na es steht doch genau da, was ich will: Problem: Nach einem Warmstart wird das Device nicht mehr erkannt. Wieso? Da es mit zwei anderen Projekten geht, müssen die es ja anders machen, die Frage ist also: was?
Sven Z. schrieb: > Problem: Nach einem Warmstart wird das Device nicht mehr erkannt. Wieso? Aufgrund der hochpräzisen Beschreibung denke ich den Fehler auf die Devicenummer 42 eingegrenzen zu können. Hier verursacht die Zeile 666 den Fehler.
Oh man, solche Kommentare könnt Ihr Euch echt sparen. Es geht mir einfach nur darum, dass es eine Richtlinie geben muss, wie ein USB-Device sich zu Verhalten hat, damit es erkannt wird. Ist das denn so schwer zu verstehen?
@ Sven Z. (treito) >Es geht mir einfach nur darum, dass es eine Richtlinie geben muss, wie >ein USB-Device sich zu Verhalten hat, damit es erkannt wird. Sicher, in der USB Spezifikation. > Ist das denn so schwer zu verstehen? Ja. Denn du brabbelst Kauderwelsch in deinen Bart. http://www.mikrocontroller.net/articles/Netiquette#Klare_Beschreibung_des_Problems
Mir geht es ja gerade um diese Richtlinie! Es wird doch sicher iirgendjemand geben, der mir mit einem Satz sagen kann, was das Device machen muss, damit es erkannt wird. 2. Wenn Du schon die Netiquette ansprichst: Die Kommentare hier sind unter aller Sau und bestimmt nicht im Einklang mit selbiger!
Sven Z. schrieb: > wie > ein USB-Device sich zu Verhalten hat, damit es erkannt wird Klar, bei USB gibts ja auch nur eine mögliche Art von Device... Ist ungefähr so, als wenn du bei der Auskunft anruftst und die "Nummer von Herrn Müller" wissen willst. Da gibts auch nur eine Möglichkeit...
Die Art müsste doch eigentlich egal sein, das Device muss doch irgendwie sowas sagen wie "Hallo, da bin ich!" Es handelt sich konkret um einen USB-IR-Empfänger. Ein LCD-Display und ein "USB-Joystick" melden sich problemlos an.
Kauf dir die USB Spezifikationen, da steht das alles und noch viel mehr drin.
Es gibt ja einen PC seitigen USB Debugger, damit kann man die Meldungen des Devices an den PC verfolgen. Was kommt denn da ? Und was sollte denn da kommen ?
@Bernd Gerade solche Kommentare könnt Ihr Euch echt sparen. Das soll ein Opensource-Projekt werden. @Oktal Kennst Du so einen? Das Device taucht bei lsusb (Linux) nicht auf.
...lass Dich nicht von Kindern ärgern. Sieht aus, als wenn Dein Problem daher kommt, dass es die Initialisierung beim Warmstart nicht nochmal durchläuft. Wie verhält es sich denn wenn Du es abziehst und wieder anschließt? Gibt es Quellcode?
Endlich mal ein vernünftiger Kommentar: Quellcode wäre hier: http://www.xs4all.nl/~dicks/avr/usbtiny/ Konkret der IR-Teil. Ich bin noch Anfänger in Sachen USB. Da für mein Projekt der Attiny2313 zu wenig Speicher hatte, wollte ich das Projekt auf einen Atmega8 umschreiben, aber da gab es keine Kommunikation. Also habe ich das auf einen Attiny44 umgebaut. Ich könnte notfalls versuchen, den USB-Krams von einem anderen Projekt zu nehmen, aber einfacher wäre es natürlich, das Problem zu beseitigen. Wie wird denn so eine Initialisierung bei einem Warmstart normalerweise getriggert? Neu anstöpseln klappt im Übrigen, genauso wie ein Kaltstart (Spannung wird getrennt).
Sven Z. schrieb: > das Originalprojekt als auch > mein Projekt Welches Originalprojekt? Meinst du InfraHID von hier http://obdev.at/products/vusb/prjall.html ? Du weißt hoffentlich, dass selbst in der Dokumentation des V-USB-Treibers steht, dass er "somehow beyond the spec" geht. Das muss nicht heißen, dass das auf allen Betriebssystemen an allen Rechnern sicher laufen muss. Wie sieht jeweils die Resetbeschaltung aus? mfg mf PS: war zu langsam, aber dein Projekt setzt ja laut deines Links auch auf dem obdev.at-Kram auf. Also bleibt es bei meiner zweiten Aussage und den Fragen.
USB Debuggen... Gurgell weiss Rat. zB. http://www.computer-solutions.co.uk/info/Embedded_tutorials/usb_tutorial.htm http://www.totalphase.com/solutions/wp/debugging_usb/ http://www.downloadatlas.com/software-web-programming-debugging/usb_protocol_analyzer/rank.html insgesammt hat's 600k Meldungen unter "debugging USB protocol" Ich hab'n Kollegen, der schon ein halbes Jahr debuggt. Das Problem ist das zusammensuchen der Unterlagen. Herauszufinden wie's denn sein sollte.
Naja die Beschaltung des Resets ist jeweils mit einem 10k an +5V. Das hatte ich abgeändert, da man beim Originalprojekt so nicht flashen kann ohne dass es einen kurzen gibt. Aber das LCD2USB-Projekt verwendet die gleiche Resetschaltung. Und na klasse, den obdev-Kram wollte ich notfalls als "Hintertür" nehmen, aber da soll es ggf. auch Neuerungen geben. Mein "Joystick" (eigentlich sind es Tasten) setzt aber auch auf den obdev-Krams auf und der geht!
Oktal Oschi schrieb: > Ich hab'n Kollegen, der schon ein halbes Jahr debuggt. Das Problem ist > das zusammensuchen der Unterlagen. Herauszufinden wie's denn sein > sollte. Also "intuitiv" würde ich sagen: Wenn das Device was sendet und der PC nicht antwortet, dann Initialisierungscode senden, bis der PC antwortet. Also wird mir wohl nichts anderes übrig bleiben, als das LCD2USB-Projekt und das usbtiny-Projekt zu nehmen und zu vergleichen?! Dann kann ich auch den Attiny durch einen Atmega8 ersetzen und den LCD2USB-USB-Code quasi übernehmen. Das hätte den Vorteil, dass man die Teile bei einem Laden bestellen kann, ansonsten wird es schwierig.
Die ganzen VUSB-Geschichten sind halt nicht 100% USB2.0 konform. So richtig versteh ich dein Problem nicht, da du offenbar selber keine bis wenig Ahnung von USB hast. USB ist ein recht komplexes Protokoll. Vielleich hilft diese Seite bisschen weiter: http://www.sprut.de/electronic/interfaces/usb/usb.htm und die USB2.0 Spec hilft auch
Wie? Mein Problem ist ganz klar. Nach einem Warmstart ist das Device nicht da. Frage war jetzt ja, wie das normalerweise gehandhabt wird. Offentsichtlich wird bei einem Start des PC's das Device initialisiert. Kaltstart ist logisch wie das geht, aber wie erkennt das Device einen Warmstart? Wie gesagt, würde ich mal blind darauf tippen,. wenn das Device keine Antwort bekommt, dass es sich dann neu initialisieren sollte. V-USB kann eigentlich nicht Schuld haben, da der "Joystick" läuft. Evtl. eine andere Version oder aber (was ich eher vermute anhand des Source-Codes), dass das USB-Protokoll sprich die USB-Routinen anders angesprochen werden.
...hänge mal den R 1,5k von D- direkt an USB5V... Der Port schaltet vielleicht zu spät oder hat nicht die volle Spannung.
Das Problem hatte ich damals mit dem Atmega8! Der wollte gar nicht und als ich den 1,5k an +5V geschaltet habe, dann hatte ich zumindest eine teilweise, verstückelte Kommunikation gehabt. Es müsste doch eigentlich reichen, den softwaremäßig auf "Dauerplus" zu schalten, da der Kaltstart ja funktioniert, oder nicht?
Sven Z. schrieb: > 13:03 > > > > > > > > > > > Wie? Mein Problem ist ganz klar. Nein. Keine Sau weiß hier, was Du da eigentlich machst. Du schreibst nur: Geht nicht. Wie meldet sich ein USB-Gerät an. Wunder Dich nicht, wenn Dich dann hier keiner ernst nimmt. Du nennst keine Details zum Projekt, zu Sourcen oder Schaltplänen. So what?
Die Sourcen und der Schaltplan sind angegeben, das Problem ist klar definiert! Und klar frage ich, wie die USB-Spec ist! Aber egal, stiller Beobachter versteht mich und ich habe gerade was interessantes gefunden:
1 | // check for USB bus reset
|
2 | for ( i = 10; i > 0 && ! (USB_IN & USB_MASK_DMINUS); i-- ) |
3 | {
|
4 | }
|
5 | if ( i == 0 ) |
6 | { // SE0 for more than 2.5uS is a reset |
7 | new_address = 0; |
8 | }
|
Da wird das Problem sein und ich denke mal, er hat Recht damit, den Widerstand auf 5V zu ziehen, da bei den anderen beiden, funktionierenden Projekten er auf 5V hängt. Komisch, dass er etwas zum Schaltplan sagen kann, wo ich keine Sourcen angegeben habe.
Erst Sven Z. schrieb: > Die Sourcen und der Schaltplan sind angegeben, das Problem ist klar > definiert! , dann Sven Z. schrieb: > Komisch, dass er etwas zum Schaltplan sagen kann, wo ich keine Sourcen > angegeben habe. Du widersprichst Dir doch. Denkst Du wir sind bescheuert?
Das war ironisch gemeint! Wie kann er was zu den Sourcen sagen, wenn ich sie nicht angegeben hätte? Die Sourcen sind doch angegeben. Man ey, wenn Du Dich aufregst, dann brauchst Du hier doch nichts zu kommentieren, gehe einfach und gut ist! So, nun die Ernüchterung. Der Widerstand hängt per Code auf Dauerplus!
Damit Du verstehst, wie ein Aussenstehender Deine Frage versteht: "Hallo, ich habe ein uC-Project mit USB, dass ich auf einen anderen uC portieren möchte. Ich habe leider keinen blassen schimmer von dem Source-Code. Diverses an der Hardware habe ich auch planlos geändert bzw. nicht übernommen. Ich bin zu faul mich mit der Source und der USB-Spezifikation auseinander zusetzen. Deshalb meine Frage, wie meldet sich ein ÜSB-Gerät an?"
Damit ich auch Wissen vermittle, was ja die primäre Aufgabe des Forums ist, erkläre ich auch den Sinn dieses Widerstands. Er sagt Deinem Hostcontroller im PC oder dem USB Hub, welche Geschwindigkeit das (Dein) angeschlossene(s) Gerät unterstützt. Low, Full, Highspeed... Er sollte hier nicht geschalten werden da sowieso nichts anderes als LOW in Frage kommt.
@Rokko Falsch, da das Originalprojekt auch schon nicht geht! Das hat nichts mit der Portierung zu tun! Die Hardware habe ich nicht planlos geändert, sondern gezielt. Meine geänderte Schaltung verhält sich wie das Original. Und das Original ist fehlerhaft, nicht meine Änderung! Ansonsten wäre es mir ganz Recht, wenn Du Dich einfach aus dem Thread heraushalten könntest! @stiller Beobachter. Okay gut zu wissen, dann werde ich in meiner nä. Hardwarerevision den auf Dauerplus setzen.
Woran erkennt ein USB-Host dass da ein neues Gerät dran gestöpselt wurde? Woran erkennt der USB-Host, welche Geschwindigkeitsklasse das Gerät hat? Welche Funktion haben die 4 Pins, die du hoffentlich korrekt beschaltet hast? Punkte 1 und 2 werden HW-seitig ohne SW vom Device gemacht und sollte sich mit Wikipedia beantworten lassen. Die USB-Spec ist für den Einstieg wirklich nicht sehr hilfreich, zu zu komplex. Und zum dritten Punkt bist DU gefragt. Wenn es eh OpenSource werden soll, tut es doch nicht weh mal einen Schaltplan zu posten, oder? Und den OpDev-Kram steht doch auch unter der GPL,oder?
Sag mal, wie oft denn noch? DIE SOURCEN SIND OBEN GEPOSTET! Komisch, dass stiller Beobachter das sehen kann und Du nicht! Man man ey, das Gerät arbeitet auch korrekt bis zum Neustart! Von daher werde ich schon wissen, was ich da zusammengekloppt habe. Das Problem ist immer noch, dass die ORIGINALFIRMWARE einen Fehler hat und die Sourcen sind wie gesagt oben zu finden!
Ja ist doch wahr. Naja, ggf. habe ich etwas gefunden, aber da der PC gerade aufnimmt, kann ich das Ganze nicht testen. Es gibt ein Thermometer basierend auf den Attiny44 und basierend auf USBTiny. Das Projekt habe ich schon verwendet, um die Sourcen an mein Schaltplan anzupassen, da ich den INT0 nicht verwenden kann und stattdessen einen PCINT verwende. Da ist mir schon aufgefallen, dass er etwas anderen USB-Code verwendet und ich habe bei mir was angepasst. Mal schauen. Und ich weiß nicht, was mein Schaltplan bringen soll, da das Originalprojekt betroffen ist, aber bitteschön! Beitrag "Ist der Schaltplan (Attiny44) so okay?"
Sven Z. schrieb: > Sag mal, wie oft denn noch? > DIE SOURCEN SIND OBEN GEPOSTET! Komisch, dass stiller Beobachter das > sehen kann und Du nicht! Ich sehe einen ominösen Link dem ich bestimmt nicht folgen werde. Und einen Link zum Original ObDev. Da steht aber nicht, was DEINE konkrete Version ist. Und ich habe keine Lust für dich die beiden Beispiele herauszusuchen und zu vergleichen. > Man man ey, das Gerät arbeitet auch korrekt bis zum Neustart! Von daher > werde ich schon wissen, was ich da zusammengekloppt habe. Wenn es so wäre, wäre dieser Thread überflüssig und die Re-Enumerierung würde klappen. Stattdessen gibst du keine Informationen die helfen DEIN Problem einzugrenzen. Hänge ein .zip-Archiv mit den Quellen der Problem-Firmware hier an. Und natürlich den Stromlauf. Dann sehen wir weiter. > Das Problem ist immer noch, dass die ORIGINALFIRMWARE einen Fehler hat > und die Sourcen sind wie gesagt oben zu finden! Sind das Original ObDev-Beispiele? Oder gibt es Änderungen bzw. Erweiterungen darin? Wäre auchmal Interessant zu wissen, was du mit > Der wollte gar nicht und > als ich den 1,5k an +5V geschaltet habe, dann hatte ich zumindest eine > teilweise, verstückelte Kommunikation gehabt. eigentlich meinst.
War zu langsam, seh gerade du hast einen Stromlauf gepostet. Was genau stellst du den mit PA.1 an, wenn du eine USB Re-Enumerierung anstossen willst? Zeig mal den Code, der bei der Initialisierung von USB diesen Pin bedient.
ich lese hier schon viel mit, aber 'DAS Originalprojekt' ist mir hier noch nie untergekommen. Wie kannst du davon ausgehen das jeder sofort weiss was du meinst? Der Hinweis im 17.Beitrag hätte doch etwas eher kommen können. Und der Vater vom 'Originalprojekt' scheint ja auch noch zu leben, den würde ich als erstes anmailen und fragen ob das ein bekanntes Problem ist. Allerdings in einem etwas freundlicheren Ton und in englisch... Ansonsten ist USB hier etwas einfacher beschrieben: http://www.usbmadesimple.co.uk/
Den einzigen Link, den ich gepostet habe, war der hier: http://www.xs4all.nl/~dicks/avr/usbtiny/ Und der ist sicher! Zu Obdev kam nicht von mir! Da Du aber so viel Angst hast, habe ich die Sourcen rangehangen. Da fehlt dann aber das Schaltbild. Zweitens: Bevor ich den Attiny44 auf einer geätzten Platine verwendet habe, hatte ich mal versucht, einen Atmega8 zu verwenden - auf Steckbrett. Problem war da, dass erst keine Kommunikation mit dem PC stattfand und als ich den Widerstand 1,5k an D- auf +5V geschaltet habe, hat er die USB-Kennung übertragen und dann war Ende. Darum nun der Attiny44. Mittlerweile weiß ich aber, dass es wohl Schwierigkeiten mit dem Steckbrett geben kann und die Kommunikation deswegen nicht klappen kann. Aber das ist Nebensache. Und noch ein Link: http://www.spida.net/projects/hardware/usbtiny-ir/index.de.html
JojoS schrieb: > ich lese hier schon viel mit, aber 'DAS Originalprojekt' ist mir hier > noch nie untergekommen. Wie kannst du davon ausgehen das jeder sofort > weiss was du meinst? Der Hinweis im 17.Beitrag hätte doch etwas eher > kommen können. Und der Vater vom 'Originalprojekt' scheint ja auch noch > zu leben, den würde ich als erstes anmailen und fragen ob das ein > bekanntes Problem ist. Allerdings in einem etwas freundlicheren Ton und > in englisch... > > Ansonsten ist USB hier etwas einfacher beschrieben: > http://www.usbmadesimple.co.uk/ Sorry, wenn mein Ton unfreundlich wird, aber wenn man hier gleich von vornherein blöd angemacht wird, ist das auch kein Wunder! Mir ging es von Anfang an nicht darum, dass mir einer sagt: Da genau liegt der Fehler. Das wollte ich nicht unbedingt einen zumuten. Okay, wenn es einer freiwillig macht, umso besser. Mir ging es eigentlich nur darum, wie die USB-Spezifikationen sind; was USB normalerweise vorschreibt. Und dazu braucht man das Originalprojekt nicht, oder?
was ist bei dir der Unterschied zwischen Kalt- und Warmstart? Ich vermute das beim Kaltstart der µC auch neu gestartet damit sein USB warten initialisiert wird. Beim Warmstart bleibt am µC vermutlich die Versorgung an und er macht keinen Reset. Also kriegt er vit. nicht mit das die Verbindung weg war. Da USB recht komplex ist wird der Autor wohl einges weggelassen haben was man eigentlich machen müsste.
Eigentlich ist Kalt- und Warmstart kalr definiert. Beim Warmstart wird der PC nicht ausgeschaltet sondern nur nue gestartet. Beim Kaltstart wird der PC von der Spannung getrennt, also Netzteil aus (idealerweise sogar Netzschalter aus) und dann neu eingeschaltet. Das Originalprojekt wird mit ausgeschaltet, das hängt bei mir an einem internen Hub, der nur (!) über das PC-Netzteil mit SPannung versorgt wird, den 5V-Pin vom USB-Header habe ich abgeklemmt. Folglich wird auch der µC von der Spannung getrennt, was aber später bei meinem Umbau nicht mehr passieren soll und dann habe ich wirklich die A-Karte gezogen. Dann kann ich den PC per FB einschalten, aber nicht bedienen - super! Naja, ich probiere nachher mal meine Codeänderung, evtl. war es das schon. Aber ich glaube, das wäre zu simpel!
Wie schon mehrfach erwähnt wurde ist der größte Unterschied beim Warmstart dass die Schaltung nicht spannungslos ist, d.h. auch am Pull-Up an D- keine "Wackeln" auftritt. Das "Wackeln" benutzt aber der Host um zu erkennen dass da ein neues Device dran hängt. Wie sollte es auch anders funktionieren? Bei USB geht die Kommunikation IMMER vom Host aus und der Slave antwortet. Solange der Pull-Up am D- hängt ist das Device da, wenn er (lange genug) auf Low geht ist das Device weg. Ein paar Zeilen im "USB in a Nutshell" lesen oder gurgeln hätten das geklärt. Stattdessen pflegt Sven einen aggressiven Ton und weigert sich beharrlich sich mit USB zu beschäftigen. Trial and Error Fehlersuche anstatt sich mit den Grundlagen der USB-Enumerierung zu beschäftigen. Und dass er es nicht geschafft hat, die mehrfach angefragten Stellen im Code mal zu posten und anscheinend davon ausgeht dass alle die Helfen wollen sich durch den Wust von Code zu quälen ist schon unverschämt. Ich bin dann mal weg hier...
Ach ist das wieder herrlich, man wechselt zur 3. Person, das zeugt von wirklicher Reife! Die Frage war ganz klar an Spezis gerichtet. Und das mit dem Pullup kann auch nicht sein, da ich 2 Projekte habe, die funktionieren und oh Wunder der Pullup hängt fest an +5V. Ach egal, was rege ich mich auf, ignorieren ist wohl das Beste.
So, das Problem ist gelöst. Dank dürft Ihr nicht erwarten, man wird hier ja nur blöd angemacht. Einzig Dank an stiller Beobachter, der mir wirklich konkrete Aussagen gegeben hat und Dank auch an JojoS für die anfänglichen Bemühungen.
> So, das Problem ist gelöst.
Gratulation, und worin bestand es genau?
Da, wo ich es vermutet hatte
1 | // check for USB bus reset
|
2 | for ( i = 10; i > 0 && ! (USB_IN & USB_MASK_DMINUS); i-- ) |
3 | {
|
4 | }
|
5 | if ( i == 0 ) |
6 | { // SE0 for more than 2.5uS is a reset |
7 | new_address = 0; |
8 | }
|
Da fehlte noch eine Zeile.
Hallo Sven, ich hatte das gleiche Problem mit dem USB wie Du mit dem selben Lösungsweg, und kann Dir sagen das Dein Problem nicht gelöst ist! Momentan funktioniert es zwar, wird aber auf kurz oder lang wieder abschmieren!
Hallo Alex, das Ganze werde ich noch einem Dauertest unterziehen, aber in der Regel erfolgt ja nicht so oft ein Warmstart. Es wäre allerdings ärgerlich, wenn es nicht klappen sollte. Da aber andere Projekte bei mir anstandslos ihren Dienst machen, bin ich doch zuversichtlich.
stiller Beobachter schrieb: > Er sagt Deinem Hostcontroller im PC oder dem USB Hub, welche > Geschwindigkeit das (Dein) angeschlossene(s) Gerät unterstützt. Low, > Full, Highspeed... > > Er sollte hier nicht geschalten werden da sowieso nichts anderes als LOW > in Frage kommt. Der geschaltete Pullup (den Dick Striefland vor ein paar Jahren auf meinen Vorschlag in USBtiny eingebaut hat) dient hier nicht der Umschaltung der Geschwindigkeit. Er sorgt dafür, daß der Controller sich nach einem Reset (z.B. wenn es per ISP neu programmiert wird) automatisch ab- und nach der Initalisierung wieder ansteckt. Vorher war der Widerstand auch bei USBtiny fest auf VCC, was zur Folge hatte, daß man den Controller nach jedem Flashen manuell ab- und wieder anstecken mußte. @Sven: Schön, daß sich einer einen Reim auf Deine Beschreibung machen und Dir helfen konnte, aber sie wirkte am Anfang auch oder gerade für Leute, die sich mit der Materie auskennen wirklich sehr konfus. Beispielsweise war mir beim Durchlesen des Threads lange nicht klar, ob Du einen Warmstart des PC oder des AVR meinst, denn ich hatte wie oben beschrieben den Pullup genau deshalb schaltbar gemacht, damit das Device sich nach einem Warmstart des Controllers wieder sauber am Host anmeldet.
Naja, man muss das ja auch mal aus meiner Sicht sehen. Ich kenne mich mit USB nicht aus. Ich habe mir nun vorgenommen, die Schaltung zu erweitern (und den LCD-Krams zu entsorgen). Dann muss ich auf einmal feststellen, dass meine derzeitige Schaltung, fast nach Dick Striefland (nur, dass ich den ISP ergänzt und darum auch den Reset angepasst habe) gebaut, nicht richtig läuft. Und das genau im USB-Teil. Das war eigentlich der Grund, warum ich einen Attiny44 genommen habe, da ich beim Atmega8 in Versuchen starke Schwierigkeiten mit der Übertragung hatte und der Pullup-Widerstand nur zu Störungen führte. Erst kürzlich habe ich hier in einem anderen Thread gelesen, dass sich wohl Steckboards nicht für USB eignen. Naja egal, der Tiny ist da und wird nun genommen, die Platine ist schön geätzt. Ich wollte ja auch gar nicht wissen, zumindest anfänglich nicht, was genau am Code falsch ist. Ich wollte lediglich wissen, was die USB-Spezifikation darüber aussagt, wie ein Gerät zu verfahren hat, wenn der PC (!) einen Warmstart ausführt. Das man aber gleich hier niedergemacht wird, nur weil man sich nicht 100% so ausdrückt, wie es die Spezialisten machen würden oder aber man nicht genau weiß, wie man sich ausdrücken soll, das finde ich unter aller Sau. Sowas ist Kindergartenniveau und zeugt nicht von Reife. Man könnte vernünftig nachfragen und muss einen hier nicht gleich niederputzen. Und wenn man der Meinung ist, dass man undeutlich gefragt hat und die Nachfrage ist keinen deut besser - dazu fällt mir nun wirklich nichts mehr ein. Okay, BTT. Wenn Du sagst, dass Du genau deswegen vorgeschlagen hast den Widerstand auf einen Pin zu geben, dann werde ich das auch beibehalten - nur habe ich keine Stelle im Code gefunden, wo der Widerstand wieder abgeschaltet wird. Naja, ich werde das noch mal überprüfen, aber bislang konnte ich nur feststellen, dass der Pullup quasi ein paar Zyklen später erst aktiviert wird, wenn Sapnnung anliegt. Aber, wenn der Widerstand quasi mit zur Erkennung dient und er schon auf einem Pin liegt, dann mache ich mir das zu nutzen - sprich wenn der PC aus ist, dann kann ich den Widerstand auch ausschalten. Gruß, Sven Edit: Und wenn ich sage, Originalschaltung, dann meine ich auch, dass bei mir derzeitig noch ein Attiny2313 werkelt...
Sven Z. schrieb: > Man könnte vernünftig nachfragen und muss einen hier nicht gleich > niederputzen. Manche hier sind leider so (nur als Erklärung, nicht zu deren Verteidigung). > Wenn Du sagst, dass Du genau deswegen vorgeschlagen hast den > Widerstand auf einen Pin zu geben, dann werde ich das auch beibehalten - Wie gesagt hatte ich den umgekehrten Fall im Blick: Reset des Controllers, während der Host weiterläuft. > nur habe ich keine Stelle im Code gefunden, wo der Widerstand wieder > abgeschaltet wird. Abgeschaltet wird er beim hardwaremäßigen Reset des Controllers, deshalb findest Du davon nichts im Code. > Naja, ich werde das noch mal überprüfen, aber bislang konnte ich nur > feststellen, dass der Pullup quasi ein paar Zyklen später > erst aktiviert wird, wenn Sapnnung anliegt. Der Pullup wird genau dann eingeschaltet, wenn der Controller seine Firmware soweit initialisiert hat, daß er vom Host per USB angesprochen werden kann. Diese Änderung (gegenüber Pullup fest auf VCC) hat bei mir damals soweit ich mich erinnere auch die Erkennung durch den Host nach dem Anstecken wesentlich stabiler gemacht, weil der Host nicht mehr versucht, mit dem Controller zu reden, solange der noch gar nicht soweit ist. > sprich wenn der PC aus ist, dann kann ich den Widerstand auch > ausschalten. An der Stelle hast Du mich jetzt wieder abgehängt. Schreib' bitte nochmal mit anderen Worten und etwas ausführlicher, was Du damit sagen willst.
Sven Z. schrieb: > Mittlerweile weiß ich aber, dass es wohl Schwierigkeiten mit dem > Steckbrett geben kann und die Kommunikation deswegen nicht klappen kann. > Aber das ist Nebensache. Also ich hatte noch nie Probleme auf dem Steckbrett mit V-USB. Lief bisher immer alles bestens. Selbst mit meterlangem Kupferlackdraht (das ist natürlich mehr als übertrieben) lief alles problemlos auf Lochraster. Die Sensibilität von V-USB wird meines Erachtens (ein Paar Experimente) überbewertet. Gruß Skriptkiddy
Sven schrieb: > aber bislang > konnte ich nur feststellen, dass der Pullup quasi ein paar Zyklen später > erst aktiviert wird, wenn Sapnnung anliegt. Aber, wenn der Widerstand > quasi mit zur Erkennung dient und er schon auf einem Pin liegt, dann > mache ich mir das zu nutzen - sprich wenn der PC aus ist, dann kann ich > den Widerstand auch ausschalten. Der R. Max sagte: Das mit dem Widerstand dient nur der Neuerkennung nach einem Flashen der Firmware. Wenn Du jetzt eine längere Initphase hast kann das zu lange sein bis der Widerstand dranhängt. Was weiß ich, wegen LCD ... Variante 1: Klemme ihn direkt, fertig. Variante 2: Widerstand splitten in 1k und 470R 470R an USB+ 1k an D- Knoten (1k+470R) an AVR Ausgang zum Neustart nach Flashen. Gute Nacht...
Prüfe lieber ob Du den zeitkritischen Init irgendwo behinderst. Also LCD-Init oder was auch immer - nicht am Anfang machen.
Schaltungswächter schrieb: > Wenn Du jetzt eine längere Initphase hast kann das zu lange sein bis der > Widerstand dranhängt. Der Host erkennt doch erst duch das Aufschalten des Pullups, daß ein Device angeschlossen wurde, und ab dem Moment wird es zeitkritisch. Davor hast Du alle Zeit der Welt, die verschiedenen Programmteile zu initialisieren, denn der Host "weiß" ja noch nicht, daß Du da bist. > Prüfe lieber ob Du den zeitkritischen Init irgendwo behinderst. > Also LCD-Init oder was auch immer - nicht am Anfang machen. Nein, genau umgekehrt: zunächst alles initialisieren, was die zeitkritische USB-Kommunikation stören könnte (oder was seinerseits im Timing durch USB gestört werden könnte) und erst danch durch Einschalten des Pullups den Host von der eigenen Existenz in Kenntnis setzen.
Hallo, danke für die Antworten. Mein Problem ist nun folgendes: Die Originalschaltung hängt an einem USB-Hub und wenn der PC aus ist, wird dieser auch abgeschaltet. Steht oben auch mal irgendwo. Mein Umbau (ohne LCD!) wird allerdings dauerhaft an 5V bleiben und ich wollte dann, wenn der PC ausgeschaltet ist (messe ich mit den 5V vom Netzteil) die USB-Kommunikation killen und den Tiny quasi in einen anderen Modus versetzen (programmtechnisch). Wird dann der PC eingeschaltet (händisch, ACPI-Timer oder über den Tiny) wollte ich den Modus wieder umschalten auf USBTiny. Im Attiny44 sollen quasi zwei verschiedene Programme ablaufen. Und ich denke mal, dann wird es besser sein, den Widerstand zu schalten. Naja, ich werde es ausprobieren. Ich habe einen geätzten Prototypen und da werde ich sehen, was passiert, wenn ich den Widerstand schalte. Gruß, Sven
Hier lernt man noch richtig was. Danke. Zwecks Abschaltung: vielleicht bei Null USB Aktivität in "Standby" gehen, also abschalten. Was Macht denn die VUSB Software bei PowerEvents? Wird darauf reagiert?
Ich kann ja nicht in den Standby gehen, da der Controller den PC wieder einschalten soll. Das geht schlecht, wenn der ein Nickerchen macht...
Hallo,
interessante Diskussion :).
@Sven: Dein Controller, der über USB an einem HUB, welcher wiederum am
PC angeschlossen ist, soll Deinen PC einschalten können?
Da stellt sich mir die Frage, wie Du Dir das vorstellst? Ich dachte
immer, wenn der PC ausgeschaltet ist, dann kann man auch die
angeschlossenen USB-Geräte nicht verwenden? Hmm...
Wie Schaltungswächter schon schrieb:
>Hier lernt man noch richtig was. Danke.
Gruß Georg
Nein nicht ganz. Der Hub ist tot, sobald der PC aus ist. Die Schaltung kommt direkt an den USB Header. Die meisten PCs (nicht Notebooks), die mir untergekommen sind, führen nach dem Ausschalten des Rechners noch Spannung. Ich spreche hier vom normalen Herunterfahren, nicht Ausschalten per Netzteil. Da ja auch ein, wie heißt das Ding? Floppy-Stecker? HDD-Stecker? Da ja auch ein Laufwerksstromversorgungsstecker mit angeschlossen ist, wird der µC daran erkennen (dank Pulldown-Widerstand), dass der PC aus ist und den Modus umschalten. Es gibt ähnliche Schaltungen, aber die benötigen 2µC (Attiny2313 und Attiny13). Im Ausgeschalteten Zustand des PC's findet keine Kommunikation statt mit dem PC, soviel möchte ich mal klarstellen, aber die USB-Spannung ist da. Und wehe einer fragt, wie man denn ohne Kommunikation den PC einschalten will! Da würde ich schlichtweg antworten: Relais parallel zum Einschalter wäre eine Möglichkeit, wenn auch nicht meine!
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.