Hi! Ich habe eine Uhr aus RGB LEDs gebaut. Die LEDs werden über Controller angesteuert, die per SPI mit dem uC verbinden sind. Aufgrund der abmessungen der Platine und des Gehäuses sind die SPI-Leitungen leider recht lang (>20cm). Hin und wieder gibt es bei der Übertragung der Daten zu den RGB Controller Fehler. Ich übertrage im Moment bei ca. 10 kHz. Gibt es irgendwelche Möglichkeiten die Leitungen zu entstören (darf auch auf kosten der Geschwindigkeit gehen)?
Klaus schrieb: > zu den RGB Controller Fehler. Ich übertrage im Moment bei ca. 10 kHz. Da passt irgendwas grundlegend nicht, würd ich sagen. 10 kHz und dann Übertragungsprobleme? Kannst du mal die Platine zeigen (Foto, Layout)? :-)
Also ich schliesse meine Displays auch über SPI an. Da ist das (Flachband-) Kabel durchaus schon mal deutlich länger als 20cm. Und as gibt nicht einmal bei 10MHz Probleme. Haben die RGD-Controller denn Tri-State-Eingänge, wenn die alle auf dem selben Bus liegen? mfg
Also bei mir sind die Daten mit 20 MHz von einem FPGA (120 MHz) via SPI unterwegs. Kabellänge größer 60 cm.
Klaus schrieb: > Hin und wieder gibt es bei der Übertragung der Daten > zu den RGB Controller Fehler. Was sind das für Controller? Verwendest du evtl. den falschen SPI-Modus?
Es kann unabhängig von der Datenrate Probleme geben, wenn Störungen auf der Clock-leitung sind. Eventuell Reflexionen?
Klaus schrieb: > Aufgrund der > abmessungen der Platine und des Gehäuses sind die SPI-Leitungen leider > recht lang (>20cm). So kurz, dann kann es fast nur ein SW-Fehler sein. Überprüf mal das Timing der LED-Controller und des MCs. Stimmt überhaupt der SPI-Mode überein? Peter
@ Floh (Gast) >Da passt irgendwas grundlegend nicht, würd ich sagen. 10 kHz und dann >Übertragungsprobleme? Doch, das kann sein, siehe Artikel Wellenwiderstand. @ Peter Dannegger (peda) >So kurz, dann kann es fast nur ein SW-Fehler sein. Würde ich nicht sagen. Nach Prüfung des SPI-Modes solle man mal einen Blick auf die Verdrahtung werfen, siehe oben. Besonders die Taktleitung und deren Masse ist wichtig! MFG Falk
Falk Brunner schrieb: > Nach Prüfung des SPI-Modes solle man mal einen > Blick auf die Verdrahtung werfen. Und zwar am besten mit einem Oszilloskop... Oder einfach mal für den SCLK eine Serienterminierung einbauen. Aber erst mal sollte Klaus die anstehenden Fragen aus dem Beitrag "Re: SPI Entstören" beantworten...
Guten morgen und vielen Dank für alle Hinweise schonmal! Dann will ich mal etwas mehr Details liefern: Thomas Eckmann schrieb: > Haben die RGD-Controller denn Tri-State-Eingänge, wenn die alle auf dem > selben Bus liegen? Also die Controller sitzen in Reihe, brauchen also kein Tri-State. Lothar Miller schrieb: > Was sind das für Controller? Ich verwende den TLC5947 von TI. Ich hab das Datenblatt für alle Fälle angehängt. Lothar Miller schrieb: > Verwendest du evtl. den falschen SPI-Modus? Ich benutze eine Software-SPI. Die habe ich genau nach Datenblatt programmiert. Und in den meisten Fällen läuft die Übertragung ja auch korrekt. Das Layout habe ich auch mal angehängt. Links ist über ein kurzes Flachbandkabel die Platine mit dem uC angeschlossen (um das Gehäuse klein zu halten, sitze die 2. Platine direkt hinter der LED Platine). Da es meistens funktioniert, schließe ich Softwarefehler für die weitere Fehlersuche (zunächst erstmal ) aus. Der Artikel über den Wellenwiderstand war sehr interessant. Mein Layout ist auf jeden Fall etwas ungünstig. Und Störungen auf der Taktleitung würden die Fehler auch ganz gut erklären, denn hin und wieder sind alle Farben eines oder mehrerer Controller verfälscht, so als ob die Bitmuster verschoben sind. 1) Das erste, was man also beachten sollte ist die saubere Leiterbahnverlegung. Bei mir läuft die Taktleitung leider unten auf der Platine und die Masse oben über die Massefläche. Würde es helfen, eine zusätzliche Masseleitung auf der anderen Seite der Platine genau gegenüber der Taktleitung zu verlegen? 2) Terminierung: Hier wird es Problematisch. In dem Artikel steht zum einen, dass Serienterminierung nur bei Punkt zu Punkt verbindungen verwendet werden kann. Bei mir habe ich allerdings 5 Abnehmer für den Takt. Und Parallelterminierung ist laut Artikel nicht für 5V/3.3V Logik geeignet. Dazu kommt das Problem, dass ich den Wellenwiderstand der Taktleitung ja nicht kenne. Was kann ich da machen? 3) Anstiegszeit der Signale: Entscheidend ist also die Flankensteilheit der Signale. Gibt es nicht eine Möglichkeit die Steilheit der Signale zu reduzieren und damit das Problem zu entschärfen?
@ Klaus (Gast) >Leiterbahnverlegung. Bei mir läuft die Taktleitung leider unten auf der >Platine und die Masse oben über die Massefläche. Das ist ziemlich schlecht. >Würde es helfen, eine >zusätzliche Masseleitung auf der anderen Seite der Platine genau >gegenüber der Taktleitung zu verlegen? Ja, aber die muss auch überall zu den ICs Kontakt haben. >Taktleitung ja nicht kenne. Was kann ich da machen? AC-Terminierung. >der Signale. Gibt es nicht eine Möglichkeit die Steilheit der Signale zu >reduzieren und damit das Problem zu entschärfen? Mit einem kleinen RC-Tiefpass am Ausgang, sagen wir 100 Ohm/470pF. Ist nicht optimal, geht aber meistens. MfG Falk
Hallo Klaus, ich denke dein Hauptproblem könnte im Layout liegen: deine Taktleitung besteht aus vielen Stichleitungen (wenn ich das richtig sehe). Besser ist es, diese Pins direkt miteinander zu verbinden - OHNE Stichleitung, zumindest möglichst kurz (die Stichleitung). An diesen Stellen besteht die Gefahr von (wie bereits erwähnt) Reflexionen. Streng genommen müsste man ebenso mit der Datenleitung verfahren. Das sollte einfach umzusetzen sein ;-) Ich könnte mir vorstellen, das es vielleicht genügt, am Ende der Takt und Datenleitung ein Abschluss R einzufügen. Dessen korrekten Wert zu ermitteln ist auch nicht ganz einfach, aber zur Not reicht ein potentes Ozsi und eine handvoll R's, die man im Trial and Error Verfahren mal "ausprobieren" könnte (dabei nach Über- und Unterschwinger fahnden) Gruss Uwe PS.: Die Impedanz deiner Signal dürfte recht hoch sein, da GND meist sehr weit weg ist.
Uwe N. schrieb: > Streng genommen müsste man ebenso mit der Datenleitung verfahren. Die Datenleitungen sind beim SPI recht unkritisch, denn es macht eigentlich nichts aus, wie lange die herumklingeln, nur zum Übernahmezeitpunkt (Latch-Flanke vom Takt) müssen sie stabil sein...
Lothar Miller schrieb: > Die Datenleitungen sind beim SPI recht unkritisch, denn es macht > eigentlich nichts aus, wie lange die herumklingeln, nur zum > Übernahmezeitpunkt (Latch-Flanke vom Takt) müssen sie stabil sein... Naja, in diesen Fall ist es Routing-Technisch aber relativ einfach umsetzbar. Irgendwie stört mich dieses "denn es macht eigentlich nichts aus, wie lange die herumklingeln, ...". Klingeln auf der Leitung stört immer :-) Gruss Uwe
Terminierung oder Begrenzung der Flankensteilheit an der Taktleitung bringen leider keine Verbesserung. Aber mir fällt gerade auf, das die Fehler umso häufiger werden, je mehr LEDs leuchten. Daher meine Vermutung, dass es an den LED Rückströmen auf dem Masse liegt. Leider kann ich die Power Masse nicht von der Signalmasse trennen, da die LED-Controller keinen getrennten Masseanschluss haben. Hat noch jemand Vorschläge, wie ich das verbessern kann? Die zusätzliche GND Leitung von jedem IC direkt entlang der Daten- und Taktleitungen habe ich gelegt.
Mir fällt da noch das Fehlen eines jeglichen Pufferkondensators auf der gesamten Platine auf. Im Datenblatt sind da auf der ersten Seite zwischen Vcc und GND (Pin 1 und 32) Kondensatoren eingezeichnet... :-o
Lothar Miller schrieb: > Mir fällt da noch das Fehlen eines jeglichen Pufferkondensators auf der > gesamten Platine auf. Im Datenblatt sind da auf der ersten Seite > zwischen Vcc und GND (Pin 1 und 32) Kondensatoren eingezeichnet... :-o Oh, mein Fehler. Auf der Platine sind an jedem IC 10nF direkt an den Pins platziert. Hab wohl nicht die letzte Version des Boards hochgeladen.
Wie sieht den dein Takt/ Datensignal aus ? Sauber oder Über/ Unterschwinger ? Es nutzt wenig, eine Masseleitung parallel zu den Signalen zu legen, wenn die Signale sich durch die Stichleitungen Reflexionen einfangen. Vorrausgesetzt, es ist tatsächlich kein Software-Fehler und alle Spannungen/ Ströme sind wie erwartet.
Uwe N. schrieb: > Wie sieht den dein Takt/ Datensignal aus ? Sauber oder Über/ > Unterschwinger ? Leider, leider, leider habe ich bisher kein Oszi :-/ Aber ich habe trotzdem einen Erfolg zu vermelden :-) Ich habe jedem Controller noch einen kleinen Elko spendiert, der die Schaltströme der LEDs vom Massepin direkt zur Versorgung der LEDs um den Controller leitet. Und siehe da, seit 30 Minuten kein einziger Bitfehler mehr. Ich habe extra eine Funktion geschrieben, die die Daten nach der Übertragung wieder ausliest und mit dem gesendeten vergleicht. Aber bisher sieht alles gut aus. Ich werde das jetzt nochmal ein paar Stunden laufen lassen, und schaun ob nochmal ein Fehler auftritt oder nicht. Vielen Dank an alle, die mich unterstützt haben! Ich hab mal wieder viel dabei gelernt ;)
Klaus schrieb: > Terminierung oder Begrenzung der Flankensteilheit an der Taktleitung > bringen leider keine Verbesserung. > > Aber mir fällt gerade auf, das die Fehler umso häufiger werden, je mehr > LEDs leuchten. Daher meine Vermutung, dass es an den LED Rückströmen auf > dem Masse liegt. Leider kann ich die Power Masse nicht von der > Signalmasse trennen, da die LED-Controller keinen getrennten > Masseanschluss haben. Hat noch jemand Vorschläge, wie ich das verbessern > kann? Die zusätzliche GND Leitung von jedem IC direkt entlang der Daten- > und Taktleitungen habe ich gelegt. Servus an Alle! Ich habe ein ähnliches Problem bei der Serienschaltung von 12 TLC5940NT ICs. Beim letzten kann ich immer sonderbare Fluktuationen erkennen. Beim Betrachter der empfangenen Daten am Sin-Pin mit dem Oszi sehe ich nichts auffälliges. Leider konnte ich deinem Lösungsvorschlag nicht folgen. Könntest du es bitte "für dummies" erklären :-) ? Eine Verringerung der Frequenz von 8MHz auf 10KHz hat ein wenig Abhilfe geschafft, da ich zuvor bei bereits 8 ICs in Serie mit Problemen zu kämpfen hatte. LG Markus
Klaus schrieb: > Oh, mein Fehler. Auf der Platine sind an jedem IC 10nF direkt an den > Pins platziert. Hab wohl nicht die letzte Version des Boards > hochgeladen. Würde ich vor viel zu wenig halten. Jeder IC 100nF und 22µF Elko für die Gesamtplatine wären ein Anfang. Elkos sind idR nicht so HF-tauglich
Markus schrieb: > Leider konnte ich deinem Lösungsvorschlag nicht folgen. > Könntest du es bitte "für dummies" erklären :-) ? Der Schlüssel lag in unzureichenden Entkopplungskondensatoren. Hier offenbar speziell bei der LED-Versorgungsspannung. Entkopplungs kondensatoren an zwischen Vcc und GND möglichst nah an jedem IC. Und zusätzlich ein Elko für die ganze Platine. Und für die LED-Versorgungsspannung sicherheitshalber einen größeren Elko (>100uF).
Bitte 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.