Auf 2m Länge SPI entstören / terminieren?

Hallo Freunde,

für den Bau einer 2m langen Laufschrift habe ich den SPI-Bus benutzt und habe nun Probleme.

Ich habe einen "Hauptprozessor" (Mega32) und 10 Mega8 (je 1 für eine 7x7 Matrix) per SPI verbunden. So lange ich das Kabel vom STK500 Board zum ATMega32 (ISP) dranlasse ist alles okay und die Laufschrift arbeitet problemlos.Das STK500 kann sogar ausgeschaltet sein. Ziehe ich dieses Kabel ab bricht die Kommunikation komplett zusammen und die Laufschrift bleibt stehen. Als Kabel habe ich ein Flachbandkabel in der Stärke von Klingeldraht genommen. Dass das dämlich war, ist mir nun klar aber das hilft mir ja für's Erste nicht weiter.

Was ich versucht habe:
1. Mich über Wellenwiderstand informiert und Serienterminierung an MOSI und SCK (MISO brauch ich nicht) direkt am AVR mit 150 Ohm versucht. Kein Erfolg.
2. Irgendwo etwas von Pullups an MOSI gelesen und probiert. Auch nix.

Was könnte man noch zur Entstörung versuchen ausser das ganze Kabel tauschen?

EDIT: Beim Ausschalten eben haben ich gerade festgestellt, dass die Störungen spannungsabhängig sind. Es ist zwar für alle Bauteile ein 5V Spannungsregler da aber irgendwo ist der Wurm drin: Bis zu einer Spannung von 8.8V ist alles okay, ab max 9.3 Volt Eingangsspannung findet gänzlich keine Kommunikation mehr statt.

Was ich nun tun? Zu Hüüülf ;)

ohne Schaltplan kann man ewig orakeln :(

kann es sein, dass Deine Anordnung zu viel Saft zieht und
der Regler wegen Überlast abschaltet?

Wie gesagt, welcher Regler, wieviel Strom etc.

Wenn es funktioniert, solange das STK500 dranhängt, würde ich zunächst den Fehler dort suchen. Hast Du vielleicht irgendeine Masse nicht richtig angeschlossen, die dann über das STK500 kommt?
Du könntest auch mal zB 2k7Ohm von SCK und MOSI gegen Masse schalten.
Serienterminierung und PulUps wären schon der richtige Weg, wenn es um Reflexionen auf der Leitung geht. Das würde man mit einem Oszi gut sehen. Die können dabei so stark werden, dass sie sich biis auf die Versorgungsleitung bzw. Masse rückwirken.
Du könntest die Signale messen mit und ohne Busaktivität, wenn Du ein Oszi hast.
Gruß

Hallo und vielen Dank für Euer Bemühen.

Da ich kein Oszi habe ist die Signalauswertung wie die Nadel im Heuhaufen.

Zitat:

---

Hast Du vielleicht irgendeine Masse nicht richtig angeschlossen, die dann über das STK500 kommt?

---

Leider nein, dort habe ich auch schon gesucht und neu verlötet - man weiß ja nie. Die Schaltung läuft auch ohne das STK, "Saft" ist also okay, nur die Übertragung ist hinüber.

Ich habe leider keinen Schaltplan,den ich einstellen könnte. Ich arbeite in der Grundschaltung der Prozessoren wie im Wiki, also nur einen Kondensator und Widerstand 10kOhm an Reset und die Wannenbuchse für den ISP. So wie hier:
https://roboternetz.de/wissen/images...ung_mitisp.gif

Der Mega32 ist auf MOSI und SCK mit den anderen Mega8 verbunden. SS ist auf die übrigen Ports gelegt.
Am Mega8 ist es auch die Grundschaltung mit MOSI, SCK und SS sowie 7+7 Ports für die LED Matrix. Eigentlich also nichts Aufregendes für die Verbindung untereinander.

Laut analogem Messgerät im Netzteil zieht die Schaltung bis ca. 1A Strom wenn alle LEDs an sind, analog ist aber träge. Rechnerisch sind es max. 70 LEDs, die mit einem Mal an sein könnten (in der Praxis aber eigentlich nur ca. die Hälfte), also 1,75A. Mein Problem ist aber auch bei nur einer geschalteten LED je Segment vorhanden. Spannungsregler ist ein 78S05 mit Kühlkörper, dieser versorgt die ganze Schaltung.

Ich würde versuchen wollen, dem Mega32 einen eigenen Spannungsregler zu verpassen. SCK & MOSI über R gegen Masse probiere ich auch heute Nacht.

ISP vom SPI entkoppeln.

Falls VCC sauber ist und es geht dennoch nicht: Versuch mal Kondensatoren an den SPI-Leitungen, zB 100pF KerKo. Gibt's andere Störquellen? Motoren, SNT bzw. SMPS, ...?

Die wirklich kritische Leitung ist CLK, denn da werden die Flanken gezählt. Die anderen sind weniger empfindlich.

Die 100 pF (nahe am Mega32) könnten helfen das Signal genügend zu verlangsamen. Alternaiv 100pF mit etwa 100 Ohm in Reihe am Ende der Leitung als Abschluß, nur bei hohen Frequenzen. Sonst würde ich eher etwas weniger als 150 Ohm für die Serienterminierung vorschlagen. Ohne Oszilloskop ist das aber schwer. Wenn mehr als 2 Punkte Verbinden wird, ist das mit der Terminierung nicht mehr so einfach.

Danke für die Tipps, ich habe nun Folgendes gemacht:

1) 1xSpannungsregler ATMega32, 1 zusätzlicher Spannungsregler nur für die 10 ATMega8. Das hat tatsächlich das Hauptproblem gelöst. Die Übertragung fast fehlerfrei.
2) Da immernoch am anderen Ende des Boards Übertragungsfehler auftraten habe ich mir die von Besserwessi empfohlenen 100Ohm Widerstände in Reihe mit einem 100nF (ist der zu groß?) Kondensator auf Masse gelegt.
3) Festgestellt, dass ich nicht mehr per ISP programmieren kann. Darauf habe ich die 100Ohm gegen die von Gock vorgeschlagenen 2,7 KOhm getauscht. Ergebnis: ISP ja, Störungen auch ja. Danach habe ich mir ein paar 470 Ohm gegriffen und habe damit einen Treffer gelandet. Per ISP programmierbar und störungs-...naja...frei...quasi ;)

