Und wieder mal eine Matrix...

  • Hallo Leute,


    heute möchte ich euch meine neue RGB Matrix vorstellen. Es gibt hier ja schon den ein oder anderen sehr guten Matrixthread, jedoch glaube ich, dass hier noch niemand eine Matrix mit WS2811 -Chip/-Protokoll vorgestellt hat. Das will ich nun ändern. Aber erst einmal genug der Worte, hier ein paar Fotos und ein Video:







    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    (Entschuldigt die schlechte Videoqualität aber mein Equipment gibt einfach nicht mehr her)



    Und nun zu den Details:



    LEDs:


    Die Besonderheit an meiner Matrix sind die verwendeten LEDs. Es handelt sich hierbei um RGB- LEDs mit integriertem WS2811- Treiber. Diese habe ich vor ein paar Monaten bei einer Sammelbestellung aus China auf Mikrocontroller.net mitgeordert. Zu meiner Freude konnte ich aber feststellen, dass die LEDs mittlerweile auch ihren Weg in einige Shops von Forenmitgliedern gefunden haben. Zudem werden sie auch schon recht zahlreich in der Bucht angeboten. Der Vorteil dieser LEDs ist, dass quasi keine zusätzliche Hardwarebeschaltung nötig ist um sie zu betreiben. Eine LED verfügt über lediglich je einen Data_In und Out Anschluss sowie 2xVCC und 1x Gnd. Zwischen VCC und Gnd sollte man noch einen 100n Stützkondensator vor jede LED setzen. Den Data_In – Anschluss der nächsten LED wird einfach mit dem Ausgang der vorherigen verbunden usw. , sodass es im Prinzip am Ende eine lange Kette ergibt.



    Das Thema Helligkeit ist ja immer sehr subjektiv. Daher kann ich nur sagen, dass ich die Leuchten subjektiv sehr hell finde und sie schon sehr arg blenden wenn man denn direkt reinguckt. Testweise habe ich auf einen LED mal einen Tischtennisball als Diffusor gesetzt um das ganze etwas objektiver betrachten zu können. Als Vergleich diente mir meine andere Matrix bei der folgende Dioden verwendet wurden.
    Fazit: Beide gleich hell. Laut Beschreibung* gönnen sich die LEDs voll angesteuert 3x 20mA. Das würde bei meinem jetzigen Aufbau mit 80Px also ca. 5A machen. Leider kann ich das nicht nachprüfen, da mein Multimeter nicht mehr ganz vertrauenswürdig zu seien scheint.



    *Das ist bis jetzt das einzig negative, was ich über die Dioden sagen mag: Es gibt scheinbar nirgendwo ein offizielles Datenblatt...



    Platinen:


    Den Schaltplan und Platinen habe ich mit Eagle gemacht. Ein Modul ist 5x5cm² groß und besitzt 4 Pixel (Pitch = 2cm). Zur späteren Montage verfügt
    jedes Modul über eine 3mm Bohrung in der Mitte. Des weiteren verfügt das Modul rechts über eine 4-polige Stiftleiste, links über die entsprechende Buchse, Diese Anschlüsse „transportieren“ die Versorgungsspannung sowie Data_In und _Out. Oben und Unten gibt es nochmal einen 2-polige(n) Stecker/ Buchse für VCC und Gnd. Wie man auf den Fotos sehen kann lassen sich die Platinen so nahtlos zusammenstecken.


    Was man auf den Fotos und Videos nicht so gut sehen kann ist, dass man am Ende jeder Zeile einen Jumper setzen muss der das Signal an die untere Zeile weiterreicht. Bei mehr als 2 Zeilen müssen ebenfalls auf der linken Seite das Data_Out eines Moduls mit dem Data_In des darunter liegenden Moduls verbunden werden.


    Die Platinen habe ich bei Itead herstellen lassen. 20 Stück für knapp 20€ inkl. Versand, da kann man nicht meckern, zumal ich auch mit der Qualität und Lieferdauer (ca 1 Monat ab Bestellung) sehr zufrieden bin.



    Software/ µC:


    Die eigentliche Effektgenerierung erfolgt mit Glediator. Die Daten werden im TPM2- Protokoll per USB- UART- Wandler mit 1Mbit an einen ATMega328P
    weitergereicht. Für den Moment ist dieser Teil der Schaltung nur auf Lochraster realisiert. Wobei die Schaltung eigentlich nur aus µC, Quarz, 3 Kondensatoren und einem ISP- Anschluss besteht.


    Die Software ist in ASM geschrieben und ist zum Download angehängt. Die TPM2- Empfangsroutine stammt von Pesi und wurde ursprünglich für das
    SEDU- Board geschrieben (Danke nochmal dafür) . Diese habe ich noch dahingehend modifiziert, dass ich auf die eingehenden Daten eine Gammakorrektur durchführe. Nach einigem Testen sieht diese nun so aus, dass die Helligkeitswerte 0-127 linear umgewandelt werden ( Werte werden mit 0,44 multipliziert), die Werte 128-255 werden mit einer Potenzfunktion[(255* ( X /255) ^ 2,2) + 0,5] umgewandelt.
    Da die Umwandlung nur im 8- Bitraumstattfindet, gehen mir dabei ca. ein Viertel der möglichen Stufenverloren. Jedoch konnte ich rein subjektiv betrachtet keinen wirklichen Unterschied zu meinem Nachbau von Pepes Matrixschaltung erkennen, bei der die Umwandlung von 8 Bit auf 12 Bit stattfindet.


    Weiter geht’s mit der Ausgaberoutine. Die Art und Weise wie die WS2811Controller ihre Daten bekommen wollen ist gar nicht so trivial und
    waren letztendlich auch der Grund warum das ganze in Assembler geschrieben wurde. Es gibt nämlich wie bei anderen LED- Treibern z.B. WS280x, TLC5940 etc. keine Taktleitung. Dies macht jedoch die Ansteuerung komplizierter, da hierbei ein festes Timing
    eingehalten werden muss. Kurz erklärt für eine logische „0“muss zuerst ein 250ns Highpegel gefolgt von einem 1µs Lowpegel „gesendet“ werden. Für eine „1“ 600ns High und 650ns Low.Nach diesem Schema müssen nun die (3*8 Bit pro Pixel) *Anz. Px gesendet werden. Ist dies geschehen, so folgt ein min. 50µs langer Lowpulse damit die Daten übernommen werden.



    Ausblick:


    Als nächstes muss ich mich mit den theoretischen Grenzen, sprich max.Pixelzahl, beschäftigen. Will ich alle Daten puffern, so würde der µC theoretisch ca. 670 Pixel (Anz. Px *3 <=2kB SRAM) zulassen aber ich denke nicht, dass das bei einer Framerate von 21 /s machbar ist. Wie ich das theoretisch ausrechne ist mir, denke ich klar aber falls jemand Ideen hat, wie ich das ganze auch in der Praxis testen könnte, ohne 100*X Pixel anzuschließen (weil soviele habe ich garnicht ;) ) wäre ich darüber sehr dankbar.


    Zudem denke ich darüber nach dem µC vielleicht noch das ein oder andere Standaloneprogramm zu spendieren, denn bei bisweilen 2,2% benutztem Flash ist da noch reichlich Platz aber das ist erstmal Zukunftsmusik.



    Und nun bin ich auf euer Feedback gespannt!
    drs


    EDIT: Da ich drum gebeten wurde hier noch ein paar weiterführende Links zu den LEDs:
    Link1
    Link 2
    Link3
    Link4

  • Hi drs!
    Bin zwar keiner der Matrix-Bauer, und kann daher zur Ansteuerung etc nix sagen, außer, dass sich augenscheinlich der Bauteil- bzw. Lötaufwand bei diesen PixelLEDs tatsächlich sehr gering zu sein scheint. Womit man das bezahlt, kann ich aber nicht überblicken.


    Was mich aber stutzig gemacht hat ist folgende Aussage zur Platine:

    Ein Modul ist 5x5cm² groß und besitzt 4 Pixel (Pitch = 2cm). [...] Wie man auf den Fotos sehen kann lassen sich die Platinen so nahtlos zusammenstecken.

    Meinst du mit Pitch den Abstand zwischen zwei zueinander gewandten LED-Gehäusekanten? Dann passt das. Mit Pitch wird doch aber idR eher den Abstand zwischen den Mittelpunkten angegeben (?), dann müsste es 2,5cm Pitch heißen.


    Gruß,J

  • Hallo,


    schon schick mit diesen neuen LEDs mit Controller (Ws2811)... spart richtig Aufwand!


    Aber das Platinendesign sollte evtl. nochmal überarbeitet werden... Ich hatte hier mal nen paar Ideen zur Umsetzung gegeben:
    Matrixsystem, Vorstellrunde...


    Dann brauchst du auch keine Jumper mehr außerdem fließt bei größeren Matrizen so einiges an Strom... gut, da weiß ich nicht ob das überhaupt Ziel deines Designs war, aber Platz für ordentliche Leiterzüge (Flächen) sind ja noch vorhanden, wenn ich das so sehe.


    Ansonsten schick... ich steh auf Anreihbar... schön flexibel... :thumbup:


    Grüße


    Basti

  • Moin moin,


    Juisoo
    Ja wenn man den Abstand von Zentrum einer LED zur nächsten nimmt sind es 2,5cm das ist richtig.


    Counterfeiter
    Ja was die Stromversorgung angeht (theoretisch) berechtigte Kritik ABER ich hab just bemerkt, dass ich euch die Rückseite der Platine vorenthalten habe. Habe davon nun noch im ersten Beitrag ein Foto eingefügt. Die Leiterbahn ist VCC, Rest ist Masse. Die weitere Stromverteilung ist wie bei dir gelöst, sprich ein VCC + GND Anschluss in jede Richtung.
    Wenn ich dein Design richtig verstehe, führst du auf der Oberseite quasi komplett VCC und auf der Unterseite Masse. Entsteht dadurch nicht ein riesiger Kondensator? Zudem sind doch die Pinheader (und nicht nur die Buchsen) in der Regel auch nur bis 3A spezifiziert?! Daher versteh ich die Verwendung der Schraubklemmen nicht so ganz (abgesehn von den ganz klaren Stailitätsvorteilen im Vergleich zu Buchsen)


    Und zum Thema Jumper:
    Man muss nicht auf jeder Platine irgendwelche Jumper setzen. Lediglich am Ende einer Modulzeile muss Data_In mit _Out verbunden werden. Hat man nun vor eine Matrix mit fester Größe zu bauen, kann man dort auch einfach eine Lötbrücke hinsetzen und gut ist. Dann bleibt einzig nur ein Kabel um die 2te Zeile eines Moduls mit der ersten Zeile des darunterliegenden Moduls zu verbinden. Also bei einem N zeiligen Display N/2 - 1 Kabel...



    So außerdem habe ich mich heute mal an das Ausrechnen der maximalen Pixelanzahl gemacht. Und siehe da, es scheint tatsächlich doch der SRAM die beschränkende Größe zu sein. Dies führt zu einer maximalen Matrixgröße von 26x26 bzw 676 Pixel! Um auf der sicheren Seite zu sein, bin ich bei der Berechnung extra von 30 Frames/s ausgegangen. Nichtsdestotrotz bin ich immer noch über Vorschläge dankbar, wie man das mal in der Praxis testen könnte ohne die wirkliche Anzahl Pixel anzuschließen.


    Gruß

  • Hallo!


    Ein paar Vorschläge zu Deinem Design (das ich sehr schick finde)


    - Wenn Du Streifenplatinen anstelle von quadratischen verwendest, kannst Du eine Menge Platinenfläche (und damit Kosten) sparen!


    - Kondensator zwischen VCC und GND Lage: Das wäre ja durchaus positiv, quasi ein Extra Stützkondensator! Aber rechne das mal aus, mit dem Abstand von 1,6mm kommt da nicht viel bei 'rum... Soweit ich weis kann dieser Effekt aber durchaus bei Multilayer Platinen konstruktiv genutzt werden, dort sind die Innenlagen deutlich dichter beieinander!


    - Ich würde vielleicht noch einen größeren (Größenordnung 10 uF) Kondensator vorsehen (Tantal, Elko, ggf. auch Keramik), denn wenn Du viele Module aneinanderreihst, und dann impulsmäßig 5A durch die Kette schieben musst (Strobo), wird den kleinen Kerkos vermutlich die Puste ausgehen, und unter Umständen bekommst Du dann unschöne Effekte ins Spiel... Musst diesen ja nicht auf jeder Platine bestücken, aber auf Nummer Sicher... :)


    - Maximale Pixelzahl: Du kannst das auch problemlos mit wenigen Pixeln testen! Schieb' einfach die maximale Zahl an Daten durch die Kette durch! Das meiste "fällt" dann zwer hinten beim letzten Pixel raus, aber die ersten Pixel wissen davon nichts! Du kannst also die maximale Widerholrate direkt an den ersten paar Pixeln testen?


    Pixelige Grüße
    Andre

  • auf der Oberseite quasi komplett VCC und auf der Unterseite Masse. Entsteht dadurch nicht ein riesiger Kondensator?


    Ja, ist nen schöner Nebeneffekt... aber wie 2bl schon sagt. Die Fläche ist riesig, aber die Kapazität wohl eher nicht. Macht nix... trotzdem gute und gern benutzte Technik.


    Ja diese Pins sind aus Messing oder weiß der Geier. Jedenfalls steht es um die Leitfähigkeit und Querschnitt nicht so schlecht wie du vielleicht denkst. Das Problem bei der Stromübertragung ist einfach nur der "luschige" Kontakt der einen hohen Widerstand auf einer kleinen Kontaktstelle erzeugt und damit bei großen Strömen zu Problemen führt. Ich kann das mit den Schraubklemmen uneingeschränkt empfehlen. Hab da nen paar Tests gefahren und 20 A mit einer Einspeisestelle ist schon ne Hausnummer. Es gibt natürlich auch deutlich bessere Kontaktsysteme auch für "Hochstrom" nur leider bezahlt man sich da arm, gerade bei der Masse die man braucht.



    Ach, da ist die Unterseite. Na schaut doch gar nicht so schlecht aus... Oben kannste aber ruhig auch noch ausfüllen. Viel hilft viel und schont gleich noch die Umwelt, weil die ihr Ätzbad nicht so schnell altert,,,


    Grüße


    Basti

  • Hmm irgendwie habe ich total verdrängt das dieser "parasitäre" Kondensator ja gut ist ;)
    naja aber wie gesagt wurde verschwindend gering. Für meinen Fall wären das für alle 20 Platinchen zusammen ganze 3,9 nF, vorausgesetzt Ober- und Unterseite wären noch komplett Kupferbeschichtet :D


    Ja Streifenplatinen sind/ wären schon ganz nett; da bin ich nicht drauf gekommen bzw würds ohne bestimmten Grund wieder so machen, außerdem hast du dich ja auch schon darum gekümmert, wenn ich das richtig gesehn habe ;)


    Und danke für den Tipp bzgl max. Pixelanzahl, manchmal kommt man selbst nicht auch solch trivialen Sachen, allerdings muss ich dafür die Software noch etwas anpassen. Da wird im Moment nur ein Byte eingelesen. Mit den dan max. 255 eingestellten Pixeln funktioniert es aber schonmal hervorragend.


    Und Platz für einen weiteren größeren Kondi und die Oberseite "fluten"werde ich beherzigen, falls ich nochmal Platinen ordern werde aber im Moment warte ich noch auf 20 Stück von Seedstudio, die ich schon Ende September bestellt hatte. Da ist aber erst mir ein Fehler unterlaufen und nun scheinen die intern auch noch eine paar Problemchen zu haben wenn man deren Website glauben schenkt.


    Gruß

  • allerdings muss ich dafür die Software noch etwas anpassen. Da wird im Moment nur ein Byte eingelesen. Mit den dan max. 255 eingestellten Pixeln funktioniert es aber schonmal hervorragend.

    Wie meinst Du das, "nur ein Byte eingelesen", von der tpm2-Framegröße....?


    da werden beide ausgewertet, es ist mit der Routine also möglich, bis zu 65.535 Bytes zu empfangen...


    bei der Ausgaberoutine hast Du ne alte erwischt, diese kann nur 255 Pixel ansteuern - da wäre es wohl besser gewesen, wenn Du gleich dieses Projekt hier umgebaut hättest auf den Mega328, da ist die Ausgaberoutine drin, die mehr als 255 Pixel ansteuern kann...


    und "ganz korrekt" wäre es eigentlich gewesen, auch die anderen verwendeten Dateien zu kennzeichnen, also so in der Art "Original von Pesi, modifiziert von drs" - nur ne Kleinigkeit, aber "gehört sich" einfach so... ;)


    was mich wundert: Dass das Ganze so läuft - Du deaktivierst ja während der Ausgabe der Daten die Interrupts komplett, d.H. in der Zeit können keine Daten empfangen werden, die Ausgabe dauert aber deutlich länger als 1 Byte empfangen, also gehen da Bytes verloren...


    klar, irgendwie kommen schon noch Daten durch, nachdem der Frame ausgegeben wurde, kann wieder ein neuer empfangen werden, wenn der dann komplett ist, wird er ausgegeben - aber der, der während des ausgebens rein gekommen ist, geht verloren, also solltest Du nur 10,5 fps Ausgabe haben statt 21...


    änder' das doch mal (bzw. nimm' halt gleich die Ausgaberuotine aus dem aktuellen Projekt), Du musst die Interrupts nur während der Zeit des High-Pulses deaktivieren, dann kann zwischen zwei Bits wieder ein neues Byte empfangen werden - k.A., warum Du das geändert hast...?


    diese Schieberei hier:


    Code
    ld		temp_R, Z+						; Rot aus RAM laden
    ld		temp_G, Z+						; Grün aus RAM laden
    ld		temp_B, Z+						; Blau aus RAM laden
    
    
    mov		temp1, temp_R					;Wandle RGB in GRB
    mov		temp_R, temp_G
    mov		temp_G, temp1


    ist auch unnötig, das war nur bei mir drin, weil man da mehrere Möglichkeiten zum Farben tauschen hatte - wenn's bei Dir fest Rot und Grün tauschen ist, kannst Du auch einfach die Farben gleich in der gewünschten Reihenfolge aus dem RAM lesen - spart wieder ein paar Takte:


    Code
    ld		temp_G, Z+						; Grün aus RAM laden
    ld		temp_R, Z+						; Rot aus RAM laden
    ld		temp_B, Z+						; Blau aus RAM laden

    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!

  • Ne ich meinte in der Ausgabe-Sub



    Das habe ich nun folgendermaßen umgeändert:


    Wobei mir gerade auffällt, dass das ja auch Mumpitz ist, denn Px_Anzahl ist in der Definitions.inc fest vorgegeben, d.h. es werden immer bspw. Daten für 256 Pixel ausgegeben, obwohl nur z.B. Daten für 128 Pixel per TPM2 empfangen wurden.


    Zitat

    und "ganz korrekt" wäre es eigentlich gewesen, auch die anderen
    verwendeten Dateien zu kennzeichnen, also so in der Art "Original von
    Pesi, modifiziert von drs" - nur ne Kleinigkeit, aber "gehört sich"
    einfach so... ;)

    Da kommt es drauf an wie du "verwendete Dateien" definierst. Ich hatte zu Beginn des Projekts ja schonmal in einem anderen Thread erwähnt, dass dies meine ersten Gehversuche in Assembler sind und mir dein Stil sehr gut gefallen hat. Daher habe ihn so übernommen. Bei der Ausgaberoutine muss ich dann aber doch zugeben, dass es wohl weniger Eigenleistung war als ich mir, bevor du es hier nochmal angesprochen hast, gedacht habe. Mea Culpa. Das war keine Absicht und wird in Zukunft korrigiert.


    Zitat

    was mich wundert: Dass das Ganze so läuft - Du deaktivierst ja während
    der Ausgabe der Daten die Interrupts komplett, d.H. in der Zeit können
    keine Daten empfangen werden, die Ausgabe dauert aber deutlich länger
    als 1 Byte empfangen, also gehen da Bytes verloren...

    Nein, das sehe ich nicht so. Es ist doch so, dass Glediator 25 mal die Sekunde einen Frame sendet. Also alle 40ms. Wenn ich jetzt richtig gerechnet habe dauert es aber nur 6,5ms (Worst- Case bei 676 Pixeln) den Frame zu übertragen, d.h. es bleiben 33,5ms die Daten auszugeben.
    Daher auch die Idee, während der kompletten Ausgabe die Interrupts zu deaktivieren. So verbrauche ich nur 1+1 Cycles während einer "Frameausgabe", wohingegen bei deiner Idee bei jedem Bit 2+2 Cycles verbraucht werden also ganze N*24*(1+1) Takte je nach Framegröße bzw Pixelanzahl.


    Soweit die Theorie, praktisch sieht es nun so aus, dass ab ca 600 Pixeln teilweise Daten sporadisch "verschluckt" werden, dadrunter läuft aber alles flüssig. Daher habe ich mir überlegt einfach eine willkürliche Grenze bei 512 Pixeln (was einer 32x16 Matrix entspricht) zu setzen ;)



    Und dann hätte ich nochmal eine Frage zu dem von 2bl vorgeschlagenem zusätzlichem Stützkondensator. Wie bestimmt man denn am besten (faust)formelmässig die Kapazität von diesem?

  • Wobei mir gerade auffällt, dass das ja auch Mumpitz ist, denn Px_Anzahl ist in der Definitions.inc fest vorgegeben, d.h. es werden immer bspw. Daten für 256 Pixel ausgegeben, obwohl nur z.B. Daten für 128 Pixel per TPM2 empfangen wurden.

    Darum meinte ich ja, schau' Dir doch mal die tpm2->WS280x-SW in der Lobby an, da ist das so drin, dass genauso viele Pixel ausgegeben werden, wie empfangen wurden...


    Nein, das sehe ich nicht so. Es ist doch so, dass Glediator 25 mal die Sekunde einen Frame sendet. Also alle 40ms. Wenn ich jetzt richtig gerechnet habe dauert es aber nur 6,5ms (Worst- Case bei 676 Pixeln) den Frame zu übertragen, d.h. es bleiben 33,5ms die Daten auszugeben.

    Ja, stimmt, Du hast ja nur so "wenige" Pixel, da geht das dann so, wenn alles glatt läuft (keine Verzögerungen bei der Datenausgabe am PC, etc.)


    Ging bei mir halt nicht, da ich bis zu 1.024 Pixel durch schiebe, da kommen schon wieder Daten rein, während der alte Frame noch ausgegeben wird... deswegen muss ich auch während der Ausgabe Daten empfangen können. Wenn zwischen 2 ausgegebenen Bits einmal die Empfangs-ISR aufgerufen wird, macht das nix, sooo heikel ist das Timing auch nicht, solange die Pause nicht länger als 7 µs wird, ist alles im grünen Bereich


    Daher auch die Idee, während der kompletten Ausgabe die Interrupts zu deaktivieren. So verbrauche ich nur 1+1 Cycles während einer "Frameausgabe", wohingegen bei deiner Idee bei jedem Bit 2+2 Cycles verbraucht werden also ganze N*24*(1+1) Takte je nach Framegröße bzw Pixelanzahl.

    Das ist jetzt hier, bei der Ausgabe für WS2811/TM1804, wo Du eine feste Pulslänge hast, ziemlich egal - ich mache halt für die Pause pro Bit einfach 2 nops weniger und dafür 1x cli und 1x sei, unter'm Strich also die selbe Anzahl Takte.... ;)

    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!

  • Ich hab' jetzt noch mal nachgerechnet (weil ich für ein anderes Projekt ne ähnliche Rechnung hatte, die mich etwas stutzig gemacht hat), und kann mir das hier:

    Soweit die Theorie, praktisch sieht es nun so aus, dass ab ca 600 Pixeln teilweise Daten sporadisch "verschluckt" werden

    dadurch schon erklären:


    gehe ich richtig in der Annahme, dass Du mit 1 Mbit vom Rechner zum AVR überträgst...? - das sind ja dann 100.000 Byte/s (8N1) - ein Frame mit 676 Pixeln hat 676 x 3 (3 Byte/Pixel) + 5 (tpm2-Header), also 2.033 Byte.


    Und 2.033 Byte / 100.000 Byte/s sind dann 20,33 ms für einen Frame, nicht 6,5 ms... passt recht gut zu den besagten 600 Pixeln - wenn die Ausgabe ca. genauso lange dauert, dann insg. 40,66 ms für einen Frame, mit 21 fps noch möglich, mit 25 fps nicht mehr...


    weiß nicht, wo die 6,5 ms aus Deiner Rechnung her kommen, evtl. vergessen, dass es ja 3 Byte pro Pixel sind..? - das würde recht gut hin kommen, 6,5 x 3 = 19,5, recht nah an meinem Wert...


    und, übrigens, das ist nicht der worst case, sondern der best case, also schneller geht es auf keinen Fall, in der Praxis eher ein bisschen langsamer... ;) - daher geht auch ab 600 Pixel ab&zu was verloren, obwohl rein rechnerisch die vollen 676 bei 21 fps drin sein sollten...

    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!

  • Puh so langsam wirds frustrierend...- Natürlich habe ich nur mit einem Byte pro Pixel gerechnet -.-


    Zum Glück habe ich mein Platinenlayout nicht auch veröffentlicht. Nicht das sich noch rausstellt das ich Plus und Minus falsch geroutet habe und es am Ende nur funktioniert, weil ich beim anschließen der Platinen die Anschlüße nochmal vertauscht habe :D


    Nun denn - habe mal die Software aktualisiert. Ich hoffe alle groben Schnitzer sind jetzt beseitigt.


    "Worst- Case" war übringens eine unglückliche Wortwahl meinerseits, ich meinte damit den Fall, bei dem die meisten Daten übertragen werden müssen, also wenn die max. Anzahl Leds angeschlossen ist.


    Aber mit der neuen Version funktioniert es auch super ohne Flackern o.ä.mit 676 Pixeln.

  • Na, ist doch super! :thumbup:


    nur ein Detail noch: hier



    würde ich den sei nach dem cbi machen - klar ist das sehr unwahrscheinlich, aber es kann passieren, dass genau da ein Interrupt zuschlägt, dann macht er nach dem sei erst mal die ISR, so lange bleibt der Pin dann auf High - also erst nach dem setzen des Pins die Interrupts wieder aktivieren, dann ist die Pulslänge definitiv festgelegt...

    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!

  • Werden die Interrupts nicht nach einem CLI sogar "gequeued"?
    Ich meine, Interrupts die während CLI anfangen gehen nicht verloren, die ISRs werden nach einem SEI dann ausgeführt.
    Klar, mehrere Interrupts der selben Sorte (z.B. Timer) gehen verloren, aber die Timer-ISR würde dennoch angesprungen...


    Hoffe es wird klar was ich meine. Dann wäre der Fall nämlich gar nicht mal sooo unwahrscheinlich, je nachdem was auf dem Controller halt noch so los ist.

  • Ja, da wird ein Flag gesetzt, und sobald der Interrupt global wieder aktiviert ist, wird das abgearbeitet, das Event wird also "gemerkt"...


    wie wahrscheinlich das ist, dass hier, bei dieser SW, mal sowas auftritt, k.A. wie man das ausrechnet - bei ner "0" sind's 4 Takte bei denen es schadet, wenn da ein IRQ auftritt, es kommt (bei 1 MBit und 20 MHz Takt) ca. alle 200 Takte ein Byte rein...


    bei ner "1" sollte es nicht viel machen, wenn der Puls etwas länger ist...


    kann also maximal hier&da passieren, dass mal fälschlicher Weise *ein Bit* dann 1 ist statt 0, das sollte kaum auffallen... ;) - ausser natürlich, wenn's ausgerechnet das MSb ist, also ein Pixel dann z.B. bei einer Farbe Wert 128 hat statt 0, gibt dann ein kurzes Aufblitzen


    sauberer/"korrekt" ist's natürlich so, dass eben der ganze Puls nicht durch nen IRQ unterbrochen werden kann, sonst kann man sich das auch gleich wieder komplett sparen mit dem cli und sei...

    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!

  • Moin,
    mittlerweile kursiert auch ein Datenblatt zu den LEDs im Netz. Ich denke der ein oder andere kann damit was anfangen.


    Da die Datei leider zu groß ist um sie hier hochzuladen, sei auf den entsprechenden Thread auf mikrocontroller.net verwiesen (LINK3 im Startpost)


    oder direkt über hier


    Was ich mich frage ist wofür der 150Ohm Widerstand gut ist. Vll könnte mich da jemand aufklären.

  • Der bildet zusammen mit dem Kondi dahinter einen Tiefpass, entkoppelt so die IC-Versorgung noch besser von der schwankend belasteten Stromversorgung, hält Störungen auf der Leitung noch besser fern als nur ein Kondi...


    das ist gar nicht so doof, da haben die mitgedacht, die Versorgung für die LED-Chips und den WS2811 ist da extra rausgeführt bei der LED.

    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!

  • Sollte man den also "zwingend" mit bestücken?


    Bei den Stripes die man mittlerweile mit diesen LEDs kaufen kann sind nämlich nur die Kondensatoren drauf.
    (Ich bastele gerade an eigenen Platinchen für die Dinger, da kann ich die Widerstände auch gleich mit einplanen...)


    Die gleiche Frage gilt für die 33R in den Datenleitungen, ja oder nein?

  • Naja wie mans nimmt. "Zwingend" um zu funktionieren wohl nicht, da meine Platinen auch gut ohne auskommen. Dennoch werd ich den in der Zukunft mal mit einplanen.


    Und wegen dem Serienwiederstand in der Datenleitung, kommt es wohl auf den Anwendungsfall an, also ob er notwendig ist oder nicht, wenn ich das hier richtig verstanden habe.

  • Die gleiche Frage gilt für die 33R in den Datenleitungen, ja oder nein?


    Der Serienwiderstand ist eher nicht zur Serienterminierung, der ist zur Impulsbegrenzung. Also falls mal ein Überschwingen auftritt (bei langen Leitungen), dann sprechen die Schutzdioden an und der Strom wird durch den Serienwiderstand gedämpft ohne das die interen Schutzdioden auch noch hops gehen...