-         

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 17

Thema: LEDs bremsen am Bus?

  1. #1
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    19.07.2007
    Alter
    53
    Beiträge
    1.080

    LEDs bremsen am Bus?

    Anzeige

    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
    Mein Hexapod im Detail auf www.vreal.de

  2. #2
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    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.

  3. #3
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    19.07.2007
    Alter
    53
    Beiträge
    1.080
    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.
    Mein Hexapod im Detail auf www.vreal.de

  4. #4
    Benutzer Stammmitglied
    Registriert seit
    03.11.2004
    Ort
    Süderlügum
    Alter
    36
    Beiträge
    86
    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

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    19.07.2007
    Alter
    53
    Beiträge
    1.080
    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
    Mein Hexapod im Detail auf www.vreal.de

  6. #6
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    07.12.2007
    Beiträge
    180
    Die LEDs nur bei Bedarf über einen Dipschalter dazuschalten?
    Gruß

  7. #7
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Die LEDs werden weniger das Problem sein, eher die langen Leitungen. Da sollte man schon Leitungstreiber nehmen und auf die Leitungsimpedanz achten.

  8. #8
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    19.07.2007
    Alter
    53
    Beiträge
    1.080
    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.
    Mein Hexapod im Detail auf www.vreal.de

  9. #9
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    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.

  10. #10
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    19.07.2007
    Alter
    53
    Beiträge
    1.080
    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*
    Mein Hexapod im Detail auf www.vreal.de

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •