Multiplexer für LED

  • Hallöchen,


    Ich möchte einen LED Cube bauen und habe mir schon soweit alles vorgelegt, wie ich das bewerkstelligen will. Nun ist der Punkt, dass ich als LED's welche mit WS2812b Chip verwenden will/werde. Nun ist die Frage, mit welchem MUX/DEMUX ich das am sinnvollsten anstelle, da die Chips ja eine feste Datenrate haben müssen, welche von dem Multiplexer gehalten bzw. garantiert werden sollte, also ohne Verzögerung wenn möglich. Ich bin aber im Bereich der Multiplexer total unbewandert und habe keine Ahnung, wo da die ganzen Unterschiede liegen.
    Da es ein Cube ist, muss ich vermutlich mehrfach hinterinander Multiplexen, um alles Ansteuern zu können.


    Hoffe jemand kann mir da weiterhelfen ^^


  • Ich sehe keine Sinn darin eine WS2812b mit einem Multiplexer zu betreiben....


    mfg maxl


    Gesendet von meinem E5823 mit Tapatalk


    Da es sich beim bauen eines Cubes leichter bewerkstelligen lässt die einzelnen LED's anzusteuern. Ich nutze sie trotzdem in Reihe und will über die Ebene Hinweg Multiplexen und somit immer nur einen "Strang" ansteuern, welcher sich angenommen in der z_Achse befindet. Und das Multiplexen findet über die x/y-Achsen statt.

  • Verstehe die Frage nicht so ganz. Wenn du einen WS2812b ansteuern kannst, kannst du doch auch 6 ansteuern. Du musst die auch nicht zeitgleich ansteuern, die Leitung auf Low zu lassen, und dann vie Multiplexer nur einen der 6 anzusteuern. Dafür brauchst du allerdings schon 3 Bit Multiplexer um die Werte 0..5 auszuwaehlen, plus eine Leitung fuer die eigentlichen Signale. Bist also eh schon bei 4 Leitungen. Da wuerde ich eher die zwei zusätzlichen spendieren, und dann kannst du auch alle gleichzeitig treiben.


  • Verstehe die Frage nicht so ganz. Wenn du einen WS2812b ansteuern kannst, kannst du doch auch 6 ansteuern. Du musst die auch nicht zeitgleich ansteuern, die Leitung auf Low zu lassen, und dann vie Multiplexer nur einen der 6 anzusteuern. Dafür brauchst du allerdings schon 3 Bit Multiplexer um die Werte 0..5 auszuwaehlen, plus eine Leitung fuer die eigentlichen Signale. Bist also eh schon bei 4 Leitungen. Da wuerde ich eher die zwei zusätzlichen spendieren, und dann kannst du auch alle gleichzeitig treiben.


    Naja bei nem Cube werden das aber locker mehr Leitungen. Und das was mich eigtl irretiert, ist die Vielfalt an Multiplexern und welchen ich den da nun am besten nehme.

  • mit WS2812B brauchst du keinen Multiplexer, du musst alle Daten im Stück rausjagen auch wenn sich von 300 LEDs nur eine LED ändert


    300 LEDs zu refeshen dauert 9ms usw.


    ich würde das vom Timing mit Arduino machen, braucht aber für die Daten 3 Byte pro LED also bei einem nano 328p mit 2k ist di Zahl der LEDs eben begrenzt auch für Code RAM
    mit einem mighty mini 1284p und 16KB SRAM kommt man weiter


    welche LEDs aktualisiert werden sollen kann man ja vom PI rüberschicken zum Arduino

    lasst die PIs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

    Edited once, last by jar ().


  • So war das ganze auch angedacht. Aber wie du eben sagst ist der Arduino begrenzt, weshalb ich eben die einzelnen Stänge mit LED's nur Refreshe und durch die anderen Multiplexe. Es stimmt das die WS2812b direkt in Reihe gebracht werden können, aber dann wird der Datenstrom eben sehr groß.

  • Du luegst dir in die Tasche wenn du denkst der Datenstrom wird mit Multiplexer kleiner. Es ist in jedem Fall fuer jedes LED die volle Farbinformation zu uebertragen, wenn du auch nur eine LED in einem Strang updaten willst. Im Fall eines vollen Updatesist die Datenmenge also exakt gleich. Wenn das System das nicht zuverlaessig schafft, dann ist es eh unggeignet.


    Das kleinteilige Optimieren von irgendwelchen Teilstraengen, die der MUX erlauben wuerde halte ich fuer ueberkandidelt. Das muesste schon ein sehr spezifischer Anwendungsfall sein, wo du zB eine Seite des Wuerfels schneller bespielen musst als alle anderen.


  • Du luegst dir in die Tasche wenn du denkst der Datenstrom wird mit Multiplexer kleiner. Es ist in jedem Fall fuer jedes LED die volle Farbinformation zu uebertragen, wenn du auch nur eine LED in einem Strang updaten willst. Im Fall eines vollen Updatesist die Datenmenge also exakt gleich. Wenn das System das nicht zuverlaessig schafft, dann ist es eh unggeignet.


    Das kleinteilige Optimieren von irgendwelchen Teilstraengen, die der MUX erlauben wuerde halte ich fuer ueberkandidelt. Das muesste schon ein sehr spezifischer Anwendungsfall sein, wo du zB eine Seite des Wuerfels schneller bespielen musst als alle anderen.


    Naja ich dachte mir das eigtl so, dass dann nicht der komplette Würfel die ganze Zeit im Arduino gehalten werden müsste, damit der RAM ausreicht.

  • Wievel LEDs sollens denn sein? Pro LED 3 Byte. Kannst du ausrechnen. Und ein ATMega2560 hat 8KB, da passen Daten fuer mehrere tausend LEDs rein.


    Wenn du das mit Arduino & Pi & Mulitplexer machst, hast du mehr Verdrahtungsaufwand & eine schlechte Update-Rate. Denn du musst


    1) Daten runterschicken
    2) rauspumpen an die LEDs
    3) rueckmelden, dass das passiert ist
    4) zu Schritt ein gehen


    Damit brauchst du diverse Millisekunden bis hunderte davon, bis du die gesamte Wuerfeloberflaeche geupdatet hast. Das wird ein schoenes geflacker.


  • Ok, damit hast du mich jetzt überzeugt. Wollte einen Arduino Nano zwischen hängen mit einem AtMega328, also 2KB. Würde also 'theoretisch' für 666 LED's reichen. Da ich allerdings erstmal nur mit 4*4*4 testen will, reicht das völlig. Und auch für die angestrebten 8*8*8 würde es locker reichen. Danke für die Ratschläge. Würde mich jetzt aber dennoch mal interessieren, wo der Unterschied bei den ganzen Mux/Demux liegt ?

  • Erwartest du jetzt, dass sich jemand hinsetzt, alle moeglichen Muxer/Demuxer raussucht, und die fuer dich vergleicht?!? Wenn du Fragen zu konkreten Bauteilen und/oder einem spezifischen Einsatzzweck hast - gerne. Eine kleine Marktuebersicht inklusiver freundlicher Einfuehrung in zugrundeliegende Konzepte ist zumindest mir ein bisschen viel...


  • Ok, damit hast du mich jetzt überzeugt. Wollte einen Arduino Nano zwischen hängen mit einem AtMega328, also 2KB. Würde also 'theoretisch' für 666 LED's reichen. Da ich allerdings erstmal nur mit 4*4*4 testen will, reicht das völlig. Und auch für die angestrebten 8*8*8 würde es locker reichen. Danke für die Ratschläge. Würde mich jetzt aber dennoch mal interessieren, wo der Unterschied bei den ganzen Mux/Demux liegt ?


    bei mir macht ein nano eine wordclock mit 114 LEDs aber der Platz ist schon arg knapp, reicht nicht mehr für NTP mit DCF77 und ein paar einstellungen per IR Fernb.


    für Größeres habe ich einen mighty mini 1284p am Start, der PI ist dafür nicht stabil genug soviel Zeit wie ich mit Linux verbringe....

    lasst die PIs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • bei mir macht ein nano eine wordclock mit 114 LEDs aber der Platz ist schon arg knapp, reicht nicht mehr für NTP mit DCF77 und ein paar einstellungen per IR Fernb.


    für Größeres habe ich einen mighty mini 1284p am Start, der PI ist dafür nicht stabil genug soviel Zeit wie ich mit Linux verbringe....


    Vielen dank für die Info :) Für die erstmal geplanten 64 LED's sollte der Platz dann noch reichen. Wenn ich mich entschließe noch eine größere zu bauen, dann muss wohl letztendlich ein neue MC her. Und ja meine Recherchen haben mir das gleiche über den Pi verraten. Man bräuchte halt ein Echtzeitbetriebssystem, welches das gewünschte Timing bereitstellt, da unter dem Pi die Interrups usw. kein genaues Timing ermöglichen, was im Endeffekt zu fehler des strikten WS2812b Protocols führt.