LEDs bremsen am Bus?

Hallo allerseits!

Ich habe mehrere Atmegas über diverse Ports verbunden um Daten zwischen diesen auszutauschen. Habe mir ein Busprotokoll ausgedacht etc. und es läuft auch ganz nett und ordentlich.

Ich erreiche Geschwindigkeiten um die 70 KB pro Sekunde, was meiner Meinung nach aber durchaus mehr sein könnte und sogar müßte.

Nun meine Frage: kann es sein, das meine LEDs - die von den Busleitungen über einen Widerstand nach Masse gehen - irgendwie eine Kapazitive Wirkung haben und mir so die Signale etwas "verseuchen", also dämpfen bzw. das Abfallen eines Pegels verzögern und mir so die Geschwindigkeit reduzieren?

Spiele grade mit dem Gedanken, die LEDs über eine Transistorstufe an den Bus zu hängen, aber es wäre ja schade, wenn ich 16 Transistoren, 16 LEDs, 32 Widerstände und Zeit für nix verbrate ;-)

Gruß MeckPommER

Das hängt etwas von den LEDs ab. Mit typsich 20 pF pro LED sollte man schon rechnen, aber die LEDs werden hoffentlich mit Vorwiederstand betrieben, der die LED vom Eigentlich BUS entkoppelt. Eventuell kommt noch etwas extra verzögerung beim Ausschalten daszu, aber durch den Vorwiderstand sollte das nicht weiter stören, es sei den bei sehr niedrigen Spannungen.

Für eine Schnelle Verbindung sollte eine SPI Verbindung gehen. Da sollten bei 20 MHz Clok bis zu 5 MBit/s also rund 600 kB pro Sekunde möglich sein. Das setzt aber kurze oder oder terminierte Leitungen vorraus.

Vorwiderstände (2,7k für die Low-Current LEDs) sind selbstverständlich vorhanden. Grade diese Verzögerung beim Ausschalten hatte ich eigentlich in Verdacht, den Datenverkehr bei mir zu bremsen.

Werde mich doch bei Gelegenheit an den Lötkolben schwingen und die Sache einfach mit größeren Widerständen und einer Transistorstufe austesten sowie weitere Teile des Datentransfers in Assembler machen.
60KBs scheint viel, aber wenn ein Bild von einer der Gameboy-Kameras zum Master geht, vom Master ins SRAM, dann vom SRAM-Modul wieder über den Master zum SD-Card-Modul ... das dauert *grumpf*

Die maximale Leitungslänge beträgt bei meinem Bot ca. 45cm.

Jetzt mal nur ne schnelle Überlegung, ohne den konkreten Hardwareaufbau zu kennen: Sollte man nicht vielleicht den Signalweg überdenken um auf höhere Geschwindigkeiten zu kommen? Also z.B. eine Gameboy Camera, ein SRAM und eine SD-Karte an den gleichen Controller hängen?
Will sagen, da wo der meisste Datenfluss ist, sollten am wenigsten Knotenpunkte dazwischenliegen wo die Daten erst durch müssen.
Auch würde ich die LEDs am Bus komplett weglassen, da sie für die Funktion ja nicht notwendig sind. Oder haben die Debugging-Zwecke?

MfG

Das mit den Signalwegen ist schon absolut richtig, aber mein Bot ist modular aufgebaut und steuert so viele Servos, empfängt so viele Sensorwerte, das einfach nicht alles an einem Controller geht.

Ferner möchte ich Funktionseinheiten wie Speicher nicht X-Mal aufbauen, sondern nur ein Mal zentral. (Auch wegen des Platzbedarfs)

Das SRAM dient nicht nur zur Speicherung von Bildern, sondern auch zur Speicherung von Messwerten, etc. und die SD-Karte speichert nicht nur Bilder, sondern schreibt auch LOG-Dateien und ähnliches.

Die LEDs dienen wirklich nur zu Debugzwecken. Ohne diese wäre es manchmal sehr schwer, festzustellen, wo es grade klemmt.