Ergebnis: Die Übertragung läuft jetzt ausreichend stabil. Ab und zu sieht man für den Bruchteil einer Sekunde mal ein leicht verzögertes Flimmern der falschen LEDs, ist aber eben selten.

Nunja, das war mein erster Versuch mit SPI und war mir mal wieder eine ordentliche Lehre.

Noch eine Anmerkung zum Bascom Programm:
Ich nutze die aktuelle Bascom 1.11.9.3 und hatte Probleme. Sobald ich HW-SPI nutzen wollte ging der Mega32 nach einigen Sekunden fest, mit Soft-SPI gehts.

Empfängerseitig sieht es nicht wesentlich schöner aus: Ich nutze im Interrupt eine Funktion, die wahrscheinlich zu lange braucht, aber eine notwendige Berechnung durchführt.

Zitat:

---

Empfang:
Spiin A(1) , 7
B(1) = "" : B(2) = "" : B(3) = "" : B(4) = "" : B(5) = "" : B(6) = "" : B(7) = ""
For X = 1 To 7
Temp = Bin(a(x))
B(1) = B(1) + Mid(temp , 2 , 1)
B(2) = B(2) + Mid(temp , 3 , 1)
B(3) = B(3) + Mid(temp , 4 , 1)
B(4) = B(4) + Mid(temp , 5 , 1)
B(5) = B(5) + Mid(temp , 6 , 1)
B(6) = B(6) + Mid(temp , 7 , 1)
B(7) = B(7) + Mid(temp , 8 , 1)
Next X
Return
Return

---

Die Daten kommen nur ordentlich beim Mega8 an wenn ich sie vom Mega32 exakt drei mal mit spiout senden lasse. Bei weniger oder mehr hängt das Programm bei spiin und wartet. Gut, das aber nur mal am Rande. Für letzteren Effekt ist wohl nicht zuletzt mein Strippendesign verantwortlich ;)


Wieder mal ein herzliches Dankeschön an alle!

Für die Terminierung waren schon 100 pF gemeint, keine 100 nF. Die Zeitkonstante R*C sollte hier schon etwa zu der gewünschten Anstigszeit des Signals passen. 1-2 nF wären da dann etwa die obere Grenze. Mit 100 nF würde es nur gehen wenn man als Gatter HCT typen hätte.

Okay, danke. Ich setze dann mal die 100pF auf meine Reichelt-Liste und tausche das Teil. Sicher is' besser ;) Hätt' ich mal... O:)