Hallo zusammen
Habe hier ein Board mit insgesamt 6x TLC5955 Chips.
Nun habe ich bei der Ansteuerung festgestellt, dass mir hier wohl das
Propagation Delay einen Strich durch die Rechnung macht.
Gemäss dem Datenblatt habe ich die Chips in einer Daisy Chain
geschaltet. Doch pro Chip ergibt sich typ 20ns Prop. Delay. Daher kommt
die Clockflanke bei jedem Chip etwas früher als noch zuvor und daher
clockt der Chip zunehmend falsche Daten ein.
Wie würdet ihr das Problem hier lösen?
RC-Glied plus schmitttrigger in den CLK vor jedem IC?
Danke und Gruss
Moin,
ich würde erstmal, wenn dem so wäre, die kurzen Laufzeiten mit
Standartlogiggattern (CMOS 4000er Reihe oder ä.) erschlagen ...
Die haben ja typ. Gatterdurchlaufzeiten im ns-Bereich...
RC-Glieder plus SchmTrigger wäre schon zu viel.
Die Verzögerung bezieht sich doch auf sout vs. sclk.
Und da sclk an allen Chips gleichzeitig kommt, ist kein
Aufaddieren der Zeiten zu erwarten.
Grüße Ludwig
Ludwig V. schrieb:> Die Verzögerung bezieht sich doch auf sout vs. sclk.> Und da sclk an allen Chips gleichzeitig kommt, ist kein> Aufaddieren der Zeiten zu erwarten.> Grüße Ludwig
Stimmt, aufadieren nicht. Aber eine erstmalige Verzögerung um 20 bzw.
30ns.
Die kann ich auch messen.
Holger schrieb:> Aber eine erstmalige Verzögerung um 20 bzw. 30ns.
Wie hoch ist denn dein geplanter SPI Takt? Ich vermute
mal die Verzögerung ist völlig irrelevant gegenüber
deinem (gemässigten) Takt.
So schnell kann keiner Lichter anschauen .... falls du
in einen Geschwindigkeitsrausch verfallen solltest ....
Jo mei schrieb:> Holger schrieb:>> Aber eine erstmalige Verzögerung um 20 bzw. 30ns.>> Wie hoch ist denn dein geplanter SPI Takt? Ich vermute> mal die Verzögerung ist völlig irrelevant gegenüber> deinem (gemässigten) Takt.>> So schnell kann keiner Lichter anschauen .... falls du> in einen Geschwindigkeitsrausch verfallen solltest ....
Der SPI Takt ist bei ca. 4MHz.
Das Problem ist, dass der zweite Chip falsche Daten einliest. Denn
dieser sieht die Taktflanke, bevor das Bit aus dem vorigen Chip gekommen
ist.
Denn das Bit aus dem vorigen Chip hat eine Verzögerung von 30ns. Der
ShiftClock jedoch nicht.
Das klingt für mich eher nach falschem SPI Mode. 4 Mhz sind 250 ns
Periodendauer, da fallen die 30 ns nicht wirklich ins Gewicht. Stell
doch mal CPHA um.
Bene schrieb:> da fallen die 30 ns nicht wirklich ins Gewicht.
So isses. Man hat üblicherweise bei SPI etwa die halbe
Clockperiode Zeit um Daten zu setten ("Set Up Time").
Steigende vs fallende Flanke ....
Danke für den Tipp mit dem SPI-Mode.
Leider ändert sich nichts.
Habe aktuell alle Chips parallel geschaltet.
D.h. alle D-Ins miteinander verbunden und die Douts unterbrochen.
SPI-CLK bei allen gleich.
Ergebnis: einige leuchten, einige nicht, so wie bisher schon die ganze
zeit.
Sehr merkwürdig.
Interessant ist noch, dass wenn ich das board mehrmals ein und aus
stecke (speisung nicht die SPI-Signale) plötlich alle miteinander so
leuchten, wie sie sollen. Als ob gewisse chips in einem art reset hängen
würden. obschon dies laut DB gar nicht möglich ist, da es keinen
entsprechenden Zustand gibt.
Holger schrieb:> Ergebnis: einige leuchten, einige nicht, so wie bisher schon die ganze> zeit.
Dann ist dein Aufbau bzw. deine Schaltung scheisse.
Schon mal an vernünftige Stromversorgungs-Pufferung gedacht?
Es gibt noch vieeeele andere Fehlermöglichkeiten.
Am Ende des Tages (des Threads) kommt meist heraus dass der
Ansatz die Schaltung aufzubauen total daneben ist.
Holger schrieb:> Habe hier ein Board mit insgesamt 6x TLC5955 Chips...
Wenn jeder Chip etwa 20 ns an Verzögerung hat, dann mußt du eben mit
deiner Taktfrequenz heruntergehen, so daß 5*20ns, also 100ns kein
Problem mehr darstellen. Würde also per Milchmädchenrechnung maximal 5
MHz Takt ergeben (je 100ns H bzw. L)
Aber das mit der Verzögerung glaube ich dir nicht. Schließlich dürfte
mMn zwischen SIN und SOUT ein dickes Schieberegister liegen, so daß das,
was du an SOUT siehst, eben NICHT das verzögerte Eingangssignal ist,
sondern der Inhalt des allerletzten Flipflops des Schieberegisters. Und
der sollte dann mit der Flanke von SCLK in den nächsten Chip übernommen
werden, bevor er sich nach 20 ns ändert.
Kann es sein, daß ganz einfach deine Schaltung die Daten, die an SIN
kommen sollen, auf die verkehrte Flanke von SCLK herausgeben?
W.S.
W.S. schrieb:> Schließlich dürfte> mMn zwischen SIN und SOUT ein dickes Schieberegister liegen
Seeeehr richtig. Aber da man ja schon mal keine Ahnung hat
macht man halt mal irgendwas, wird schon was dabei rauskommen.
Welcher SPI-Mode ist für den TLC5955 der richtige (CPOL=?, CPHA=?)
Ich würde einfach alle 4 Möglichkeiten durchprobieren.
// Define baud rate
SPISettings mSettings(spi_baud_rate, MSBFIRST, SPI_MODE0);
Holger schrieb:> Leider ändert sich nichts.
Wenn es auf 30ns Taktflankenlage an kommt, werden deine Daten bei der
falschen Taktflanke übernommen oder du hast einen grundlegenden Fehler
in deiner Logik. Zeichne dir deine Signalverläufe mal auf und markierte
die bei dem jeweiligen SPI-Mode für die Datenübernahme relevante Flanke.
Route_66 H. schrieb:> Ich würde einfach alle 4 Möglichkeiten durchprobieren.
Es soll sogar Datenblätter geben, in denen die Zeitdiagramme für die
Datenübernahme abgebildet sind ...
Mit einem Auto probierst du doch auch nicht, ob man vor einer Wand
besser die Bremse oder das Gaspedal drücken sollte.
Unter der Annahme, dass das prinzipielle Design (Logik) korrekt ist:
Ich würde auch auf einen falsch konfigurierten Sample-Zeitpunkt tippen.
Oder auf schlechte Signalqualität (Reflexionen, Cross-talk, ...).
Hast du dir die gesampelten Daten mal angesehen? Wenn die nicht konstant
um X Bits zu den "Solldaten" verschoben sind (bzw. das beobachtete
Verhalten nicht mit um X Bits verschobenen Daten erklärbar ist), wird es
wohl eher in die Richtung Signalqualität gehen.
Holger schrieb:> Nun habe ich bei der Ansteuerung festgestellt, dass mir hier wohl das> Propagation Delay einen Strich durch die Rechnung macht.
Wie soll es?
SOUT ändert sich beim TLC5955 erst typisch 20ns (t_D0) nach der
steigenden Flanke von SCLK, d.h. wenn SCLK hoch geht, ist das Signal
noch 20ns stabil. Für die Datenübernahme sind 2ns gefordert (t_H0).
Falls deine Clock-Leitung zum zweiten Chip nicht gerade ein paar Meter
lang ist, sollte das immer passen. Mit 30ns Clockverzögerung erzeugst du
gerade das Problem, dass die Daten an SOUT nicht mehr stabil sind.
Deine Rechnung ist wohl falsch.
Joggel E. schrieb:> Der Clock/Latch sollte ja auch erst kommen, wenn die Daten stabil sind.> Bedeutet der kann ganz am Schluss kommen wenn ueberall die korrekten> anliegen.
Dann guck mal ins Datenblatt des TLC5955 (Fig. 20 und Tab. in 6.6).
SOUT wird kurz nach dem Clock instabil. Sonst würde das mit der
Daisy-Chain nicht funktionieren.
Vor dem Clock ist nach dem Clock.
Hast Du ein oszi? Dann Abfolge mit Datenblatt-diagramm abgleichen.
Achtung: manche Zeiten sind 0.
Zudem wären Doppelimpulse ein möglicher Fehler.
Wenn es parallel nicht klappt, mach dir keine Gedanken um irgendwelchen
vodoo.
propagation.png
(50 KB)