Limitierend sind zwar auch einige der Module (wie z.B. SRAM, auf dem mit Latches auf ein 512KB-SRAM zugegriffen wird, was natürlich langsam ist oder die GBCam, deren Werte erst digitalisiert werden müssen) aber ich möchte zumindest den Datentransport so schnell wie möglich gestalten, damit der Bot nicht anfängt zu ruckeln, weil der Daten vom Kopf nicht so schnell zu den Beinen kommen ;-)

Die LEDs nur bei Bedarf über einen Dipschalter dazuschalten?

Die LEDs werden weniger das Problem sein, eher die langen Leitungen. Da sollte man schon Leitungstreiber nehmen und auf die Leitungsimpedanz achten.

Die LEDs mit Dipschaltern zu versehen, gefällt mir nicht so. Es ist zwar eine Lösung, erinnert mich aber an die frühen Mainboards ^^
Ich würde die LEDs schon gerne immer im Blick haben können bei voller Busleistung.

Das die maximale Länge von 40-50cm schon Schwierigkeiten verursachen können sollen, erstaunt mich. Aber man lernt ja nie aus :)
Kürzer gehts halt nicht, weil auf dieser Strecke 15 Module mit Controllern sitzen und enger bekomme ich die nicht zusammen.

Probleme mit der Leitungslänge bekommt man dann, wenn die Laufzeit (ca. 5 ns je Meter) des Signals länger als etwa 1/5 der Signal Anstiegszeit ist. Für 50 cm also ab etwa 12 ns Flankensteilheit. Das ist also gerade etwas zu lang für die Ausgangssignal der AVRs und 74HCxx mit Anstiegszeiten von ca. 5ns - 10ns.
Der ISA Bus an den frühen IBM PCs lief schießlich auch nur mit 8 MHz, auch wegen der Probleme mit den Leitungslängen, und die haben schon was dafür getan damit es etwas besser geht.

Es könnte helfen wenn man die Flaken Absichtlich etwas langsamer macht. Wie man das ambesten macht, hängt aber sehr davon ab wie der Bus Aufgebaut ist. Gerade ein Bus mit vielen Modulen kann schwierig werden.
Am einfachsten sind Serienwiderstände von ca. 80 Ohm an den Treiberausgängen. Das Verlangsamt die Flanken etwas und gibt gleichzeitig eine ungefähre Anpassung der Leitungsimpedanz.

Danke für den Tipp ... äh ... nur begriffen hab ich nicht so ganz, was die Leitungslänge mit der Signalanstiegszeit zu tun hat - das ist der Nachteil, wenn man nicht vom Fach ist, sondern nur interessierter Laie.

Da die höchsten Frequenzen auf meinem Bus derzeit aber bei gemächlichen 60kHz liegen, vermute (hoffe/rate) ich aber derzeit, das es nicht die Leitungslänge mit den damit verbundenen Schwierigkeiten ist, die bremsend wirkt.

Um überhaupt eine Auswirkung von "irgendwie beschalteten" LEDs auszuloten, habe ich meine LEDs einfach mal von Masse genommen (die Leds hängen an Widerstandsnetzwerken - sind nun, obwohl von Masse getrennt immernoch über das Netzwerk mit einander gekoppelt) mit dem Ergebnis, das sich die Busgeschwindigkeit um 1-2% verringerte.

... eine ungefähre Anpassung der Leitungsimpedanz ... *denk: Bahnhof, Bahnhof, Bahnhof ... nächste Haltestelle: Grübelhausen*

Jede Leitung hat eine Kapazität und einen sogenannten Wellenwiderstand.

Der Wellewiderstand hängt von der Frequenz ab.
Offene oder hochohmig abgschlossene Leitungen haben daher einen Terminations- oder Abschlusswiderstand, der dem Wellenwiderstand der Leitung entspricht. Du kennst evtl. noch die alten PC-Netzwerkkraten mit den Koaxialkabeln? Da mußte auch ein Abschluswiderstand dran.
Wenn diese Leitungen nicht abgeschlossen werden, d.h. mit einem Widerstand der dem Wellenwiderstand entspricht mit Masse verbunden werden, kann das Signal reflektiert werden, das offene Litungsende wirkt dann wie ein Spiegel und das Signal kommt zurückt.

Die Kapazität der Leitung sollte klar sein, da sollte ein vernünftiger Bustreiber helfen um steile Flanken zu erhalten und damit hohe Schalt- bzw. Signalfrequenzen.

