Hallo, hier ein Fehler im Maxim Datenblatt zum MAX6675 Thermocouple IC: Im Datenblatt steht fälschlicher Weise, dass die Daten auf die fallende CLK-Flanke ausgelesen gehören. Das stimmt aber - wie man den angehängten Oszillogrammen entnehmen kann - definitiv nicht. Sie gehören auf die steigende CLK-Flanke (oder in der Mitte des pos. CLK-Pulses) ausgelesen. Gruß
Angehängte Dateien:
-
SCR_0004.PNG
7,6 KB -
SCR_0005.PNG
8,2 KB -
fehler.PNG
17 KB
an diesem Punkt bin ich jetzt auch, und auch 2009 hat das hier schon mal jemand gemeldet: Beitrag "MAX6675 Phänomen" Ich habe meine MAX6675 aus China, sind das möglicherweise Nachbauten die sich so verhalten? Oder hat jemand sicher Originale und das Gleiche gemessen?
Hi >Das stimmt aber - wie man den angehängten >Oszillogrammen entnehmen kann - definitiv nicht. Sie gehören auf die >steigende CLK-Flanke (oder in der Mitte des pos. CLK-Pulses) ausgelesen. Das hängt von den SPI-Einstellungen ab. Und die stimmen bei dir nicht. Lt. Datenblatt des MAX6675 hat SCK L als Ruhepegel. Bei dir ist es H. Welchen Controller benutzt du? MfG Spess
Die o.g. Bilder sind nicht von mir, ich habe einen LPC1347 und CPOL=0 eingestellt, der Clock Ruhepegel ist dann 0. Bilder vom Logic Analyzer kann ich erst heute abend liefern, aber auch mit CPOL=0 ist der Effekt der Gleiche, wie auch in dem verlinkten noch älteren Thread.
Ich hab vor kurzem noch ne Lib für den MAX6675 geschrieben und der verhält sich programmtechnisch und auch im DSO so wie im Datenblatt beschrieben. Sample bei falling edge. SPI MODE I CPHA = 1 und CPOL = 0 bei einem Mega88A
:
Bearbeitet durch User
Danke Thomas. Hast du DSO Screenshots gespeichert und kannst du die hier hochladen?
Ich hänge das Ding nur dran, wenn was nicht klappt. Dann fühle ich mich meist uncomfordable und sobald der Fehler gefunden ist kommt das Ding ab und ich arbeite weiter. An Fotos denke ich dann nicht. Ich hatte damals auch ein Problem mit der Modusfindung, deshalb erinnere ich mich aber noch genau daran, dass das Bild im DSO konform mit dem war was ich anhand des Datenblattes erwartet hatte, sobald ich das Bit für den SPI Modus 1 dann richtig gesetzt hatte im Controller. Wenn Du gar nicht weiter kommst kann ich das am Wochenende aber mal machen. SPI Mode I sollte aber klappen.
Hi
>ich habe einen LPC1347 und CPOL=0 eingestellt, der Clock Ruhepegel ist dann >0.
Es gibt auch noch CPHA im SSP/SPI Control Register 0. Und das muss 1
sein. Siehe S.252:
13.7.2.3 SPI format with CPOL=0,CPHA=1
MfG Spess
spess53 schrieb: > 13.7.2.3 SPI format with CPOL=0,CPHA=1 ist richtig, CPHA=1 hatte ich auch mal eingestellt und ich bekomme auch Daten. Allerdings ändert das nix am MAX sondern sagt nur dem µC wann er zupacken soll. Und wenn der MAX bei der fallenden Flanke die Daten ändert ist das Ergebnis stark Temperatur und Mondphasenabhängig. Ich habe den Saleae LA mit 25 MHz samplen lassen und die Daten stehen nur für eine Samplephase von 40 ns nach dem fallenden Clock an, dann ändern sie sich wenn ein anderes Bit folgt. Das HW SPI mag da noch rechtzeitig abtasten können, bei SW SPI wird man aber zu spät kommen. Wie geschrieben, ich kann die Screenshots leider erst später liefern.
Jojo S. schrieb: > Und wenn der MAX bei der fallenden Flanke die Daten ändert ist das > Ergebnis stark Temperatur und Mondphasenabhängig Keineswegs! Denn er ändert sie wegen der Flanke und logischerweise garantiert danach. > Ich habe den Saleae LA mit 25 MHz samplen lassen und die Daten stehen > nur für eine Samplephase von 40 ns nach dem fallenden Clock an, dann > ändern sie sich wenn ein anderes Bit folgt. Das ist doch ok. Welche Hardware-SPI braucht eine längere Hold-Zeit? spess53 schrieb: > 13.7.2.3 SPI format with CPOL=0,CPHA=1 So sehe ich das auch... MAX6675 schrieb im Beitrag #3535604: > Im Datenblatt steht fälschlicher Weise, dass die Daten auf die fallende > CLK-Flanke ausgelesen gehören. Das stimmt aber - wie man den angehängten > Oszillogrammen entnehmen kann - definitiv nicht. Dem angehängten Bild kann man entnehmen, dass die fallende Flanke zum Übernehmen der Daten genommen werden sollte. Sofort danach wird der nächste Ausgangswert angelegt. Das ist eine sehr durchsichtige Arbeitsweise, wenn man davon ausgeht, dass SPI nur verkettete Schieberegister sind. Falls man einen Soft-SPI macht, dann müssen die Daten natürlich /direkt vor/ der Erzeugung den fallenden Flanke gelesen werden. Denn danach wäre zu spät...
Lothar Miller schrieb: > Das ist doch ok. Welche Hardware-SPI braucht eine längere Hold-Zeit? ok, dann vergleiche ich nochmal beide Einstellungen. Die Hold Zeit ist für den LPC1347 mit min. 0 ns angegeben, den Atmega habe ich zum Vergleich noch rausgesucht und da steht typ. 10 ns.
Jojo S. schrieb: > ok, dann vergleiche ich nochmal beide Einstellungen. Die Hold Zeit ist > für den LPC1347 mit min. 0 ns angegeben, Das hätte ich erwartet. > den Atmega habe ich zum > Vergleich noch rausgesucht und da steht typ. 10 ns. Uuuups, schon wieder was verpfuscht? Trotzdem sollten die gemessenen 40ns noch locker ausreichen... ;-)
Angehängte Dateien:
-
MAX6675-SPI-Detail.png
52 KB -
MAX6675-SPI-CPHA-0.png
59 KB -
MAX6675-SPI-CPHA-1.png
59 KB
so, hier sind noch meine Screenshots. Eine Detailaufnahme, oben ist Clock und darunter MISO, abgetastet mit 100 MHz. Mit der höheren Auflösung komme ich jetzt auf <= 20 ns hold time. Dann zwei Bilder die das Gleiche Sample zeigen, aber einmal mit CPHA=0 und einmal mit CPHA=1 ausgewertet. Liefern beide das Gleiche Ergebnis, nur das das Timing bei CPHA=1 wesentlich entspannter ist. So würde ich einen SPI Sklaven auch implementieren, Daten bei der einen Flanke bereitstellen und bei der anderen für gültig erklären. Bei 50 % duty cycle haben die Daten einen halben Takt lang Zeit sich zu beruhigen und der Master hat einen halben Takt zum abtasten. Gut, wenn Maxim sagt das die Daten bei der fallenden Flanke abgeholt werden können und NXP sagt 0 ns hold time reichen dann lasse ich das CPHA=1 mal eingestellt.
Hi >Gut, wenn Maxim sagt das die Daten bei der fallenden Flanke abgeholt >werden können und NXP sagt 0 ns hold time reichen dann lasse ich das >CPHA=1 mal eingestellt. Also war der 'Fehler im Datenblatt' wohl doch etwas vorschnell. Mit solchen Aussagen sollte man sehr, sehr vorsichtig sein. MfG Spess
spess53 schrieb: > Also war der 'Fehler im Datenblatt' wohl doch etwas vorschnell. Mit > solchen Aussagen sollte man sehr, sehr vorsichtig sein. die stammte zwar nicht von mir, aber auch Datenblattschreiber sind nicht unfehlbar. Ausserdem habe ich mich wieder umentschieden :-) Ich habe mir jetzt auch das Datenblatt vom Nachfolger MAX31855 angesehen, die Diagramme sind gleich und es werden die gleichen Characteristics beziffert. Der Neue ist nur schneller und liefert mehr Bits. Und die entscheidende Passage ist hier einfach anders formuliert: 'Bits D[30:18] contain the converted temperature in the order of MSB to LSB, and are presented to the SO pin within tD0 of the falling edge of SCK.' Heisst für mich auf Deutsch: die Bits stehen spätestens nach tDO (40 ns beim 31855, 100 ns beim 6675) an. Das erste Bit (MSB) steht spätestens nach 100 ns nach CS an. Diese Zeit halte ich locker ein, >1 µs. Dann habe ich immer bis zur nächsten fallenden Flanke Zeit die Bits zu lesen - die steigende Flanke liegt also zu 100 % in diesem Fenster.
Jojo S. schrieb: > Dann habe ich immer bis zur nächsten fallenden Flanke Zeit die Bits zu > lesen - die steigende Flanke liegt also zu 100 % in diesem Fenster. Oder andersrum: du verschenkst die Hälfte der Zeit, weil du nicht bis zur fallenden Flanke wartest. Jojo S. schrieb: > Gut, wenn Maxim sagt das die Daten bei der fallenden Flanke abgeholt > werden können Dieser Ausdruck "bei der Flanke abgeholt werden können" dreht mir immer den Magen um. Richtig ist, dass MIT der Flanke übernommen werden sollen. Die Flanke taktet das Schieberegister...
Lothar Miller schrieb: > Jojo S. schrieb: >> Gut, wenn Maxim sagt das die Daten bei der fallenden Flanke abgeholt >> werden können > Dieser Ausdruck "bei der Flanke abgeholt werden können" dreht mir immer > den Magen um. Richtig ist, dass MIT der Flanke übernommen werden sollen. Nein, in diesem Fall sollen die Daten eben nicht MIT fallender Flanke übernommen werden, sondern die Daten stehen NACH der fallenden Flanke des Masters plus tDO bereit. So steht's im DB, für den 6675: "SCK Fall to Output Data Valid -> 100ns" Nimmt man das SPI-Interface eines AVRs (ATM328p), dann gibt das DB Setup und Hold mit jeweils 10ns an, Mastermode. Das Timing kann damit von der SPI-HW bei der Übernahme auf fallende Flanke nicht eingehalten werden. Um das zu erreichen, übernimmt man bei steigender Flanke, dann ist tDO berücksichtigt. Das steht so aber nicht im DB des 6675, das muss man sich selbst denken.
MWS schrieb: > Lothar Miller schrieb: >> Jojo S. schrieb: >>> Gut, wenn Maxim sagt das die Daten bei der fallenden Flanke abgeholt >>> werden können >> Dieser Ausdruck "bei der Flanke abgeholt werden können" dreht mir immer >> den Magen um. Richtig ist, dass MIT der Flanke übernommen werden sollen. > > Nein, in diesem Fall sollen die Daten eben nicht MIT fallender Flanke > übernommen werden, sondern die Daten stehen NACH der fallenden Flanke > des Masters plus tDO bereit. So steht's im DB, für den 6675: "SCK Fall > to Output Data Valid -> 100ns" > > Nimmt man das SPI-Interface eines AVRs (ATM328p), dann gibt das DB Setup > und Hold mit jeweils 10ns an, Mastermode. Das Timing kann damit von der > SPI-HW bei der Übernahme auf fallende Flanke nicht eingehalten werden. > Um das zu erreichen, übernimmt man bei steigender Flanke, dann ist tDO > berücksichtigt. Das steht so aber nicht im DB des 6675, das muss man > sich selbst denken. das ganze Datenblatt lesen, auch die minimal erlaubten High bzw Low Zeiten für die Clock sowie deren maximale Frequenz. Bei maximaler Geschwindigkeit wirst du bei Verwendung der steigenden Flanke Probleme bekommen die Setupzeit im Worstcase einzuhalten. Füge dann noch ein etwas längeres Kabel und eventuell (aktive) Optokoppler oder Leitungstreiber hinzu und schon geht gar nichts mehr. Ich schliesse mich Lothar an, die fallende Flanke sollte verwendet werden, dann ist das alles unkritisch, auch wenn die Holdzeit des 6675 leider nicht spezifiziert ist, bzw nur duch den angemeckerten Satz impliziert wird, dass sie >0 ist.
Lattice User schrieb: > das ganze Datenblatt lesen, auch die minimal erlaubten High bzw Low > Zeiten für die Clock sowie deren maximale Frequenz. Ein ausgezeichneter Ratschlag, wenn Du den jetzt noch selbst beherzigst, dann wird alles gut. ;-) Max. Clock = 4,3MHz = 232ns / Periode, min. Clock H/L = 100ns. Zuerst kommt die fallenden Flanke des Masters, welche dem Slave sagt, er möge Daten bereitstellen, wofür dieser bis zu 100ns benötigen darf. 1:1 Clockratio vorausgesetzt, kommt nach 116ns die steigende Flanke, zu welchem der Master die Daten übernimmt. Das ist doch vom Timing einwandfrei und genug Zeit bis der Master wieder auf Low zieht. Wenn jedoch der Master auf seinen fallende Clock sampelt und der Slave bis zu 100ns benötigt, bis die Daten sicher stehen, wie soll er da irgendwie im Timing liegen? Besonders, wenn das hier auch noch zuträfe: > Bei maximaler Geschwindigkeit wirst du bei Verwendung der steigenden > Flanke Probleme bekommen die Setupzeit im Worstcase einzuhalten. Füge > dann noch ein etwas längeres Kabel und eventuell (aktive) Optokoppler > oder Leitungstreiber hinzu und schon geht gar nichts mehr. D.h. Clock zum Master verzögert sich zum Slave, die rücklaufenden Daten auch, während in der Zwischenzeit der Master bereits irgendetwas übernommen hat. Aber wenn Du schon diese Meinung vertrittst, dann erklär' doch mal an einem einfachen Beispiel, wie Du Dir eine Abholung bei fallender Flanke so vorstellst.
MWS schrieb: > Nein, in diesem Fall sollen die Daten eben nicht MIT fallender Flanke > übernommen werden Steht aber so im Datenblatt. Ganz oben rechts im Screenshot... > sondern die Daten stehen NACH der fallenden Flanke des Masters plus tDO > bereit. So steht's im DB, für den 6675: "SCK Fall to Output Data Valid > -> 100ns" Damit ist also die fallende Flanke der sicherste weil stabilste Zeitpunkt, wo die Daten übernommen werden könnten. Denn nach oder besser wegen der fallenden Flanke kommt ja wieder Bewegung in den Laden... MWS schrieb: > kommt nach 116ns die steigende Flanke, zu welchem der Master die Daten > übernimmt. Das ist doch vom Timing einwandfrei und genug Zeit bis der > Master wieder auf Low zieht. Aber wenn der Master nochmal 116ns warten würde, wären die Daten noch stbiler... > Wenn jedoch der Master auf seinen fallende Clock sampelt und der Slave > bis zu 100ns benötigt, bis die Daten sicher stehen, wie soll er da > irgendwie im Timing liegen? Wenn sich die Daten wegen der fallenden Flanke ändern, dann ist die nächste fallende Flanke die Flanke mit dem größten Abstand und der längsten Setup-Zeit. > Aber wenn Du schon diese Meinung vertrittst, dann erklär' doch mal an > einem einfachen Beispiel, wie Du Dir eine Abholung bei fallender Flanke > so vorstellst. Ein Schieberegister "holt" nichts ab, sondern wird einfach mit der fallenden Flanke getaktet. Und laut der Rechnung hat das Signal zwische zwei solcher Flanken insgesamt 232ns Zeit, sich zu stabilisieren. Davon geht weg: der Slave braucht 100ns, der Koppler 50ns, die Leitung 17ns, das Schieberegister hat eine Setup-Zeit von 10ns (alles halbwegs realistische Beispielwerte!!), bleiben zur Signalstabilisierung noch: 232-100-50-17-10 = 55ns. Und nur so kann es funktionieren...
:
Bearbeitet durch Moderator
nur warum sollte man Treiber und damit Verzögerungen nur in einer Leitung einbauen? Takt und Daten gehören gleichmässig getrieben/verzögert, wer das einseitig verzögert ist doch selber Schuld. Dazu kommt das die tDS = 100 ns eine max. Angabe ist, nach meiner Messung ändert sich der Pegel schon nach 10..20 ns (bei 100 MHz kann ich nur mit 10 ns auflösen). Damit ist man beim ATMega schon sehr nah an den min. 10 ns Haltezeit dran. Aber da ich einen LPC benutze ist mir das gerade egal :-) Und auch das Auslesen mit 4 MHz läuft sauber.
MWS schrieb: > Zuerst kommt die fallenden Flanke des Masters, welche dem Slave sagt, er > möge Daten bereitstellen, wofür dieser bis zu 100ns benötigen darf. 1:1 > Clockratio vorausgesetzt, kommt nach 116ns die steigende Flanke, zu > welchem der Master die Daten übernimmt. Das ist doch vom Timing > einwandfrei und genug Zeit bis der Master wieder auf Low zieht. das wäre allerdings auch sehr knapp, mein Master hat eine Setup time von 15 ns, damit bin ich dann noch 1 ns im grünen Bereich :) Also begnüge ich mich mit 4 MHz max. Takt und warte eine knappe µs länger auf das Ergebnis. Da der MAX eh erst nach 220 ms einen neuen Wert liefern kann ist das auch nicht so tragisch.
Jojo S. schrieb: > Takt und Daten gehören gleichmässig getrieben/verzögert, wer das > einseitig verzögert ist doch selber Schuld. Das ist nur die halbe Wahrheit, denn für den Master wird ja tasächlich nur das MISO-Signal verzögert. Der Schiebetakt ist ja "sofort" im Master, denn er wird vom Master erzeugt... Die gesammelten Verzögerungen sind aus sicht des Masters also: Laufzeit Takt vom Master bis zum Slave plus der Verzögerung im Datenpfad vom Slave zum Master.
gut, ich ergebe mich und bin froh keine Treiber und kurze Leitungswege zu haben. Es ist wichtig die richtige Flanke zu nehmen vor allem wenn die Taktfrequenz hoch wird oder Treiber ins Spiel kommen. Und beim SW SPI aufpassen wann die Datenleitung gelesen oder gesetzt wird. Danke für die gute Aufklärung!
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.