ich habe ein unerklärliches Problem mit einer Ansteuerung eines PCF8574/HD44780 Displays auf einem Atmega328PB (nicht 328P!).
Auf meinem Aufbau mit einem Atmega328PB auf einer Expander-Platine bekomme ich die TWI-Kommunikation nicht zum Laufen.
Entsprechenden Empfehlungen nach habe ich mit verschiedenen Pull-Ups experimentiert und 330R serielle Widerstände eingefügt, nichts hilft.
Um Probleme mit meinem Code (AVR command line gcc) auszuschließen, habe ich die Arduino-IDE gestartet und das Beispiel aus https://github.com/mathertel/LiquidCrystal_PCF8574 auf mein Board geladen.
Ich habe das Beispiel mit vielen Serial.print() Statements erweitert, so dass ich ungefähr sehe, wo die Sache schief läuft.
Der Output sieht dann so aus, alle Beispiele soweit, bis der µC hängt. Das geschieht recht schnell. Ein bis 5 Reboots, dann hängt der Controller.
Jedes "==Start LCD==" steht für einen Reboot. BOD ist disabled, die Spannung ist auch komplett stabil, hängt an einem kleinen Labornetzteil.
Das Board hat alle Kondensatoren nach Datenblatt und
den Hardware Design Considerations for AVR Controller (https://ww1.microchip.com/downloads/en/appnotes/atmel-2521-avr-hardware-design-considerations_applicationnote_avr042.pdf)
Im Oszi kann ich den Triggerlevel auf 4,9V setzen, und bekomme keine fallende Flanke.
Das letzte Beispiel zeigt, dass durch den Absturz sogar die serielle Taktreferenz gestört werden kann.
Nun habe ich die TWI Kommunikation protokolliert und zum Spass den Code auf einen Pololu A-Star 328PB geflasht, da ich so die TWI1 Kommunikation mit einem gleichen Controller nachvollziehen kann.
Überraschung: Obwohl ich zum ersten Versuch noch keine Pullups verwendet habe, TWI nur mit den internen Port-Pullups läuft, rennt der Sketch auf dem A-Star sauber ohne Probleme.
Das Oszibild vom AStar sieht erschreckend aus, klar: die Pullups fehlen. Aber es tut.
Bei meinem Board fällt mir nur auf, dass ich auf dem SDA-Kanal einen kurzen Spike sehe, der auf dem A-Star nur zu sehen ist, wenn man durch meinen Spike darauf aufmerksam wurde.
Was kann ich noch untersuchen, welche Tips habt ihr, wie ich weiter vorgehen kann?
Beide Oszilloskopbilder sehen OK aus. Das erste deutet auf grenzwertig schwache Pullups hin, es geht aber noch.
Der Spike kommt in dem Moment, wo der Master die SDA Leitung los lässt jnd der Slave sie herunter zieht um das ACK Signal zu erzeugen. Dazwischen ist eine kurze Lücke, wo SDA "in der Luft hängt" und durch den Pullup hoch gezogen wird. Je stärker der Pullup ist, umso ausgeprägter der Spike. Er bei der nächsten steigen Flanke an SCL muss das ACK Signal sauber anliegen. Dafür ist noch reichlich Zeit übrig. Insofern: Deine Bilder sehen gut aus. Ich sehe darin keine Störung.
Was ich testen würde: Statte Master und Slave beide mit Pullups aus. Wenn die Kommunikation hängt, trenne due Verbindung (SDA und SCL) zwischen Master und Slave im laufenden Betrieb. Wahrscheinlich bleibt eine der getrennten Leitungen auf LOW hängen. Auf diese Seite (Master oder Slave) ist der Fehler zu suchen.
Zum Gegentest könntest du den I2C Scanner Sketch verwenden. Wenn der sich nie aufhängt, liegt ein Softwarefehler im den anderen Sketch nahe.
Beide Oszilloskopbilder sehen OK aus. Das erste deutet auf grenzwertig
schwache Pullups hin, es geht aber noch.
Das ist ja gerade das, was mich irritiert. Ein grenzwertiges Signal und die Sache läuft problemlos über Stunden.
Der Spike kommt in dem Moment, wo der Master die SDA Leitung los lässt
jnd der Slave sie herunter zieht um das ACK Signal zu erzeugen.
Dazwischen ist eine kurze Lücke, wo SDA "in der Luft hängt" und durch
den Pullup hoch gezogen wird. Je stärker der Pullup ist, umso
ausgeprägter der Spike. Er bei der nächsten steigen Flanke an SCL muss
das ACK Signal sauber anliegen. Dafür ist noch reichlich Zeit übrig.
Insofern: Deine Bilder sehen gut aus. Ich sehe darin keine Störung.
Ok, dann ist der Spike auch nicht das Problem, sondern die Folge der stärkeren Pullups.
Was ich testen würde: Statte Master und Slave beide mit Pullups aus.
Wenn die Kommunikation hängt, trenne due Verbindung (SDA und SCL)
zwischen Master und Slave im laufenden Betrieb. Wahrscheinlich bleibt
eine der getrennten Leitungen auf LOW hängen. Auf diese Seite (Master
oder Slave) ist der Fehler zu suchen.
Ok, das werde ich versuchen, dürfte ein wenig schwierig werden, dem Portexpander auf dem Display die Widerstände zu spendieren.
Zum Gegentest könntest du den I2C Scanner Sketch verwenden. Wenn der
sich nie aufhängt, liegt ein Softwarefehler im den anderen Sketch nahe.
Der wird sich auch aufhängen, siehe meine Crash-Logs. Da findet ja schon nach dem Wire.begin() ein Reset statt. Der verwendet ja auch die Wire-Bibliothek und startet mit "Wire.begin();", was ich zu "Wire1.begin()" ändern müsste.
Und ein Softwarefehler, der auf einem Board mit grenzwertigen Pullups nicht auftritt?
Ich verstehe momentan noch nicht, warum sich manchmal der µC ein paarmal resetted, bevor er hängt, manchmal jedoch gleich hängt.
Das Taktsystem (Quarz und Bürde-Kondensatoren). Der Quarzoszillator ist nämlich einer der wesentlichen Unterschiede zwischen 328P und 328PB. Der vom PB ist wesentlich "zickiger".
Sehr wahrscheinlich schwingt der hier gerade noch so. Das ist ganz schlecht, würde er gar nicht schwingen, würde das als Ursache ja sofort auffallen. Das "gerade noch so" fällt hingegen erst mal kaum auf, macht aber den ganzen µC instabil und kann für die seltsamsten Fehlerbilder sorgen.
welche Tips habt ihr, wie ich weiter
vorgehen kann?
Bürde-Kondensatoren tauschen. Erst eine E-Stufe kleiner, dann eine E Stufe größer als das, was aktuell verbaut ist. In eine der beiden Richtungen sollte sich eine dramatische Verbesserung ergeben, in der anderen hingegen wird das Teil wahrscheinlich garnicht erst anschwingen.
Bürde-Kondensatoren tauschen. Erst eine E-Stufe kleiner, dann eine E
Stufe größer als das, was aktuell verbaut ist. In eine der beiden
Richtungen sollte sich eine dramatische Verbesserung ergeben, in der
anderen hingegen wird das Teil wahrscheinlich garnicht erst anschwingen.
OK, das ist einen Versuch wert, könnte das Hängenbleiben und die serielle Taktverwirrung erklären. SCL1 liegt ja gerade neben XTAL1, ich habe die beiden XTAL-Anschlüsse zwar so gut separiert wie möglich, ich kann aber die räumliche Nähe nicht ausschließen. Da ist natürlich meine CPU auf dem Breakout Board empfindlicher, als der A-Star, da XTAL1 und SCLA dort auch erstmal parallel verlaufen, bevor es an die Pins geht.
Aktuell habe ich 33pF nach den oben erwähnten "Hardware Design Considerations for AVR Controller" verbaut, dort werden 22-33 angegeben. Ich hätte 20pF als nächstkleinere da, oder soll ich auf 18 oder gar 15 gehen?
Das Atmega328PB Datasheet schreibt was von 12pF-22pF.
das wird anders berechnet. Die internen Pads haben beim 'P' und 'PB' gleiche 18pF laut Manual. Nimm erstmal für deine Bürden 22pF. 33pF sind jedenfalls zu viel. Ob das jedoch den Spike eliminiert, weiß nicht so richtig. Oder ist das ein Messfehler mit dem Tastkopf? Massefeder vorhanden? Nimm einmal diese. Deine I2C Leitung ist wie lang?
Wenn er gar nicht taktet kommt CFD Kapitel 12 ins Spiel. Der 'PB' ist in sofern schon besser, weil die "verfused" Angst gibt es nicht.
Wie kommst du zu diesem Urteil?
Du musst das aus der Sicht der I2C-Spezifikation betrachten. Die Signale sind völlig in Ordnung. Nach Spezifikation müssen die Daten auf SDA einen stabilen Logikpegel besitzen, während SCL high ist - und das tun sie.
Macht denn ein 328PB wenn der Takt instabil wird oder ausfällt ein
Reset?
Interessante Frage. Ich kann hier nur mal soweit gehen, dass BOD ausgeschaltet ist und auch kein WDT aktive ist. Ich habe jetzt einmal
1
2
ISR(BADISR_vect) {
3
// Catch unexpected interrupts to prevent reset
4
}
in den Code eingefügt, in der Annahme, dass der Reset durch eine mir unbekannte Interruptquelle erzeugt wird. Ich vermute, es ist die Serial-Library.
Mit diesem Catchall gibt es keine Resets mehr,
Der Output von sieht nun so aus:
1
2
==Start LCD==
3
Probing for PCF8574 on address 0x27...
4
after Wire.begin() ...
5
after beginTransmission() ...
6
End Transmission, Error-code is: 0
7
LCD found.
8
==Start LCD==
9
Probing for PCF8574 on address 0x27...
10
after Wire.begin() ...
11
after beginTransmission() ...
12
End Transmission, Error-code is: 0
13
LCD found.
14
status==0
15
status==1
16
status==2
17
status==3
18
status==4
19
status==5
20
status==6
21
status==7
22
status==8
23
status==9
24
status==10
25
status==11
26
status==12
27
status==13
sieht mal ganz nett aus, ABER auf dem Display ist nichts zu sehen. Der serielle Port mit dem USB-seriell-Adapter ist tot, das Betriebssystem kann nicht mehr kommunizieren.
Es wurden zwar viele status-Zeilen ausgegeben, bis irgendwas die serielle Kommunikation getötet hat. Das Programm läuft weiter, erkennbar an ein paar Reaktionen auf dem Display. Manchmal sogar lesbarer Text, dann wieder lange nicht oder Bytemüll.
Was aber die Quelle für den Interrupt ist?
Also ich werde nun mal die Kondensatoren tauschen.
Bei meinem Board fällt mir nur auf, dass ich auf dem SDA-Kanal einen
kurzen Spike sehe
Dann lass dir einmal vom Logikanalysator erklären, was da passiert. Der Spike wird wohl an der Stelle sitzen, wo der Master sein letztes Bit, in dem gezeigten Fall ein Low, gesendet hat und dann den Treiber abschaltet. Das Bit danach kommt vom Slave und ist das ACK-Bit. Die Umschaltung ist eben nur endlich schnell und je nach dem, wie aggressiv du den losgelassenen Bus mit den Pull-Ups hochreißt, siehst du einen kurzen Peak oder eben nicht.
ABER auf dem Display ist nichts zu sehen...
erkennbar an ein paar Reaktionen auf dem Display.
Was jetzt, erscheint etwas auf dem Display oder nicht?
Ich hoffe, dir ist bekannt, dass es zahlreiche Varianten dieser Display+I²C Adapter gibt. Du musst die Pins zwischen dem Adapter und dem Display passend konfigurieren, wenn sie nicht zufällig der Standardvorgabe entspricht.
In der locker-flockig einfachen Arduino Welt verbirgt man die wahre Komplexität gerne - gibt mehr Likes.
ABER auf dem Display ist nichts zu sehen...
erkennbar an ein paar Reaktionen auf dem Display.
Was jetzt, erscheint etwas auf dem Display oder nicht?
Habe ich doch geschrieben: Fragmente von Text, die Hintergrundbeleuchtung geht mal an und aus, Bytemüll etc. Einfach Lebenszeichen. Die ich mit den kleineren Kondensatoren nun nicht mehr habe.
Ich hoffe, dir ist bekannt, dass es zahlreiche Varianten dieser
Display+I²C Adapter gibt. Du musst die Pins zwischen dem Adapter und dem
Display passend konfigurieren, wenn sie nicht zufällig der
Standardvorgabe entspricht.
In der locker-flockig einfachen Arduino Welt verbirgt man die wahre
Komplexität gerne - gibt mehr Likes.
Wie gesagt: Auf dem A-Star Board rennt der Test stundenlang! hab es auch spaßeshalber auf einen Nano (dann mit TWI0) gepackt, auch kein Thema. Das Display ist es definitiv nicht, die Codes stimmen!
Edit: mein eigener Code hat mit der Arduino-Welt wenig zu tun, ich schätze die Sachen jedoch als Referenz, weil weit verbreitet und getestet. Daher bin ich ja auch zum Verifizieren aud das Arduino-Beispiel umgestiegen.
eine grundlegende Frage.
Mit wieviel MHz soll dein 328PB takten?
Die Oszi Einstellung ist 10µs/DIV?
Ich frage deshalb, weil dein eingestellter I2C Takt im Code sind 10kHz.
1
Wire1.setClock(10000);
Laut Oszi ist die Periodendauer 10µs, was 100kHz sind.
100µs wären 10kHz.
Ist irgendwas falsch eingestellt?
So Kondensatoren auf 20pF reduziert, das Ergebnis ist niederschmetternd.
Weit unstabiler, es gibt sogar Resets, trotz Resethandler.
20pF sind aber auch mehrere Stufen unter 33pF, nicht eine, wie empfohlen. Das könnte schon fast wieder zu wenig sein.
Allerdings zeigt die deutliche Änderung im Verhalten (jedenfalls unter der Voraussetzung, dass du sonst nichts geändert hast) zumindest dies: hier ist wirklich die Ursache der Probleme zu suchen.
Man könnte auch mal den Quarz umgehen, indem man einen externen Taktgeber anschließt oder den internen R/C Oszillator verwendet. Dann ist allerdings nicht mehr sicher, dass die serielle Baudrate gut genug eingehalten wird. Ich denke, mit 2400 Baud stehen die Chancen besser als mit den meisten höheren.
20pF sind aber auch mehrere Stufen unter 33pF, nicht eine, wie
empfohlen. Das könnte schon fast wieder zu wenig sein.
Allerdings zeigt die deutliche Änderung im Verhalten (jedenfalls unter
der Voraussetzung, dass du sonst nichts geändert hast) zumindest dies:
hier ist wirklich die Ursache der Probleme zu suchen.
Da dachten wir das Gleiche! Ich nun auf 30pF gegangen und habe nach der Erfahrung mit dem AStar die Pullups und die seriellen Widerstände entfernt, und was soll ich sagen:
Die Sache läuft!
Sauber, wie auf dem AStar, auch wenn das Oszi nun die schwachen internen Pullups zeigt.
OK, vielen Dank allen, die mich auf diese Sache hingewiesen haben.
Wenn due Pullup Widerstände ein Problem auslösen, hast du wahrscheinlich eine mangelhafte Stromversorgung. Die kann auch den Oszillator zur Mimose machen.
eine grundlegende Frage.
Mit wieviel MHz soll dein 328PB takten?
Die Oszi Einstellung ist 10µs/DIV?
Ich frage deshalb, weil dein eingestellter I2C Takt im Code sind 10kHz.
1
Wire1.setClock(10000);
Laut Oszi ist die Periodendauer 10µs, was 100kHz sind.
100µs wären 10kHz.
Ist irgendwas falsch eingestellt?
Oops, das ist wohl ein Typo, den die Bibliothek aber wegsteckt (oder gar ignoriert), denn wie das Oszi zeigt, taktet SCL mit 100kHz!
Wegen der Oszibilder habe ich da gar nicht im Code nachgesehen. Hab es jetzt mit dem funktionierenden Setup auch mal auf 100000 gesetzt, kein Unterschied im Oszi! ;-)
Ich nun auf 30pF gegangen und habe nach der
Erfahrung mit dem AStar die Pullups und die seriellen Widerstände
entfernt, und was soll ich sagen:
Die Sache läuft!
Da er bei 33pF und 20pF nachweislich jeweils noch halbwegs schwingt, bei 33pF aber scheinbar etwas besser als bei 20pF, wäre wohl 27pF letztlich der optimale Wert.
Da er bei 33pF und 20pF nachweislich jeweils noch halbwegs schwingt, bei
33pF aber scheinbar etwas besser als bei 20pF, wäre wohl 27pF letztlich
der optimale Wert.
Wenn der so sensibel auf die Bürde reagiert, dann stimmt das was nicht, z.B. fehlende Entkopplungskondensatoren.
Wenn der so sensibel auf die Bürde reagiert, dann stimmt das was nicht,
z.B. fehlende Entkopplungskondensatoren.
Unzulänglichkeiten in der Versorgung erleichtern dem Oszillator natürlich nicht seine Arbeit, sind also ebenfalls eine Überprüfung wert.
Allerdings: wenn die Bürden optimal gewählt sind, ist auch die Resistenz gegen solche Unzulänglichkeiten optimal. Kann also definitiv nicht falsch sein, hier die richtigen Werte zu wählen, insbesondere dann nicht, wenn man den "Geht-Bereich" sowieso schonmal ausgeklingelt hat.
Außerdem: der 328PB-Oszillator ist auf LowPower optimiert und deswegen tatsächlich vergleichsweise anspruchsvoll bezüglich der Anpassung der Bürden. Das ist was ganz anderes als der "FullSwing"-Oszillator des 328P.
Wenn due Pullup Widerstände ein Problem auslösen, hast du wahrscheinlich
eine mangelhafte Stromversorgung. Die kann auch den Oszillator zur
Mimose machen.
Ich kann es jetzt nicht sagen, ob die Kondensatoren alleine das Problem gelöst haben oder nicht. Da ich aber ohnehin an der Stelle am Entlöten war, hab ich gleich zwei Dinge auf einmal erledigt.
Die Stromversorgung kann es eigentlich nicht sein: Das Oszi zeigt keinerlei Auffälligkeiten, ungefähr 20-30mV Ripple, der sich reduziert, wenn ich den seriell-Adapter entferne. Überall an Vcc und AVcc sind Stützkondensatoren, Das Netzteil ist stabil und könnte >8A, ist aber auf 120mA max gesetzt, aktuell zieht der µC mit Display und Hintergrundbeleuchtung 36mA. Ohne Beleuchtung sind es 16mA.
Das Display hat da, wo es angeschlossen ist einen 22µF Elko und einen 100nF zum Sieben.
Während ich das schrieb, passierte, was nicht passieren soll. Ich schob den laufenden Controller ein wenig weiter weg von mir, und die Probleme waren zurück.
Jetzt hatte ich einen anderen Verdacht. Aus einem anderen Projekt einen ebenfalls per Breakout-Bord gesockelten µC entnommen und diesen programmiert. Heftig hin- und hergeschoben, berührt (der Atmega soll verschiedenen Foreneinträgen ziemlich touchy sein), alles kein Problem.
Nun musste das Makroobjektiv ran. Ein Bild sagt mehr als viele Worte:
Das Reinigen mit Isopropanol un einem feinen Pinsel war wohl das Problem. Nochmals mit kräftig Iso abgewaschen, mit eine feinen Skalpellklinge die Stellen gereinigt (die ich mit Lupe und Lesebrille gar nicht sehen kann) und wieder eingesetzt und programmiert.
Lasse das Teil nun über Nacht laufen, ich fürchte, ich habe zwei Tage an den komplett falschen Stellen gesucht.
Die Bürde sollte eigentlich so ausgewählt werden, dass der Quarz
möglichst genau auf seiner Nennfrequenz schwingt.
Natürlich.
Wobei hier aber ein anderer Aspekt derselben Sache entscheidend ist. Nur bei der Nennfrequenz erreicht man die maximale Amplitude, die mit der durch den Oszillator gegebenen Energiezufuhr möglich ist. Und diese Amplitude muss halt für einen sicheren Betrieb der Triggerstufe ausreichen.
Kann man mit einem "FullSwing"-Oszillator mehr Energie in die Schwingung pumpen, ist auch der Bereich deutlich breiter, in dem sich eine Schwingung mit hinreichender Amplitude ergibt (wenn auch mit leicht abweichender Frequenz).
Die leicht abweichende Frequenz macht den µC nicht instabil. Eine unzureichende Amplitude hingegen schon.
berührt (der Atmega soll verschiedenen Foreneinträgen ziemlich
touchy sein)
Was ist mit evtl. unbenutzten Pins, sind die auf Input mit Pullup oder
Output geschaltet? Ein unbeschalteter Input ohne Pullup darf nicht sein!
Ich fragte nach Foto_s_ (Plural = Mehrzahl) vom gesamten Aufbau.
Solange keine kommen, gibt es keine Antworten mehr!
Lief jetzt über Nacht durch, ohne Probleme. Brauche also keine weiteren Antworten mehr. Trotzdem Danke!
Der ganze Rest stimmt, es gibt keine unbenutzen Inputs, es läuft nur das Arduino-Beispiel.
Ist die Aufnahme vor oder nach der Reinigung entstanden. Da sind immer noch merkwürdige Stellen zu sehen - im günstigen Fall Flussmittel oder evtl. sogar Lötzinn.
Ist die Aufnahme vor oder nach der Reinigung entstanden. Da sind immer
noch merkwürdige Stellen zu sehen - im günstigen Fall Flussmittel oder
evtl. sogar Lötzinn.
Du hast tatsächlich gesehen, was ich auch gesehen habe! Genau daher habe ich ja das Bild geposted.
Die Stelle hat tatsächlich dafür gesorgt, das SCL1 XTAL1 mit massiven Störungen versorgt hat. Das ist es, was ich dann entfernt habe, und seither läuft das Ding stabil, auch mit stärker schwankenden Spannungen, mieser USB-Verbindung etc.
Oops, das ist wohl ein Typo, den die Bibliothek aber wegsteckt (oder gar
ignoriert), denn wie das Oszi zeigt, taktet SCL mit 100kHz!
Hab es jetzt mit dem funktionierenden Setup auch mal auf 100000 gesetzt,
kein Unterschied im Oszi! ;-)
Mich würde es überaus nachdenklich stimmen, wenn ich ein Programm schreibe oder ändere und es hinterher nicht das tut, was ich zu schreiben oder ändern gemeint hatte.
Aus Erfahrung: sowas holt einen ein. Früher oder später.
Wenn due Pullup Widerstände ein Problem auslösen, hast du wahrscheinlich
eine mangelhafte Stromversorgung. Die kann auch den Oszillator zur
Mimose machen.
In der rückblickenden Betrachtung waren die Pullups ein Steinchen auf dem Weg zur Lösung, aber nicht wegen der Stromversorgung.
Sondern: Mit den Pullups wurden die Signale wesentlich mehr rechteckig, d.h. die Pulse auf SCL1 die über die Dreckbrücken (was immer das war) XTAL1 beeinflusst haben, waren steiler. Das Weglassen löste daher nicht die Probleme, sondern reduzierte sie nur ein wenig. Vermutlich war diese Mikro-Brücke auch noch beweglich, was für mich die Erklärung ist, warum es dann plötzlich auch mal längere Phasen ohne Aussetzer gab.
Ich habe immer nur die Verdrahtung auf der Punktrasterplatine untersucht, dazu auch immer den µC aus dem Sockel gehoben und beim Einsetzen dann auch wieder auf die Brücke gedrückt ;-) .
Kann man mit einem "FullSwing"-Oszillator mehr Energie in die Schwingung
pumpen, ist auch der Bereich deutlich breiter, in dem sich eine
Schwingung mit hinreichender Amplitude ergibt (wenn auch mit leicht
abweichender Frequenz).
Die leicht abweichende Frequenz macht den µC nicht instabil. Eine
unzureichende Amplitude hingegen schon.
Das ist, meiner Folgerung nach, genau was passiert ist: Für 160 Zyklen (Dauer eines SCL1 Pulses) wurde die Amplitude hochohmig angehoben, konnte also nicht auf GND_Niveau sinken.
Es war für mich interessant darüber nachzudenken. Ich ärgere mich, dass ich nicht auf die Idee kam, das Oszi an XTAL1/XTAL2 zu hängen. Auch wundert mich nun, dass hier niemand mit der Idee kam.
Die TWI Pulse sind wesentlich strenger, als die Quarzschwingungen, so dass die Beeinflussung nur in die eine Richtung gewirkt hat.
Da ich mit dem µC und dem Aufbau schon weit mehr Dinge getestet habe, die alle sauber liefen, hatte ich den Takt nicht im Blick. Aber das erklärt nun genau das Verhalten, dass bei sauberer TWI-Kommunikation der µC hängt, und dass das Hängen oder der Reset teilweise schon nach 3-8 SCL1-Zyklen stattfinden.
Auch erklärt es, warum alle anderen Pins einwandfrei taten, was sie sollten, im Gesamtaufbau sind nahezu alle Pins belegt.
eine grundlegende Frage.
Mit wieviel MHz soll dein 328PB takten?
Die Oszi Einstellung ist 10µs/DIV?
Ich frage deshalb, weil dein eingestellter I2C Takt im Code sind 10kHz.
1
Wire1.setClock(10000);
Laut Oszi ist die Periodendauer 10µs, was 100kHz sind.
100µs wären 10kHz.
Ist irgendwas falsch eingestellt?
Auch dem Thema bin ich nun nochmal nachgegangen. Hier habe ich wohl einen Fehler gemacht, und Code aus einem meiner Test geposted, der nach den Oszi-Aufnahmen nochmals verändert wurde.
Ich hatte da versucht den Takt zu reduzieren. Ich habe das nochmals getestet, weil ich ansonsten ein Github Issue aufgemacht hätte.
Zur vielfältigen Diskussion um die Bürde-Kondensatoren. Auch hier wieder rückblickend Selbstkritik. In dem Tütchen mit den Quarzen aus einer 13 Jahren alten Ali-Bestellung, findet sich ein Zettel, der dem "YIC 16000 C3 HC49" 20pF parasitäre Last bescheinigt.
Da ich automatisch, wenn ich einen aus dem Tütchen hole, immer auch 33/30pF (was gerade da ist) dazunehme, erinnere ich mich, das auch mal ausgerechnet zu haben:
C1=C2=2*(20-3) = 34pF, bei einem breiteren Stray-Wert dann: C1=C2=2*(20-5) = 30pF.
Der Wert passt also, die Resultate der kleineren Kondensatorwerte haben das auch gezeigt.
Soweit meine rückblickenden Überlegungen zum Thema.
Soweit meine rückblickenden Überlegungen zum Thema.
Meine rückblickende Überlegung zum Thema:
Du solltest dir - wenn noch nicht geschehen - Entlötlitze und
Flussmittel zulegen und die SMD-Pins vom überflüssigen Löt-
zinn befreien. Wenn du mal eine maschinelle Lötung anschaust
und vergleichst, wirst du feststellen dass du viel zu viel
Lötzinn drauf hast, was die Funktionssicherheit (Brücken) und
Prüfbarkeit (Lötstellen) beeinträchtigt. "Saubere" Lötungen
ersparen dir eine Menge Zeit der Fehlersuche.
Du solltest dir - wenn noch nicht geschehen - Entlötlitze und
Flussmittel zulegen und die SMD-Pins vom überflüssigen Löt-
zinn befreien. Wenn du mal eine maschinelle Lötung anschaust
und vergleichst, wirst du feststellen dass du viel zu viel
Lötzinn drauf hast, was die Funktionssicherheit (Brücken) und
Prüfbarkeit (Lötstellen) beeinträchtigt. "Saubere" Lötungen
ersparen dir eine Menge Zeit der Fehlersuche.
Ein Vergleich von Äpfeln mit Kokosnüssen. Wenn bitte, zeige mir Bilder von anderen händischen Lötungen!
Sobald man mit Entlötlitze auf die Pins geht, ist alles weg, und die Pins liegen sauber auf.
Bin dankbar für hilfreiche Tips, aber nicht für belanglose Vergleiche.
Bin dankbar für hilfreiche Tips, aber nicht für belanglose Vergleiche.
Beratungsresistenz ist eine Zier, doch weiter kommt man ohne ihr.
Dann komme doch mal mit einem brauchbaren Tip rüber! Wie kann ich händisch! mit noch weniger Zinn löten? Fotos von solchen Lötungen könnten helfen.
Es ist sogar so, dass Flussmittel dazu führt, dass das Zinn die Beinchen hochläuft.
Einfach nur sagen ist Scheiße, ist keine Beratung. Sofern bich ich schon resistent!
Wie kann ich händisch! mit noch weniger Zinn löten? Fotos von solchen
Lötungen könnten helfen.
Es ist sogar so, dass Flussmittel dazu führt, dass das Zinn die Beinchen
hochläuft.
Dann verwendest du eine ungeeignete Lötspitze und/oder hältst sie falsch.
Unter dem Stichwort "Drag Soldering" findest du einen Haufen Tutorials, z.B.
https://www.youtube.com/watch?v=wUyetZ5RtPs
Zur vielfältigen Diskussion um die Bürde-Kondensatoren. Auch hier wieder
rückblickend Selbstkritik. In dem Tütchen mit den Quarzen aus einer 13
Jahren alten Ali-Bestellung, findet sich ein Zettel, der dem "YIC 16000
C3 HC49" 20pF parasitäre Last bescheinigt.
Da ich automatisch, wenn ich einen aus dem Tütchen hole, immer auch
33/30pF (was gerade da ist) dazunehme, erinnere ich mich, das auch mal
ausgerechnet zu haben:
C1=C2=2*(20-3) = 34pF, bei einem breiteren Stray-Wert dann:
C1=C2=2*(20-5) = 30pF.
Der Wert passt also, die Resultate der kleineren Kondensatorwerte haben
das auch gezeigt.
"Was gerade da ist" ist Mist, der Wert muss schon zum Quarz CL passen. Ich komme mit 20pF CL auf 26pF Bürde Kondensator. 30pF wären mir dabei zu viel. Die Frage lautet, arbeitet er nun mit deinen 30pF sauber oder noch nicht? Denn darum dreht sich deine Eingangsfrage.
Ich komme mit 20pF CL auf 26pF Bürde Kondensator. 30pF wären mir dabei
zu viel.
Ich habe jetzt nicht nachgerechnet, aber auf 5 pF mehr oder weniger kam es bei mir noch nie an. Außer wenn er eine Uhr antreiben soll. Ist der PB Oszillator wirklich so pingelig?
Ich habe jetzt nicht nachgerechnet, aber auf 5 pF mehr oder weniger kam
es bei mir noch nie an.
Dann hast du wohl immer nur mit den ollen AVRs mit FullSwing-Oszillator gearbeitet. Bei denen spielen 5pf tatsächlich fast keine Rolle, außer für die Frequenz. Bei den LowPower-Oszillatoren hingegen sehr wohl.
Man kann das sehr schön mit mal mit einem Mega1284P ausprobieren, der bietet nämlich beide Oszillatortypen (per Fuse umschaltbar). Da kann man also ein- und dasselbe Layout mit ein- und derselben Bestückung und ein- und demselben Programm laufen lassen.
Was mit FullSwing problemlos läuft, kann mit LowPower entweder erst garnicht starten oder auch instabil laufen, wenn eine Fehlanpassung vorliegt.
Ich hatte z.B. mal ein Exemplar, bei dem war das einzige Anzeichen dieser Instabilität die Tatsache, dass Timer4 einfach nicht laufen wollte, alles andere ging ohne Auffälligkeiten. Das nur als Beispiel für abstruse, scheinbar völlig unerklärliche Fehler, die sich so ergeben können.
Nach Optimierung der Bürden lief das dann mit beiden Oszillatortypen gleichermaßen, insbesondere auch inclusive Timer4...
Ist der
PB Oszillator wirklich so pingelig?
Ja. Alle LowPower-Oszillatoren sind generell diesbezüglich deutlich anspruchsvoller als die FullSwing-Teile der alten Typen.
Es war für mich interessant darüber nachzudenken. Ich ärgere mich, dass
ich nicht auf die Idee kam, das Oszi an XTAL1/XTAL2 zu hängen. Auch
wundert mich nun, dass hier niemand mit der Idee kam.
Weil es keine besonders gute Idee ist. Es ist nämlich fast unmöglich, ein Oszi-Probe dranzuhängen, ohne die Eigenschaften des schwingfähigen Systems deutlich zu ändern. Das Probe ist halt ebenfalls ein komplexe Last und diese ist im Normalbetrieb nicht vorhanden.
Du siehst also auf dem Oszi nicht das, was im Normalbetrieb vorgeht.
Sinnvoller ist im Zweifelsfall, den Clock-Output zu aktivieren (sofern vorhanden) und dort zu messen. Aber auch das ist nicht ganz einfach. Das, worauf es ankommt (Jitter und ausfallende Ticks) sieht man auf einem einfachen Oszi nämlich leider erst mal garnicht. Bei gehobenen Oszis kann man den Spektrum-Analyzer benutzen. Der macht sowas sichtbar.
