R/G-Matrix 80x8 mit TLC5940 ansteuern bzw.Alternativen

  • Habe auch mal wieder ne Frage....


    ich suche für ein R/G-LED-Matrix-Modul 8x8 (elektrisch gesehen eine Matrix mit 8x16) einen Matrix-Treiber-IC, ähnlich wie den beliebten MAX7219/7222, nur soll der können:


    - eben 8x16 statt nur 8x8
    - jede LED einzeln dimmen statt nur alle gesamt - muss nicht 256 Stufen sein, 32 z.B. reicht auch


    wichtig:


    - da die Module nur 2 x 2 cm² groß sind, und hinter jedes Modul direkt ein IC soll, darf dieses max. so 0,8 x 2 cm² (SO-32 o.ä.) groß sein - gerne auch kleiner, solange noch mit Haushaltsmitteln zu löten (also kein BGA o.ä.)


    sehr schön wäre, wenn man das einfach über SPI ansprechen und auch kaskadieren könnte, ohne großartig umständliches Protokoll


    ich hab' mir schon nen Wolf gesucht, aber finde einfach nix - evtl. ist ja jemand schon mal über so was gestolpert...?

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    Einmal editiert, zuletzt von Pesi ()

  • Hallo Pesi,


    was dem wohl am nächsten kommt, sind die ICs der Reihe MAX696x, welche eine 8x8 Rot-Grün-Matrix ( 16 x 8 ) direkt ansteuern können (inkl. Scanning), allerdings leider nur mit max. 4 Helligkeitsstufen pro Farbe und Pixel und nur grüne LEDs mit weniger als 3 V Vorwärtsspannung (die eher gelb-grünen LEDs), wobei die meisten Rot-Grün-Matrix-Teile wohl mit solchen LEDs ausgestattet sind.
    Wie alles von MAXIM integrated sind auch diese ICs bei kleinen Stückzahlen eher teuer.


    Sonst gibt's natürlich immer die Option, es mit einem 'normalen' 16-Kanal-Konstantstrom-PWM-Treiber zu machen und das Scanning der Zeilen/Spalten von einem kleinen µC abarbeiten zu lassen (inkl. Verwalten eines internen Bildspeichers). Der µC kann dann natürlich auch als SPI-Slave etc. fungieren. Das geht natürlich nur, wenn neben dem LED-Treiber-Chip auch noch Platz genug für einen µC ist.


    Gruss
    Neni

  • Hi Neni,


    vielen Dank für die Antwort! - Habe die leider gerade erst gesehen, im neuen Forum funktioniert das mit dem Benachrichtigen irgendwie nicht so wirklich...


    ich tendiere mittlerweile dazu, das gleich direkt mit nem µC zu machen (und halt noch Transistoren und ULNs dran). Das muss schnell gehen und darf nicht zu viel kosten, ich habe i.M. auch keine Zeit, mich mit der Multiplex-Ansteuerung so eines Chips zu befassen. Entweder soll ein Chip ganz easy alles selbst machen, oder ich mach's gleich komplett mit nem µC in SW.


    SW-mäßig ja kein Problem, einfach Multiplexen mit PWM, 64 Helligkeitsstufen bekomme ich da vernünftig hin, das reicht hier... ist praktisch schon fertig, halt nur für 5x8 statt 8x16...


    ich würde dann so kleine Platinen machen, die sozusagen den gesuchten Chip "ersetzen" - bei dem ganzen geht es um einen Prototypen für einen Freund, da spielt die Größe keine so entscheidende Rolle (wenngleich es auch nicht zuu groß werden soll) - ich mach' praktisch senkrecht angesteckte Platinen hinter jedes Matrix-Modul, die dann später durch einen passenden Chip (oder wie auch immer) zu ersetzen, ist dann das Problem seines Kunden.


    Hier noch ne Frage: Es handelt sich um solche Module hier: http://www.lipoly.de/index.php…jkvr8pu5a3unngq98q6mh5dc4


    Der Verkäufer hat nur noch drei Stück auf Lager, wir brauchen aber mind. 60 :D - telefonisch ist der leider gerade nicht erreichbar, dann 2 Wochen im Urlaub - und wir brauchen das Zeug schnellstmöglich. Also wenn jemand ne andere, schnelle Bezugsquelle für genau so Teile weiß... ;)


    Um diese Ansteuer-Platinen senkrecht auf die Basisplatine (die dann nur 30 so LED-Module und Steckverbinder enthält) brauche ich auch noch nen passenden Steckverbinder - also so was wie diese Stift- und Buchsenleisten z.B.


    Wegen der Breite kann ich aber für die 24 Pins keine 2x12 nehmen, bräuchte also eher ne dreireihige Stift-/Buchsenleiste mit 24 Pins - finde leider aber generell nur 2-reihige Leisten - kennt da jemand was passendes..?

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    Einmal editiert, zuletzt von Pesi ()

  • Neue Idee: Mir ist gerade aufgefallen, ich bin dem Irrtum aufgesessen, dass ich pro LED-Modul dann einen µC und einen 'normalen' 16-Kanal-Konstantstrom-PWM-Treiber bräuchte.


    Aber das ist ja gar nicht der Fall! - Pepe hat auf seiner Matrix-Platine ja auch 3 TLC5940 (oder so) an einem µC und 8 FETs zum Multiplexen.


    Im Prinzip könnte ich ja auch die ganze Matrix mit einem µC und 30 TLC erschlagen - wenn ich da die Daten schnell genug rein bekomme, um das noch multiplexen zu können.


    oder, Kompromiß, ich mache eine lange Platine je 10 Module (die Matrix ist 10 x 3 Module groß), also je Platine 1x µC, 8x Fet, 10x TLC5940 - könnte hinhauen, 10 so ICs in Assembler zu befüllen statt 3 ICs in C... (?)


    der Gedanke gefällt mir nun ganz gut - ist dann auch flexibler, man kann für andere Anwendungen (Laufschrift o.ä.) dann z.B. auch ne Matrix mit 30 Modulen nebeneinander machen statt 3x10...


    und da sind dann auch die Steckverbinder kein großes Problem mehr, da ich ja die 8 Rows nur 1x für alle 10 Module rüber führen muss, und dann nur noch 2x8 Columns je Modul... ;)


    und als netten "Nebeneffekt" auch noch Konstantstrom und deutlich mehr Helligkeitsstufen :thumbup:


    bleibt nur die Frage, ob ich das schnell genug programmiert bekomme - wenn ich den Thread von Pepe richtig verfolgt habe, muss das ja recht tricky sein, die Dinger zu multiplexen...?

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Hallo Pesi, hier mal drei Alternativ-Verkäufer solcher 20 mm Rot-Grün Matrix-Elemente, welche ich auf die Schnelle ergooglen konnte:
    http://www.elecrow.com/display…color-redgreen-p-243.html
    http://www.emartee.com/product/41411/20mm 8*8 Square Matrix LED Red&Green
    http://www.aliexpress.com/stor…MM/829429_1137867408.html


    Was die Ansteuerung von TLC5940 inkl. Multiplexing angeht, so würde ich persönlich GS-Clock und SPI-Clock zusammenlegen (natürlich mit Buffern). Dann schickst du einfach einen Stream mit einer entsprechende Anzahl an Dummy-Bytes (z.Bsp Wert 0) und am Schluss des Streams die eigentlichen Daten (für die nächste Zeile) pro Zeile per SPI, so dass sich insgesamt 4096 Bits (also automatisch auch 4096 Clocks) ergeben, bevor du XLAT und BLANK aktivierst und die Zeile umschaltest, dann wieder von neuem etc. Das würden also 512 Byte SPI-Daten pro Zeile sein, wovon aber nur die letzten ( (n x 192) / 8 ) Byte im SPI-Stream die eigentlichen Daten wären, der Rest sind Dummy-Daten.


    Gruss
    Neni

  • Vielen Dank, Neni, für die Links und Tipps!


    ich habe die Beiträge mal in nen eigenen Thread verschoben, um den allgemeinen Frage-Thread nicht zu arg zu zerreissen... ist evtl. auch für andere Interessant, wenn's für meinen Kumpel OK ist, stelle ich dann auch die fertigen Layouts für das Teil zum nachbauen rein...


    Wenn ich das richtig sehe, muss ich für den TLC5940 selbst den Clock für die PWM erzeugen..?


    ich habe das Prinzip verstanden, mit den 512 Byte: die ergeben ja 4.096 Bit, also einen PWM-Zyklus - in meinem Fall (10 Stück TLC5940 kaskadiert) schicke ich also 272 Dummy-Bytes nur zum Clock erzeugen, und dann die 240 eigentlich genutzen Bytes hinterher...


    schade, das geht sich dann um ein "paar" Byte nicht aus, dass ich gleich alle 30 TLCs kaskadiere, das wären dann insg. 720 Byte - oder siehst Du da ne Möglichkeit, z.B. ich zähle mit, nach 512 Bytes (kompletter PWM-Zyklus durch) schalte ich blank, und schiebe die restlichen 208 Byte bei ausgeschalteten LEDs "hinterher".


    wobei ich natürlich nochmal 29% "Leuchtzeit" verliere, und die Dinger sollen eigentlich möglichst hell sein... aber praktisch wäre es schon, nur Platinen mit TLCs und Fets drauf, und das ganze von einem SEDU angesteuert...


    Mein Problem bei der ganzen Ansteuerung (was aber kein so großes sein kann, beim Pepe funktioniert das ja auch): ich habe 4.096 PWM-Takte - das mal 8 (8 Zeilen gemultiplext) und ne vernünftige Refresh-Rate von 100 Hz für das ganze Display ergibt dann 3.2768.00 Hz - mit bisschen "Verlust" für's Umschalten wäre dann 4 MHz SPI-Takt angesagt.


    bei nem µC mit 20 MHz Takt also 5 Takte pro Bit, Bitbanging kann man da vergessen - mit dem HW-SPI sollte es zu schaffen sein, sind ja dann 40 Takte pro Byte... abzgl. bisschen Verlust für rein und raus bei der "SPI-fertig"-ISR... aber eng wird's wohl schon, muss ja auch noch Bitschieberei dazu wegen den 12 Bit...


    und ich muss aber auch noch Daten empfangen, wohl auch in ner ISR - das könnte dann schon sichtbaren (?) Jitter geben, wenn der PWM-Takt dann schwankt - oder meinst Du, das fällt gar nicht weiter auf, wenn bei 4.096 PWM-Ticks mal 4, 5 bisschen länger sind...?


    Das größere Problem: Das ganze soll von nem Arduino angesteuert werden - da bei dem der USART ja schon "intern" belegt ist, kann ich also die Daten nicht seriell zu meinen Boards schicken, die sollten idealer Weise da auch per SPI hin gelangen - aber der HW-SPI ist ja bei mir schon belegt...


    Man kann doch den USART auch als SPI "missbrauchen", wenn ich das richtig in Erinnerung habe..? - würdest Du den dann eher zum Daten empfangen nutzen, oder zum raus schicken..?


    Das Ganze wird eh' ne rechte Herausforderung, einfach weil die LED-Module so klein sind (20 mm x 20 mm) - da bleibt zwischen den Pins kaum noch Platz für die Row-Leiterbahnen (die ja doch recht breit sein müssen bei dem Strom) und dann auch noch Steckverbinder...


    ich tendiere dazu, das Ganze auf 3 Platinen aufzuteilen, die dann auf die drei Pinreihen der Module gesteckt werden - Vorteil: ich brauche gar keine "Basisplatine" mit 10.000 Löchern. Und kann diese Platinen selbst ätzen und bestücken, weil gar nicht soo viel drauf/eng bestückt.


    Also praktisch "oben" ein Board mit TLCs für grün, in der Mitte eins mit 8 FETs für die Zeilen, und "unten" ein Board mit den TLCs für Rot...


    da brauche ich dann aber Buchsenleisten mit 2,4 mm Rastermaß (so sind die Pins an diesen LED-Modulen) - k.A., ob's so was gibt..?! - wobei, notfalls sollte es auch mit 2,5 mm gehen, die Pins sind ja recht lang, das biegt sich dann schon so hin... habe ich aber auch noch nicht gefunden, nur 2,54 mm und 2 mm....

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Hallo Pesi,


    ich würde bei den 10 Modulen in Serie (x 3) bleiben oder unter Umständen noch weiter aufteilen, z.Bsp. 5 Module in Serie (x 6). Alle 30 Module in Serie wären meiner Meinung nach auf jeden Fall zu viel von der für eine Zeile benötigten Zeit her.


    Da du per BLANK (schaltet die Ausgänge aus und resettet den Counter) ja den Counter des TLC5940 grundsätzlich selbst kontrollierst und der TLC5940 ja klassische PWM (also nicht ES-PWM oder sowas) macht, kannst du prinzipiell auch jede beliebige PWM-Tiefe (PWM-Clocks) pro Zeile realisieren, wobei sinnvollerweise ein Wert teilbar durch 8 (wegen SPI) und grösser oder gleich der maximalen Bitzahl der Zeilendaten gewählt werden sollte.
    Bei 10 Modulen in Serie hast du 1920 Bit Zeilendaten, also würde sich eine 11-Bit-PWM (also 2048 PWM-Clocks) anbieten. Da müsstest du dann nur noch 16 Dummy-Bytes vor den 240 Datenbytes via SPI pro Zeile schicken. Da kannst du entweder bei 4 MHz SPI bleiben und bekommst die doppelte Bildwiederholrate oder du nimmst 2 MHz SPI und gewinnst dafür Verarbeitungszeit.
    Bei 5 Modulen in Serie könntest du sogar eine 10-Bit PWM verwenden und würdest dadurch noch höhere Bildwiederholraten bzw. mehr Verarbeitungszeit gewinnen.
    Klar ist, dass in beiden Fällen die PWM-Daten entsprechende Maximalwerte dann nicht überschreiten sollten, also 11 Bit bzw. 10 Bit, obwohl die Registerbreite pro Wert 12 Bit zulässt.


    Bezüglich USART, ja, bei gewissen AVRs kann man soweit ich mich erinnern kann (mache nicht mehr so viel mit AVRs sondern mehr mit ARM Cortex Ms) den/die USART(s) in einem synchronen Modus betreiben, was glaub ich dann kompatibel zum SPI ist, aber da musst du dir die jeweiligen Datenblätter dazu mal ansehen.


    Gruss
    Neni

  • Danke erneut!


    Das Thema USART hat sich wohl erledigt, mein Kumpel nimmt nun so nen Arduino Due, irgendwas ARM mit 84 MHz, der sollte das dann alleine schaffen, ohne noch mal nen µC dazwischen...


    ja, hatte auch schon überlegt, mit der PWM-Tiefe runter zu gehen, es reichen eigentlich sogar 64 Stufen... mache wohl 256, dann braucht man auch nicht in ner log-Tabelle nachgucken oder sowas... einfach nur die 8-Bit-Werte von der Anwendungs-SW nehmen.


    schade nur, dass man das Input-SR nicht in der Bitbreite umschalten kann - könnte man den Chip z.B. auf 8 Bit "einstellen", dann würde man sich die Bitschieberei wegen den 12 Bit/Kanal auch sparen...


    wegen der Ansteuerung: Ich mach' ja sowieso einzelne Platinen mit je 5 TLC drauf und Data in/out - dann kann man immer noch später entscheiden, ob man die nun parallel füttert (also 6x je 5 TLCs) oder je 2 zusammen hängt, oder alle 30 TLCs kaskadiert... ;)

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Es gibt von Macroblock Treiber für so LED-Display-Module.
    Die neuen haben direkt SRAM an Bord und können so nach einmaligem Befüllen die Matrix selber updaten.
    Das alles mit erweiterter PWM (niedrige Werte werden über den Frame gestreckt und randomisiert). So muss man sich nciht selber um die PWM kümmern und vor allem nicht um das 1/16 Scan Update des Moduls.
    Auf Aliexpress kann man die ICs auch kaufen, Modulhersteller die die Teile einsetzen habe ich leider bisher nicht gefunden.


    Die entsprechenden ICs wären MBI5050 bis MBI5053.
    http://www.mblock.com.tw/products.php?KindID=1&ID=92
    Die unterscheiden sich glaube ich nur in der Anzahl der maximalen Scanlines die in den RAM passen.

  • Danke für den Tipp - aber wenn ich das richtig sehe, ist der einzige Vorteil der, dass die mehrere Zeilen intern puffern können, und ich dann praktisch nur umschalten muss, welche Zeile engeziegt werden soll...?


    schade, verstehe ich nicht, wenn die eh' schon die ganze Matrix intern puffern, warum kümmern sie sich nicht um das multiplexen auch noch selbsttätig..?!


    wäre ja wohl nicht viel dabei gewesen, und dann wäre das genau der gesuchte Chip: Einfach nur Daten rein kloppen und das Teil steuert die Matrix vollständig autark an - ein Chip hinter jedes LED-Modul, fertig...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Die Dinger brauchen einen globalen Takt für die PWM und dann noch Zeilenwechsel glaube ich.
    Bedenke, dass die Treiber für riesen Modulwände gedacht sind, da wird einiges an Aufwand in Sync und Anti-Flicker investiert.


    Die ICs sparen aber schon massiv Bandbreite ein, man muss die Inhalte ja nur noch 1x übertragen und nichtmal PWM-Zyklen berechnen - das machen die dann für dich, insofern hast du eine Ersparnis von PWM-Zyklen_pro_Frame - 1 insgesamt - also nur noch ein 255stel bzw. weniger an Daten.

  • Kleines Update: Ich habe mich nun doch für die TLC5940 entschieden, weil mir schon bekannt... sind nun auch schon 100 Stück da ;)


    Das mit der Bandbreite stimmt schon, ist nur für mich nicht wirklich ein großer Vorteil - ich muss ja irgendwie den PWM-Takt erzeugen, und zwar so, dass mir im µC bekannt ist, wo der gerade steht.


    Deswegen finde ich die Idee von Neni nach wie vor ganz gut, da gleich den Takt vom HW-SPI für zu nehmen. Und dann ist's ja egal, ob ich nur ein Dummy-Byte zum Takt erzeugen raus schicke, oder ein Byte mit Nutzdaten.


    Der Plan ist nun, doch alle 30 Module in Reihe zu hängen, um nur einen SPI zu benutzen.


    Das Problem mit der Bit-Anzahl (die ja bei dieser Methode nicht für 30 Module reicht) umgehe ich einfach in HW: Ich hänge SCKL und GSCKL nicht direkt zusammen, sondern teile den Takt vom SPI durch zwei, der kommt dann an Greyscale Clock.


    So habe ich die doppelte Anzahl Bits zum rein schieben zur Verfügung, bis ein PWM-Zyklus durch ist, das reicht dann.


    Also 8.192 SPI-Takte (^= Bits) macht dann 4.06 PWM-Takte, also ein Zyklus - bei 192 Bit pro TLC kann ich somit 42 Stück in Reihe hängen.


    um weiter bei 100 Hz Refresh zu bleiben (siehe Rechnung oben) muss ich dann den SPI-Takt auf 8 MHz erhöhen - das sollte ja auch kein Problem sein bei dem Arduino mit dem ARM... der kann wahrscheinlich eh' die Zeile per DMA raus schieben und muss sich dann erst beim Zeilenwechsel wieder um das Display kümmern...


    Klingt das plausibel, oder habe ich nen Denkfehler irgendwo....? - was wäre denn ein geeignetes Flipflop zum Takt teilen, das die Geschwindigkeit sicher mitmacht..?

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Hoi Pesi,


    ich denke, das sollte so stimmen wie du es berechnet hast. Mit 8 MHz SPI-Clock (also 4 MHz GS-Clock) dürftest du auf 122 Hz Display-Refresh-Rate kommen. Wenn du die Daten mittels DMA zeilenweise rausschiebst, solltest du einen Ping-Pong-Puffer für das gesamte Display im Arduino-ARM implementieren (Platz genug dürfte dieser haben) und jeweils den Puffer bei Vertical SYNC und wenn neue Daten für ein ganzes Bild in den anderen Puffer geschrieben worden sind switchen. Dies vermeidet Tearing-Effekte, erfordert aber, dass die Frame-Rate (wenn nicht synchron zum Refresh) deutlich niedriger ist als die Refresh-Rate, um sichtbare Ruckler zu vermeiden, also bei 122 Hz Refresh ca. bis 30 Hz Frame-Rate.


    Gruss
    Neni

  • Neni, danke für die Bestätigung! - einen wirklichen "Refresh" wird es da erst mal gar nicht geben, da soll nur ab&zu mal ein anderes Bild dargestellt werden, wenn's da nen kurzen Moment flackert/Doppelbild gibt, ist's auch nicht schlimm...


    das ganze ist i.M. nur eine Designstudie - umsetzbar ist das in der Art dann sowieso nicht, das Display soll in ein flaches Gehäuse, ähnlich wie iPad, und das alles mit Akku betrieben werden.


    Es ist nun aber ca. 4,5 cm "dick" (LED-Module mit Platinen hinten dran), und das ganze Display zieht bei alle Pixel an 60 A :whistling: - da wird zwar nur Text dargestellt, also ca. 1/5 der Pixel an, und meist entweder rot oder grün, also dann ca. 6 A, aber mit nem flachen kleinen Akku läuft das bestimmt auch nicht die geforderten 8 Stunden :P


    das ist uns aber egal - ob/wie das dann im endgültigen Produkt überhaupt umgesetzt werden kann, ist deren Problem - das scheitert wahrscheinlich schon an den Kosten...


    will damit nur sagen, soo supertoll geschmeidig muss das gar nicht laufen, ist nur ne Art Demo - aber trotzdem danke für den Tipp mit dem doppelten Buffer, werde ich meinem Kumpel weiter geben (der programmiert das dann).


    Basti: Unabhängig davon, wüsstest Du denn nen Chip, mit dem man easy so ne Matrix mit 32 Stufen ansteuern kann..? - evtl. ist das ja auch mal für andere Projekte interessant (oder wenn die doch von uns ne kleinere/billigere Lösung haben wollen...)

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • @Pesi ich meinte einfache Schieberegister, wo die LED nur an und ausgeschalten werden kann... muss man sich seine PWM also selbst machen... hat TI in auch seiner Reihe im Angebot... scheint es aber auch günstiger von den Chinesen zu geben... siehe Beitrag: Jumbotron 16x32 Pixel RGB-Matrixen flott ansteuern...
    Hätte an der Stelle auf meinen Blog verwiesen, weil dort recht viel Quellcode einfach übernommen werden kann und ich im Grunde das ganze erst neulich angesteuert habe: sebastianfoerster86.wordpress.com


    Die Panels gibts in unterschiedlichem Pixelabstand und kosten fast nichts... hast halt noch die Farbe Blau drin... aber wenns dann günstiger wird?!


    Grüße


    Basti

  • Danke für den Tipp, habe den Thread auch schon verfolgt...


    bringt mir aber hier nix, es geht nicht darum, ein LED-Display möglichst günstig zu bauen, sondern eben genau dieses R/G-Display mit diesen Modulen (20 mm x 20 mm) für einen Kunden, der das genau so haben will...


    da hatte ich anfangs auch schon dran gedacht, das notfalls komplett in SW zu machen, also pro Modul ein µC drauf, der halt SW-PWM und Multiplexing macht, 64 Stufen wären da auch kein Problem (hätten ihm auch gereicht), im Prinzip das selbe wie hier...


    wäre aber zu groß und aufwändig geworden, je Modul ein µC und dann auch noch ULN etc. dazu...


    simples SR habe ich dann gleich verworfen, wenn ich auch gleich ein SR nehmen kann, das PWM erzeugt ;) - und auch noch genug Strom liefert (eben den TLC5940)


    die Jumbotron-Dinger sind aber echt interessant, werde mir evtl. auch mal welche zulegen - ich warte noch auf Rückmeldung von Larkin, der war vor paar Wochen mal hier und hatte solche Pixelplatinen von APA da - auch so ca. DIN-A4-Größe, mit 512 LEDs


    die wären mit ca. 30-40 Euro/Stück zwar deutlich teurer als Euere, aber dafür in der Ansteuerung wesentlich einfacher, weil ja komplett mit APA-LEDs bestückt. Also nur serielles Signal durchjagen...


    Wenn man zusätzliche HW und den Aufwand dazu rechnet (Zeit ist halt das, was ich am wenigsten habe), für mich dann unter'm Strich wohl sogar trotzdem günstiger...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!