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
Angehängte Dateien:
-
propagation.png
50 KB
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.
Zwei NAND Gatter, oder zwei Inverter, oder zwei Schmitt-Trigger (ohne RC-Glied) aus der CD40xx Reihe, hintereinander geschaltet.
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.
Ich nutze diesen Code: https://github.com/zfphil/TLC5955 jedoch mit einem Arduino Leonardo (Atmega32u4)
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);
Route_66 H. schrieb: > Ich würde einfach alle 4 Möglichkeiten durchprobieren. Wenn der Aufbau scheisse ist hilft keiner der vier Modi.
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.
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
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.
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.