www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik SPI Entstören


Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?

Autor: Floh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?
:-)

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lehrmann Michael (ubimbo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also bei mir sind die Daten mit 20 MHz von einem FPGA (120 MHz) via SPI 
unterwegs. Kabellänge größer 60 cm.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: anonymous (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es kann unabhängig von der Datenrate Probleme geben, wenn Störungen auf 
der Clock-leitung sind.
Eventuell Reflexionen?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Klaus (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Uwe N. (ex-aetzer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Uwe N. (ex-aetzer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uwe N. (ex-aetzer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ernestus Pastell (malzeit) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.