@iorcan:
Die steilen Flanken sollte man soweit möglich vermeiden. Dann kann man sich vieles von der Impedanzanpassung vereinfachen.

Bei den Controllern wird man die Daten kaum über 1 MB/s gebrauchen. Da sollte man dann mit Anstiegszeiten von ca. 100 ns noch keine Probleme haben, da hängt aber von den ICs und sonstigen Störungen ab. Die Leitungskappatzität sollte man eventuell mal Abschätzen. Jeder Zentimeter bringt ungefähr 1 pF und die Eingänge auch nochmal 1-5pF.
Man bräuchte wohl noch ein paar mehr Informationen zu dem BUS und dem Aufbau der Schaltung um da weiterhelfen zu können.


noch mal zum besseren Verständnis etwas zum Wellenwiderstand:

Der Wellenwiderstand gibt das Verhältnis von Spannung zu Strom zum Treiben einer gedachten undlichlangen Leitung an. Wenn nicht alzuviel Dämpfung (z.B. ohmscher Widerstand) im Spiel ist wird das duch das Verhältnis von Kappatzität und Induktivität bestimmt. Normalerweise ist der wellen Widerstand relativ unabhängig von der Frequenz. Normale Koaxialkabel haben z.B. 50-75 Ohm. Leitungen in Flachbandkabeln sowie normalbreite Leiterbahnen mit wenig Abstand ungefähr 100 Ohm. Mehr als ca. 300 Ohm sind fast nicht möglich.

Wenn eine Leitung einfach aufhört oder nur ein hochohmiger Eingang angeschlossen ist, verursacht eine ankommende Flanke dort Störungen. Es kommt mit der Flanke zu viel Strom an, weil ja keiner weiterfließen kann und dadurch steigt die Spannung kurzzeitig bis zu doppelten an und dann fließte der Strom wieder zurück in die Gegenrichtung und erzeugt ggf. am anderen Ende der Leitung noch mal Storungen die dann auch mehrmal hin und her laufen können. Wenn man sich die Signale auf einem Oszilloskop ansieht, kann man an den Flanke Überschwinger erkennen, die dazu führen können das das Signal auch nach einigen us noch nicht stabil ist.
Um das Refelktiern des Signals am Leitungsende und anfang zu vermeiden sollte der Ein bzw Ausgang den selben Widerstand wie der Wellenwiderstand der Leitung haben. Ein niederohmiger Treiber kriegt also einen Widerstand in Reihe und ein Hochohmiger Eingang einen parallel. Wenn man das an beiden Enden so macht, verliert man leider relativ viel vom Signalhub der Digitalsignale und verbraucht recht viel Strom. Da nur die hohen Frequenzen stören kann man dem Widerstand am Eingang einen relativ kleinen Kondensator in Reihe schalten. Durch den Serienwiderstand der hoffentlich zwischen Signal und LED hängt, sollte das Signal von der LED entkoppelt sein.

@iorcan & Besserwessi:

danke für eure Ausführungen, nun ist mir die Problematik schon deutlich klarer! Ich stelle mir das Ganze - um es mir zu veranschaulichen - momentan wie Wasser in einem U-Profil vor mit den Controllern, die mit ihren Impulsen Wellen erzeugen. Ist das U-Profil an den Enden geschlossen, gibt es Reflexionen etc., und die empfohlenen Terminatoren sorgen für den "Abfluss" an den Enden um die Reflexionen zu verhindern.

Das mit dem verringerten Signalhub bei den nötigen (kleinen) Abschluss-Widerständen und der daraus resultierenden hohen benötigten Leistung für den Bus ist wirklich ein Problem, da die Atmegas nicht viel Leistung auf den Ports bieten und ich andererseits auch keinen Platz für Treiberstufen habe ...

.. aber dank eurer Hilfe habe ich nun wenigstens Anhaltspunkte und kann mich weiter schlau machen, meine Technik verbessern und das Problem bekämpfen :)

Gruß & THX MeckPommER

Nachtrag:

Die LEDs waren tatsächlich am Problem unbeteiligt und bremsten den Datentransport in keinster Weise.

