Hallo zusammen, ich kämpfe gerade gegen ein merkwürdiges Problem: Die CPU läuft stunden- und tagelang durch und meldet brav via GPIO und UART ihre Ergebnisse. Nebenbei bedient sie noch ein paar LEDs. Und nach einer gewissen Zeit hört die GPIO- und UART-Aktivität einfach auf, aber die LEDs funktionieren weiter (hängen an einem anderen Port). Zunächst dachte ich, mir wird mein DDRD überschrieben, so dass die UART nicht mehr senden kann. Also habe ich versucht, regelmäßig DDRD, Bit 1 wieder so zu setzen, damit die UART senden kann. Das hat nicht geholfen. Jetzt initialisiere ich den gesamten UART und DDRD in regelmäßigen Abständen neu und nun kommen auch weiterhin Ausgaben über diesen Tot-Punkt hinweg via UART. Die GPIO Aktivität ist aber trotzdem tot. Die LED-Aktivität zeigt aber ein noch brav laufendes Hauptprogramm an. Was ich nun via UART-Daten sehe, ist irgendwie ein "etwas" zurückgesetzter Atmega8. Die Software wurde offenbar nicht zurückgesetzt. Aber: Einige Daten im RAM-Speicher (die ich mir regelmäßig per UART ausgeben lasse) sind kaputt und offensichtlich funktioniert auch der einmal aufgesetzte Interrupt an Port D nicht mehr (weshalb die GPIO-Aktivität zum Erliegen kommt). Es scheint zunächst auch nur Port D zu erwischen, wobei dort auch die Signale von/zum anderen Rechner dran hängen. Das würde evtl. den Hinweis von jemanden anderen erhärten, der Atmega hätte große Probleme mit EMV. Ist so etwas auch anderen bekannt? Ich bin nun dabei, das Leiterkarten-Layout neu zu gestalten. Bisher waren bereits Anschlüsse für Schirme der beiden Signalkabel vorgesehen, die evtl. auftretende Störungen am Rand der Leiterkarte führen sollten. Das alleine scheint aber nicht zu helfen. Und ja, ich habe den Kardinal-Fehler begangen, auf beiden Leiterkartenenden Kabel vorzusehen, mit der CPU in der Mitte. Alles an sonstigen Signal-Störungen muss also durch die CPU durch (trotz Schirm, oder vielleicht wegen?). Für mich stellt sich nun die Frage, wie weit ich dabei gehen muss: Müssen gleich Optokoppler her? Oder reicht vielleicht auch eine sternförmige Verdrahtung, so dass die Leiterkarte immer eine Sackgasse für etwaige Störungen ist? Kann jemand die Empfindlichkeit des Atmega beurteilen? Gruß Jürgen
Einen Softwarefehler kannst du ausschließen (Stacküberlauf, nicht initialisierter Pointer, ein Arrayzugriff außerhalb des Arrays usw.)? Falls der AVR mit externem Quarz >8MHz läuft: CKOPT gesetzt?
Wie sieht denn dein Aufbau aus ? Wo ist Dein Code ? Geh doch Systematisch vor und nicht Symptomatisch ! Du musst wissen ob die Schuld bei der Hard- oder der Software liegt. Da Du die Hardware (MCU) nicht "testen" kannst, bleibt Dir nur noch die Softwar ezu verifizieren. Wie wäre es mit JTAG ? Wenn Du da nicht weiter kommst, würde ich alle Teilsysteme an sich "prüfen". Sprich -gut- Testen. Wenn alle Teilsysteme an sich funktionieren, kann nur noch deren zusammenwirken zum Ausfall führen... Weischt ?
Hallo, vielleicht auch nur den Fehler eingrenzen, den es in der Software gibt und der beim Zusammentreffen bestimmter Bedingungen (Race Condition genannt) z.B. den Stack oder ein paar Variablen zerlegt? Ich will damit Störungen nicht generell ausschließen, aber die erzeugen selten bei wiederholtem Auftreten ähliche Fehlerbilder behaupte ich jetzt mal. Gruß aus Berlin Michael
Benedikt K. schrieb: > Einen Softwarefehler kannst du ausschließen (Stacküberlauf, nicht > initialisierter Pointer, ein Arrayzugriff außerhalb des Arrays usw.)? Naja, einen Fehler kann man nie ausschließen. Darum ist der Aufbau der Software auf meiner Seite auch so einfach wie möglich. Einfach eine doofe Schleife, die für alle Zeiten ihre Kreise dreht, Flags abfragt und daraufhin Speicherzellen füllt. Allerdings benutze ich eine externe Bibliothek (v-usb von obdev.at = Software USB) über die ich wenig sagen kann. Und es ist der USB-Host, der mein System irgendwann nicht mehr erreichen kann, das System an sich arbeitet aber noch (d.h. die Schleife dreht noch, dafür habe ich bestimmte Blink-Muster in den LEDs programmiert). > Falls der AVR mit externem Quarz >8MHz läuft: CKOPT gesetzt? Ja, 12 MHz. Und: Ja, CKOPT gesetzt. Diese Dinge habe ich jetzt mehrfach durchgeprüft (was aber bekanntlich nichts zu heißen hat... ;-) ) Das AHA-Erlebnis habe ich vergessen zu schreiben: Vor kurzen habe ich an meiner Schaltung gearbeitet und draußen zog ein Gewitter auf. Es blitzte einmal und plong war meine Schaltung weg (nur der USB, nicht die UART). Eigentlich habe ich eine schöne Antenne gebaut: +----+ USB +--------+ 3m geschirmt +----------+ | PC |-------------|ATMEGA8 |--------------------| DCF Empf.| +----+ geschirmt +--------+ +----------+ Daher habe ich mich im Moment an der EMV-Idee verbissen. Jürgen
Kannst Du die "aussetzer" an irgendwas festmachen ? z.b. Neonröhre an,aus,an,aus machen ? Schaltung mit dem Handy abgehen ? .... Wie hast Du die Schirmung aufgelegt ? Wie sieht Deine Masseführung aus ? Gibt es eine Schutzerde an dem Gehäuse ? Fliegender Aufbau ?
? ? schrieb: > Wie sieht denn dein Aufbau aus ? > Wo ist Dein Code ? Willst Du den wirklich haben? Ich habe nichts dagegen, allerdings kann man da nicht "mal eben" drüberschauen. > Geh doch Systematisch vor und nicht Symptomatisch ! > Du musst wissen ob die Schuld bei der Hard- oder der Software liegt. Das versuche ich jetzt bereits seit 6 Wochen herauszufinden. Keine Ahnung wieviel Tests ich nun schon hinter mir habe. Aber alle bisherigen Vermutungen haben sich nicht bestätigt. Allerdings ist eine Fehlerrate von etwa 1..3 Tagen auch gar nicht so einfach in den Griff zu bekommen. Wenn etwas raucht beim Einschalten, wäre mir das viel lieber. Andererseits gehen mir langsam die Ideen aus, was ich noch prüfen kann. Das Problem sind die erforderlichen Langzeitmessungen. Mal eben ein Oszi dranhängen, richtige Triggerbedingung einstellen, es macht ping schon hat man ein Ergebnis ist hier leider nicht. > Da Du die Hardware (MCU) nicht "testen" kannst, bleibt Dir nur noch die > Softwar ezu verifizieren. > > Wie wäre es mit JTAG ? Ich habe hier nur einen ISP und avrdude kann keine post-mortem-Analyse (zumindest habe ich es noch nicht rausgefunden), sondern setzt die CPU zurück und damit ist habe ich das System verändert, während ich reingucke. > Wenn Du da nicht weiter kommst, > würde ich alle Teilsysteme an sich "prüfen". > Sprich -gut- Testen. Ich habe hier noch drei andere Karten, auch mit Atmega 8 und der Software-USB-Anbindung. Allerdings andere Aufgaben und somit anderer physikalischer Aufbau (und natürlich andere Firmware). Und geringerer Datenverkehr auf dem USB, und, und, und. Man denkt immer nur vorher, es ist eh alles das gleiche, wird schon gehen... > Wenn alle Teilsysteme an sich funktionieren, kann nur noch deren > zusammenwirken zum Ausfall führen... Ich gehe davon aus, dass die Firmware einfach genug ist, Jahre im Kreis laufen zu können, ohne über die eigenen Füße zu stolpern. An der Hardware ist ebenfalls nix spektakuläres. Was ich mal zwischendrin gemerkt habe (nach dem Blitz): Ich hatte zunächst ein falsches Kabel in Richtung DCF-Empfänger. Falsch weil: Zu wenig Adern. Daher hatte ich (ja, ich schäme mich auch dafür :-) ) den Schirm als Signal-Masse benutzt. In der Folge hing meine Schaltung in diesem merkwürdigen Zustand etwa einmal am Tag. Jetzt habe ich mir das richtige Kabel besorgt, also nun kann der Schirm wirklich seine Aufgabe erfüllen. Signal-Masse wird nun im Kabel geführt. Und siehe da: Jetzt dauert es reproduzierbar mindestens 3 Tage, bis sich meine Schaltung vom USB verabschiedet. Und die Firmware habe ich zwischenzeitig nicht verändert. Dieser Zusammenhang ist derzeit reproduzierbar. Alle anderen Vermutungen und Versuche waren irgendwie immer Sackgassen. Gruß Jürgen
Ich kenne sowas... ;) Weil Du dich schon recht festgelegt hast, meine Frage wie Du die Masse führst... Z.b. hat es sich bei mir bewährt den Schirm mit ein paar pF auf die Masse zu legen. Die Leitungsenden auf eine passende art und weise abzuschliessen. (reihenR, kleinesC, hochohmiger Spannungsteiler) Irgendwo hier im Forum habe ich mal einen Link gefunden, dort wurde auf die ganze EMV-Problematik eingegangen. Dinge wie Anschlüsse alle auf eine Seite (Pot.senke) usw. Nur blöd, wenn es dann doch an der Software lag. Hast Du deinen Source schon von jemand anderem gegenschauen lassen ???
? ? schrieb: > Kannst Du die "aussetzer" an irgendwas festmachen ? > > z.b. Neonröhre an,aus,an,aus machen ? > Schaltung mit dem Handy abgehen ? > .... Das einzige, was ich direkt mitbekommen habe ist der Blitz während eines Gewitters, als ich am Messen war. Alles andere kann ich an nichts festmachen, weil es zu (meiner Meinung nach) beliebigen Zeiten passiert. Mal am Tag, mal Nachts usw. > Wie hast Du die Schirmung aufgelegt ? Kommt rein über das USB-Kabel als dessen Schirm, liegt dann als Ring um meine Leiterkarte, und setzt sich im Kabel-Schirm bis zum DCF-Empfänger fort. > Wie sieht Deine Masseführung aus ? Masse und Versorgung kommen im USB-Kabel bis zur Schaltung. Dort habe ich - trotz nur zwei Lagen - die beiden Seiten geflutet, so dass ich großzügige Fläche für Masse und VCC habe. Auf der anderen Seite der Leiterkarte sind dann die Litzen für die Versorgung des DCF-Empfängers ebenfalls an diesen Masse- und VCC-Flächen angeschlossen. Hier sehe ich derzeit ein mögliches Problem: Denn alles was sich der DCF-Empfänger einfängt, oder per kapazitiver Kopplung in die Adern des DCF-Kabels einstrahlt muss komplett durch die Leiterkarte. Und in deren Zentrum liegt der Atmega8. Hier hatte ich vor, das Layout so zu ändern, dass die Versorgung des DCF-Empfängers ebenfalls am Eingang des USB-Kabels abgegriffen wird. Allerdings ist das nur eine "verzweifelter" Versuch. > Gibt es eine Schutzerde an dem Gehäuse ? Kunststoff-Gehäuse. Nirgends Blech. > Fliegender Aufbau ? Nein. Ordentliches USB-Kabel (einer USB-Maus entrissen), richtige zweiseitige Leiterkarte (nicht selber geätzt) und noch ein USB-Kabel, wegen des Schirms und den 4 inneren Litzen zum DCF-Empfänger. Gruß Jürgen
Wenn du deiner Software so vertraust, dann kann es eigentlich nur noch die Hardwarae sein. Poste mal den Schaltplan und evtl. auch das Layout. Schreib was zur Spannungsversorgung (Schaltnetzteil, über 2m angeschlossen oder was auch immer). Das Rätseln hat ansonsten kein Ende. Gruß, Christian
? ? schrieb: > Ich kenne sowas... ;) > > Weil Du dich schon recht festgelegt hast, meine Frage wie Du die Masse > führst... > > Z.b. hat es sich bei mir bewährt den Schirm mit ein paar pF auf die > Masse zu legen. Klingt wie das was Joachim Franz in seinem Buch über EMV beschreibt: Gib der Störung einen ungefährlichen Pfad, sonst sucht sie sich selber einen. Er empfiehlt ja auch, nur auf einer Kartenseite Anschlüsse vorzusehen. Damit Störungen immer auf eine Sackgasse treffen. Nunja, diesen Ratschlag habe ich missachtet. > Die Leitungsenden auf eine passende art und weise abzuschliessen. > (reihenR, kleinesC, hochohmiger Spannungsteiler) Hmm, in Richtung DCF-Empfänger habe ich praktisch Gleichstrom (1 Hz zähle ich noch dazu). Was soll man denn da abschließen? Mir fällt noch der Optokoppler ein, um das DCF-Nutzsignal zu trennen, bevor es der uP zu sehen bekommt. Seufz. Meine Schaltung besteht aus dem uP und einer Hand voll passiven Bauelementen. Eigentlich eine richtige Bagatelle. > Irgendwo hier im Forum habe ich mal einen Link gefunden, > dort wurde auf die ganze EMV-Problematik eingegangen. > Dinge wie Anschlüsse alle auf eine Seite (Pot.senke) usw. Ich such' mal danach. > Nur blöd, wenn es dann doch an der Software lag. > Hast Du deinen Source schon von jemand anderem gegenschauen lassen ??? Wer soll sich denn für meine langweiligen Programmzeilen interessieren... Gruß Jürgen
Es geht nicht darum das eine Hz abzuschliessen, vielmehr die Transienten (wie das auch immer heissen mag, HF...) abzuleiten/kurzschliessen bevor sie der µC sieht. Ich hatte mal eine Anwendung bei der ich über eine geschirmte Leitung (mehr als 5 Meter) ein paar Signal auswerten musste. (Mischmasch aus Rel.kontakten, OpenCollector und Taster) Doof, das es immer falschauslösungen gab als ich nicht da war. Da sind dann wirklich dumme Sachen passiert... Nach viel probiererei habe ich : - jeweils ein C von Signal zur Masse und einem R in den µC - die Schirmung auf das Gehäuse Gehäuse mit PE + das wiederum mit einem kleinen (somit HF-durchlässigen) C mit der Schaltungsmasse verbunden. - Masse beidseitig vom Schirm genommen. Danach war alles Super ! Leider finde ich den Link nicht mehr... Wenn Du was findest, dann bitte Posten.
Christian Gärtner schrieb: > Wenn du deiner Software so vertraust, dann kann es eigentlich nur noch > die Hardwarae sein. Poste mal den Schaltplan und evtl. auch das Layout. Anbei. Layout ist mit Eagle gemacht. Wenn das jemand nicht lesen kann, möge er mir bitte sagen, in was ich es konvertieren soll. Schaltplan als drei png-Dateien. Insgesamt übersichtlich. > Schreib was zur Spannungsversorgung (Schaltnetzteil, über 2m > angeschlossen oder was auch immer). Hmm, evtl. wäre Fremdspeisung nochmal ein Versuch wert. Derzeit wird über USB versorgt. Allerdings hängt am gleichen Root-HUB noch anderes USB-Zeugs und das stellt sich nicht so zickig an. Das USB-Kabel, was ich der Maus geklaut habe ist rund 1,5m lang. > Das Rätseln hat ansonsten kein Ende. Och, ich mach das jetzt seit Wochen. Man gewöhnt sich dran... :-( Gruß Jürgen
Ich glaube mein TFT ist kaputt. Deine PNGs kann man fast nicht lesen... Geht das nicht besser ???
? ? schrieb:
> Hört da ein HW Interrupt auf das DCF ?
Nein, nur die "Capture Unit". Und die sagt per Flag Bescheid, und das
wiederum fragt meine Endlosschleife ab. Ich habe zwei Interrupts in
meinem Programm: Das eine ist der Timer-Interrupt mit dem ich die
Referenz-Sekunde erzeuge und das andere ist der Interrupt von USB, für
den sich die V-USB-Bibliothek interessiert. Da die V-USB-Lib aber harte
Bedingungen an die Latenz stellt, ist meine Timer-Interrupt-Routine sehr
"schmal" geworden:
1 | .extern second_start_time_stamp |
2 | .extern timer_status |
3 | |
4 | .text |
5 | .global TIMER_REFERENCE_IRQ |
6 | .type TIMER_REFERENCE_IRQ, @function |
7 | |
8 | TIMER_REFERENCE_IRQ: |
9 | ; to come up to here: 7 clocks |
10 | push r24 ; 2 clock |
11 | |
12 | in r24, OCR1BL - 0x20 ; 1 clock |
13 | sts second_start_time_stamp, r24 ; 2 clocks |
14 | in r24, OCR1BH - 0x20 ; 1 clock |
15 | sts second_start_time_stamp + 1, r24 ; 2 clocks |
16 | |
17 | lds r24, timer_status ; 2 clocks |
18 | ori r24, TIMER_REFERENCE + NEW_SECOND_STARTS ; 1 clock |
19 | sts timer_status, r24 ; 2 clocks |
20 | /* |
21 | * atomic operation requirement ends here. Its possible to reenable |
22 | * the interrupts right now to avoid any interference with the USB lib |
23 | */ |
24 | cli ; 1 clock |
25 | pop r24 ; 2 clocks |
26 | reti ; to return 4 clocks |
27 | |
28 | ; sum: 27 clocks, but only 21 with interrupts disabled |
Arbeiten mit der Variable "timer_status" ist in der Endlosschleife
wiederum mit:
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
[ ...tue was mit timer_status... ]
}
geschützt. Gleiches gilt für die Auswertung der Variablen
"second_start_time_stamp". Und sie sind "volatile" deklariert, damit der
Compiler nicht auf dumme Gedanken kommt.
Gruß
Jürgen
? ? schrieb: > Ich glaube mein TFT ist kaputt. > Deine PNGs kann man fast nicht lesen... Öhh, stimmt. Wenn man es genauer sehen will, sieht man gar nix mehr. Sorry. > Geht das nicht besser ??? Ich habe es mit riesigen PNGs versucht, aber das war auch nix. Jetzt als PDF. Damit Deine Augen nicht so leiden müssen. Gruß Jürgen
? ? schrieb: > Ich kenne sowas... ;) > > Weil Du dich schon recht festgelegt hast, meine Frage wie Du die Masse > führst... > > Z.b. hat es sich bei mir bewährt den Schirm mit ein paar pF auf die > Masse zu legen. > Die Leitungsenden auf eine passende art und weise abzuschliessen. > (reihenR, kleinesC, hochohmiger Spannungsteiler) Im Zusammenhang mit EMV denke ich aber, ist der Ort, wo man diese Kapazität platziert wohl entscheidend, oder? Wenn ich das auf der DCF-Seite meiner Karte machen würde, kopple ich mir wohlmöglich die Störungen wieder in die Schaltung ein und sie wabern durch alles hindurch. Meine Idee war aber eher sie um die Schaltung herumzuleiten. Aber vielleicht ist der Schirmring auch der falsche Ansatz. Waren alles so Ideen aus dem EMV-Buch von J. Franz. Gruß Jürgen
-verbinde doch mal Schirm mit ein paar pF mit der Masse. -Wie gut sieht denn Dein Oszillator aus ? -Wie schaut es eigentlich auf Deiner Ub aus ? Da sind ja nennenswert nur die 100nf Blockkondensatoren am µC. Vielleicht kannst Du da noch ein paar Müff an Elkos paralellschalten ? Denke am einfachsten am ISP. -Ist die Init wirklich weg ? Vielleicht kannst Du die Register gegenprüfen und bei abweichung eine LED ansteuern ? Das würde ich jetzt probieren.
Danke für die PDFs. Tja, kenne den Herrn Franz nicht. Aber führt man die Masse deshalb nicht genau an einem Punkt zusammen ? An Deiner stelle würde ich das jetzt Symetrisch/mittig machen. Viel ändern kannst Du doch nicht mehr ?! Ist Dein Ring nicht auch eine halbe Windung ? PS: Bin nur Autoschrauber... somit nicht kompetent. :)
> Das USB-Kabel, was ich der Maus geklaut habe ist rund 1,5m lang.
hochohmig, und meines wissens nicht geschirmt(?), spontan würde ich ein
anderes Kabel empfehlen.
Zusätzlich würde ich dir bei Verwendung dieses Kabels eine kleine
Drossel hinter der USB-Buchse in der Plusleitung empfehlen. Ein
zusätzlicher Keramischer Kondensator direkt dahinter nicht vergessen.
Evtl. solltest du auch noch einen 10µF einplanen.
Bist du dir ganz sicher, dass deine Z-Dioden D2 und D3 auf der richtigen
Seite des Widerstandes sitzen? So macht es eigentlich keinen Sinn.
Wie hast du eigentlich die beiden Kondensatoren C1 und C2 angeschlossen?
Fehlen da ein paar Leitungen/Layer oder kann ich Eagle nicht bedienen?
ALLE Spannungsversorgungspins sollten direkt (auf kürzestem Weg) mit
einem Kondensator (~100nF) verbunden sein.
? ? schrieb: > -verbinde doch mal Schirm mit ein paar pF mit der Masse. > > -Wie gut sieht denn Dein Oszillator aus ? > > -Wie schaut es eigentlich auf Deiner Ub aus ? > Da sind ja nennenswert nur die 100nf Blockkondensatoren am µC. > Vielleicht kannst Du da noch ein paar Müff an Elkos paralellschalten ? > Denke am einfachsten am ISP. Da bin ich gerade dabei. Um irgendeinen Unterschied zu merken, mache ich immer nur eine Änderung auf einmal. Derzeit ist ein 10u am DCF-Empfänger. Jetzt warte ich wieder auf den nächsten Blitz (oder was auch immer). Dann kommt die nächste Kapazität dazu. Mühsam ernährt sich das Eichhörnchen... > -Ist die Init wirklich weg ? > Vielleicht kannst Du die Register gegenprüfen und bei abweichung eine > LED ansteuern ? An die relevanten Einstellungen für Port D habe ich auch schon gedacht. Das versuche ich, wenn ich mit den Kapazitäten durch bin und die auch wieder eine Sackgasse waren. Was ich aus der Diskussion hier entnehme ist, dass dieser Microcontroller also offenbar keine besondere Empfindlichkeit gegenüber irgendwelchen eingekoppelten Störungen hat, oder? Gruß Jürgen
? ? schrieb:
> Viel ändern kannst Du doch nicht mehr ?!
Doch, eine neue Leiterkarte. Die versuche ich derzeit richtig zu
machen....
Gruß
Jürgen
Dann frage ich Dich jetzt mal : "Wie wird sowas richtig gemacht ???" ;)
Christian Gärtner schrieb: >> Das USB-Kabel, was ich der Maus geklaut habe ist rund 1,5m lang. > hochohmig, und meines wissens nicht geschirmt(?), spontan würde ich ein > anderes Kabel empfehlen. Also aus dem freien Ende dieses Kabels kommt ein Schirm. Da ist aber noch ein Schrumpfschlauch drüber. Vielleicht ein Fake? Was meinst Du mit "hochohmig"? Meine gesamte Schaltung verbraucht auch nur etwa 30mA. Oder meinst Du die Masse bzw. den Schirm? > Zusätzlich würde ich dir bei Verwendung dieses Kabels eine kleine > Drossel hinter der USB-Buchse in der Plusleitung empfehlen. Ein > zusätzlicher Keramischer Kondensator direkt dahinter nicht vergessen. > Evtl. solltest du auch noch einen 10µF einplanen. Die 10uF habe ich schonmal im nächsten Layout vorgesehen. Ob es etwas bringen könnte, versuche ich gerade herauszufinden (Karte läuft seit Gestern wieder). > Bist du dir ganz sicher, dass deine Z-Dioden D2 und D3 auf der > richtigen Seite des Widerstandes sitzen? So macht es eigentlich keinen > Sinn. Die CPU läuft mit 5V, somit auch die beiden USB-Leitungen, sobald der Controller sie bedient. Und das wiederum mögen die meisten USB-Host-Controller nicht, denn es sind nur 3,3V spezifiziert. Und bei 3,3V läuft wiederum der Atmega nicht mit 12 MHz. > Wie hast du eigentlich die beiden Kondensatoren C1 und C2 > angeschlossen? > Fehlen da ein paar Leitungen/Layer oder kann ich Eagle nicht bedienen? Optionen -> Einstellungen -> Verschiedenes -> Ratsnest berechnet Polygone Dann einmal Ratsnest auslösen. Dann füllen sich die leeren Flächen und die Bauteile darin werden angeschlossen, sofern sie zum gleichen Netz wie die Fläche gehören. > ALLE Spannungsversorgungspins sollten direkt (auf kürzestem Weg) mit > einem Kondensator (~100nF) verbunden sein. Wenn man die Spannungsversorgung flächig macht, gilt das nicht mehr (zumindest liest man das überall), bzw. bringt es keinen Vorteil mehr. Gruiß Jürgen
? ? schrieb:
> Dann frage ich Dich jetzt mal : "Wie wird sowas richtig gemacht ???" ;)
Das versuche ich ja gerade hier zu klären :-) Nur Bücher lesen hilft ja
scheinbar auch nix. Oft ist die Praxis ergiebiger.
Vermutlich bin ich hier aber inzwischen OT. Wenn nicht die CPU selber
der Übeltäter ist, sondern ich mit meinem Layout, sollte ich vielleicht
wo anders weiterfragen.
Gruß
Jürgen
>Wenn nicht die CPU selber der Übeltäter ist
Oder die V-USB Lib....
Ist ein FT232RL wirklich so teuer?
Was ich nur mal in den Raum werfen möchte: Die Software-USB-Lösung auf nem Atmega 8, die ich mir angeschaut habe verzichtet aus Rechenzeitgründen auf die Prüfung der CRC im USB-Protokoll. Wenn da mal n bit kippt kann ich mir gut vorstellen, dass es in die Hose geht. Versuchs doch mal mit nem externen USB controller ala ftdi und schau obs dann noch probleme gibt.
hihi, der erste Punkt auf der V-USB seite: * Fully USB 1.1 compliant low-speed device, except handling of communication errors and electrical specifications.
Hmmm, naja vielleicht gibt es einen Punkt an dem "wissen" (das ist ja auch nur höchst mögliches glauben) und glauben ausseinanderlaufen. Ich denke wenn man etwas nicht falsifizieren kann, wird es sehr viel Wahrscheinlicher. Schau doch mal deinen Schirmring an. Man könnte den jetzt als - Faradayschen Käfig sehen, bzw als Feldschwächung im Raum. - als kapazitive Kopplung zu den anderen Leiterbahnen. - als induktive Kopplung zu den anderen Leiterbahnen. Was ist stimmt jetzt ? Ich denke bei den richtigen Frequenzen und Feldstärken (verschiedene Fälle) kann fast alles zutreffen...
holger schrieb: >>Wenn nicht die CPU selber der Übeltäter ist > > Oder die V-USB Lib.... > Ist ein FT232RL wirklich so teuer? Nein, dass ist er nicht. Aber die Lösung über die beiden GPIOs hat ihren Charme. Und ich setze dass bereits in ein paar anderen Kärtchen ein. Um mal eben ein paar Steuer-Bytes zu übertragen ist der FTDI eher die "mit Kanonen auf Spatzen" Lösung. Und seit ich mit dem FT245BM so auf die Nase gefallen bin (grützige Busschnittstelle) bin ich mit diesen Separat-USB-Chips etwas vorsichtiger geworden. Gruß Jürgen
Eine Methode zur Fehlersuche, die mir half, eine unvermutet hochohmige und störempfindliche Verbindung aufzustöbern: 50Hz mit 50cm Kabel aus der Luft über dem Labortisch beziehen und damit über 100kOhm alle Anschlüsse der beteiligten aktiven Bauteile im Betrieb abtasten, mit dem Oszi messen, wenn der Anschluss niederohmig ist, sinkt die 50Hz Wechselspannung von etwa 10V auf unter 0,5V. Auf diese Weise fand ich einen zeitweise hochohmigen Anschluss (RXT des ATmega88, dessen Speisung zyklisch abgeschaltet wurde). Das konnte zum Stillstand (!) des Controllers bei statischer Elektrizität führen. Die Effekte waren mysteriös: Schaltung läuft bei offenem Gehäuse, langsames Schließen des Gehäuses rief den Fehler hervor, aber nur bei bestimmter Wetterlage. Streicheln des Gehäuses führte auch zum Fehler... Grüße, Peter
Mit hochohmig meine ich den ohmschen Widerstand der Leitung und des Schirms. O.k. das mit den Z-Dioden zur Spannungsbegrenzung könnte so funktionieren. > Wenn man die Spannungsversorgung flächig macht, gilt das nicht mehr > (zumindest liest man das überall), bzw. bringt es keinen Vorteil mehr. Dem würde ich so nicht glauben. Ich persönlich würde die 5V Leitung auf der Oberseite führen und alle VCC Pins extrem kurz anschließen, dann den Rest mit Masse fluten. Beide Seiten mit einigen Vias verbinden nicht vergessen. Christian
? ? schrieb: > Hmmm, > naja vielleicht gibt es einen Punkt an dem "wissen" (das ist ja auch nur > höchst mögliches glauben) und glauben ausseinanderlaufen. > > Ich denke wenn man etwas nicht falsifizieren kann, wird es sehr viel > Wahrscheinlicher. > > Schau doch mal deinen Schirmring an. > Man könnte den jetzt als > > - Faradayschen Käfig sehen, bzw als Feldschwächung im Raum. > > - als kapazitive Kopplung zu den anderen Leiterbahnen. > - als induktive Kopplung zu den anderen Leiterbahnen. > > Was ist stimmt jetzt ? > > Ich denke bei den richtigen Frequenzen und Feldstärken (verschiedene > Fälle) kann fast alles zutreffen... Das ist richtig. Aber vielleicht ist es ja auch mein Host, der sich was einfängt und in alle Richtungen kräftig austeilt. Wäre nicht der erste 0815-PC mit aufgedruckten TÜV- und GS-Zeichen, der sich so verhält. Nur: Welche Mittel und Wege hat man als Hobbybastler, hinter die wahre Ursache zu steigen? Gruß Jürgen
>Nur: Welche Mittel und Wege hat man als Hobbybastler, hinter die wahre >Ursache zu steigen? Nicht viele. Eine Bohrmaschine mit abgenutzen Kohlen die schon ordentlich feuert nehm ich ganz gerne. Ersetzt fast einen Blitz. Handy könnte man mal probieren. Staubsauger anmachen. Dimmer ohne Entstördrossel. Sei kreativ ;)
Fette Drossel, noch dickerer Elko so das dass Netzteil beim anlaufen schon Probleme bekommt. ;) Wenn der USBHost aussteigt, sollte doch ein reInit helfen ? Am ende liegts an irgendwelchen Stromspargeschichten lach Ohne Übertreibung an alles denken...
Hi >Und nach einer gewissen Zeit hört die GPIO- und UART-Aktivität einfach auf, >aber die LEDs funktionieren weiter (hängen an einem anderen Port). Jedesmal so? >Zunächst dachte ich, mir wird mein DDRD überschrieben, so dass die UART >nicht mehr senden kann. Also habe ich versucht, regelmäßig DDRD, Bit 1 >wieder so zu setzen, damit die UART senden kann. Wenn die UART (TX/RX) enabled sind, ist DDRD aus dem Spiel. Zeugt nicht gerade von profunden AVR-Kenntnissen. >Jetzt initialisiere ich den gesamten UART und DDRD in regelmäßigen Abständen >neu und nun kommen auch weiterhin Ausgaben über diesen Tot-Punkt hinweg >via UART... Also, das durch Störungen regelmässig die gleichen Symptome entstehen halte ich persönlich für recht unwahrscheinlich. Zumindest ist die Wahrscheinlichkeit, das sich ein verwirrter Pointer im IO-Bereich austobt genauso gross. MfG Spess
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.