Nach einigem Nachdenken und Ausprobieren habe ich eine für mich wenigstens realisierbare Lösung gefunden.
Die Störungen bekomme ich nicht ganz unterbunden, dafür wäre zuviel Aufwand nötig mit Bustreibern etc. und die verbratene Leistung auf dem Bussystem wäre für meinen Bot auch nicht so schön.

Ich habe zwar den Bus mit Abschlusswiderständen terminiert, diese aber nicht so klein wie empfohlen (aber nicht machbar) gewählt. Das mindert zwar die Störungen, beseitigt diese aber nicht zu 100%.

Die Lösung meines Problems habe ich eher in der Software gefunden. Alle Programmteile der verschiedenen Controller habe ich in Assembler neu geschrieben und bessere Fehlerkorrekturen eingebaut. So liefert nun der Empfangscontroller das Signal des sendenden Controllers zu vergleichszwecken zurück und speichert das ankommende Signal erst, wenn der sendende Controller das zurückgegebene Signal als korrekt bewertet hat.
Etwas mehr Aufwand, aber sicherer und schneller. Momentan bin ich bei Datenraten von bis zu 120 Kilobytes pro Sekunde, was ja immerhin fast eine Verdopplung zur vorherigen Geschwindigkeit ist. Die reale Geschwindigkeit ist sicherlich noch etwas höher, aber die zu transportierenden Daten (128 Byte Blöcke) müssen ja ersteinmal von den Controllern bereitgestellt bzw. verarbeitet werden und das dauert ja auch so seine Zeit.

P.S.: Diesem Problemen auf die Spur zu kommen, ist mit nem Multimeter unmöglich. Einzig die Resultate von Änderungen lassen sich durch den Frequenszähler beobachten. Wenn ich mal groß bin, dann kaufe ich mir nen Oszilloskop ... ^^

auch ne Möflichkeit währe differenzieller Datenbus

@vitis:
Ein differentieller Bus wäre schön, aber da braucht man mehr Leitungen und definitiv spezielle Treiber und Empfänger. Wenn es nicht um sehr hohe Geschwindigkeiten geht kommt man noch ohne differentielle Übertragung aus.

Die Teileweise Terminierung ist schon eine Verbesserung. Bei den immer noch relativ niedrigen Geschwindigkeiten sollte aber vor allem die TErminierung an der Senderseite die beste Wahl sein. In der Regel ist das einfach ein Serienwiderstand von 50-100 Ohm. Neben der eigentlichen Terminierung werden die Flanken langsamer. Bei 0,5 bis 1 m Leitungslänge käme man auf etwa 100 pF Kappatzität und damit eine Zeitkonstante von etwa 10 ns. Dadurchwird die maximale Geschwindigkeit zwar etwas Begrentzt (ca. 10 MB/s), aber diese Grenze wird mit den AVRs ohnehin nie erreicht. Als Verteile hat man weniger Funkstörungen und fast kein zusätzlicher Stromverbrauch.

Nun, das mit den Widerständen in Serie werde ich einfach mal ausprobieren und schauen, was sich so in Sachen Geschwindigkeit tut. Da die Module alle gesteckt sind, läßt sich dort ja relativ einfach ein Zwischenstück mit Widerstanden einfügen.

Da ich die Daten auf den Bussen Nibble-Weise übertrage (restlichen 4 Bits für Kontrollzwecke) liegen die Frequenzen derzeit bei ca. 200-300 KHz. Da hab ich ja noch viel Luft nach oben :)

Aber egal, wieviel es letztlich bringen mag: jede Optimierung macht das System besser, sicherer und schneller und erlaubt zusätzliche Funktionen. Ausserdem ist Projektende sicherlich nicht vor 2012 und wenn ich mir anschaue, was ich in den letzten 12 Monaten so geschafft und dabei gelernt habe, dann bin ich mir sicherer denn je, das für mich richtige Hobby zu haben :-)

Manchmal ists nur für Aussenstehende ein wenig schwierig, nachzuvollziehen, warum man grade vor Glück aus dem Häuschen ist, nur weil irgendwo eine LED leuchtet und auf einer SD Karte ein Bild auftaucht ;-)