Beiträge von drs

    Ich in Anlehnung an den Tipp von steveLB würde ich doch empfehlen mal zu schauen, ob deine Bildungseinrichtung auch sowas wie einen Lehrplan zur Vefügung stellt. Gewiss kann man nie zuviel lernen aber um erstmal einen Einstieg zu finden sollte das doch am hilfreichsten sein.
    Da ist es dann aus meiner Sicht auch erstmal sinnvoller sich mit anderen Grundlagen zu beschäftigen als gleich mit irgendwelchen Trafos anzufangen.
    Zumal ich mir in keinster Weise vorstellen kann, dass man Wissen darüber voraussetzt.


    Ich denke eher, dass Oberstufen-Mathe-Wissen in Lin. Algebra + Analysis zum Anfang/ Einstieg völlig ausreichend sein sollten aber wie gesagt mehr zu wissen schadet natürlich nicht.

    Moin,
    danke Kanwas für die Erläuterung. Ganz verkehrt lag ich mit meinem Erklärungsversuch im vorangegangenen Post ja nicht.
    Habe mich nun für einen 10µF SMD Elko als Stützkondensator pro Platine entschieden.


    Am Wochenende bestelle ich dann ein paar Platinen, mal schauen, ob ich sie noch vor Neujahr verschickt werden.

    Moin,
    erstmal danke für die Antwort Kanwas, allerdings verstehe ich sie nicht so ganz...
    Ich bin eigentlich immer davon ausgegangen das Abblock- und Stützkondensator Synonyme sind.
    Und was soll in diesem Zusammenhang "normal" bedeuten?


    Ich will hier ja wirklich niemanden vor den Kopf stoßen oder undankbar klingen aber es bringt mir nicht viel wenn ihr mir sagt, WAS ihr machen würdet, viel hilfreicher wäre es doch zu erfahren WARUM ihr es so machen würdet.


    Hier nochmal meine Gedanken zu der Thematik:
    Jede LED hat ihren eigenen 100n Kerko ( wie auch im DB empfohlen wird), welcher Stromimpulse ausgleicht und so hilft die Spannung im Rest der Schaltung zu stabilisieren (C1- C4). Diese können ihre Energie sehr schnell auf- bzw. wieder abgeben. Zusätzlich habe ich nun auf Anraten noch einen weiteren Kondensator pro Platine vorgesehen (C5). Meine Idee wäre, dafür einen Elko mit etwas größerer Kapazität zu verwenden. Diese können, im Vergleich zum Kerko, ihre Energie langsamer auf-/ und abnehmen, könnten daher quasi als Puffer dienen. Bauformbedingt besitzen sie aber auch einen induktiven Anteil, wäre also zu klären, ob sie am Ende nicht sogar mehr schaden als helfen würden.


    Gruß
    Dennis

    Hello,
    ein SMD Quarz ist mir erst gar nicht in den Sinn gekommen, habe aber gerade mal bei Reichelt geguckt und festgestellt, dass der billigste 16MHz Quarz 5mal teurer ist als das Pedant in THT. Zudem weiß ich aufgrund der Produktfotos gar nicht, ob ich den überhaupt per Hand gelötet bekomme. Also nicht wegen der Größe sondern weil die Pads auf der Unterseite liegen und ich nicht erkennen kann inwieweit man da von der Seite rankommt.


    Counterfeiter
    Ja, nee genau das wollte/ will ich mit den Lötpads umgehen ;) Im Moment sehe ich die Platinen immernoch mehr als Bauklötze, die man ständig neu zusammenstecken kann um zu gucken, wie es dann wirkt. Das ist dann denke ich einfacher/ angenehmer eben mal ne Lötbrücke zu trennen/ verbinden als im Zweifelsfall Stiftleisten aus- oder einzulöten.



    P.s. Mir ist aufgefallen, dass ich euch noch ein Video vom Empfangs-Timeoutprogramm schuldig bin. Die mit LEDs bestückten Platinen liegen zwar seit fast einem Monat hier rum, allerdings sind mir Stiftleisten und Kondensatoren ausgegangen und es hat sich noch nicht genug weiteres Zeug angesammelt, dass sich eine Bestellug lohnen würde... Aber sofern hier keine gigantischen Designfehler gefunden werden, sollte die Platinen und Bautteilbestellung am Wochenende rausgehen.

    Hallo Leute,


    ich habe am Wochenende mal wieder etwas
    Zeit gefunden um an meinen Platinen weiterzuarbeiten.


    Ersteinmal habe ich das Layout der
    Basisplatinen überarbeitet um unter anderem Hinweise und Tipps, die
    hier genannt worden sind, zu beherzigen. (Danke dafür)


    Schaltplan und Layout sehen nun
    folgendermaßen aus:




    Hier in aller Kürze die Änderungen:

    • Standard - LED – Beschaltung aus
      Datenblatt übernommen


    • Statt Leitungen für die
      Stromversorgung VCC als Polygon auf Oberseite sowie GND- Polygon auf
      Unterseite eingefügt


    • Anschluss auf Rückseite zur
      Spannungsversorgung ODER für Stützkondensator


    • Stift- bzw. Buchsenleiste oben
      und unten von 2 auf 4 Pol erweitert


    • 3 Lötbrücken eingefügt, um auf
      Jumper und fliegende Verkabelung z.T. verzichten zu können

    Zudem habe ich mich mit der µC-
    Platine beschäftigt. Zuerst hatte ich vor diese separat zu
    erstellen, also eine eigene Platine, die am Ende z.B. hinter der
    Matrix angebracht werden kann. Da aber u.a. eines der Ziele dieses
    Projektes sein soll mich näher mit dem Löten von SMDs
    auseinanderzusetzen und auf der Basisplatine noch reichlich Platz
    war, habe ich den µC kurzerhand auf die Rückseite ebendieser
    verfrachtet. Als dann immer noch reichlich Platz übrig war, wurde
    der USB/UART- Wandler (FT232) ebenfalls direkt integriert.






    Insgesamt bin ich mit den Platinen nun
    soweit zufrieden. Einziger Wermutstropfen ist, dass man auf den
    Basisplatinen je nach Position in der Matrix Lötbrücken einfügen
    muss. Dies hält sich aber in Grenzen beispielsweise müsste man bei
    einer 32x16 Matrix, die folglich aus 16x8 Platinen besteht, nur 16
    Brücken einfügen.


    Soweit so gut, unschlüssig bin ich mir
    nach wie vor noch bei der Dimensionierung des Stützkondensators C5
    auf der Basisplatine. Ich plane alle 3 Platinen die Spannung neu
    einzuspeisen, d.h. Ein Einspeisepunkt „versorgt“ jeweils 9
    Platinen was theoretisch unter Volllast (Weiß) 2,16A entsprechen
    würde ( Im „normalen“ Betrieb z.B. Plasma- Animation ca. 2/3
    davon). Ich gehe doch richtig davon aus, dass es am Besten wäre auf
    den umliegenden 8 Platinen jeweils einen Kondensator zu platzieren?


    2Bl schrieb ganz zu Anfang mal was von
    ca. 10µF. Würde das immer noch für o.g. Szenario gelten?


    Über Ratschläge und Tipps bzgl.
    Layout und Kondensatorproblemchen würde ich mich sehr freuen.


    Danke und viele Grüße
    Dennis

    Tag auch,
    also es ist so, dass man den Data_Out Pin des letzten WS2812 Pixels mit dem µC verbinden muss (genauer mit INT1).
    Beim Start/ Reset des Controllers wird nun zu Beginn der externe INT1 aktiviert und damit begonnen Nullen an die Pixel zu senden. Dabei wird erstmal von der maximal möglichen Pixelanzahl ausgegangen (675 Pixel). Pixel Nummer 1 "nimmt" sich die ersten 24 Bit und reicht den Rest weiter, Pixel Nummer 2 "nimmt" sich Bit 25-48 und gibt alle weiteren Bits weiter, usw. Hat nun auch das letzte Pixel seine 24Bit erhalten, so gibt es bei Emfang weiterer Bits diese Daten an den INT1 Pin des µCs weiter, wodurch ein Interrupt ausgelöst wird. In der ISR wird nun mit Hilfe eines Zählers, der während der Ausgabe mitläuft, die Anzahl der angeschlossenen Pixel berechnet.


    Stellt man die Verbindung zwischen letztem Pixel und µC nicht her so speichert das Programm die maximale Pixelanzahl, was aber auf die Ausgabe von Glediator- Daten keine Auswirkung hat, da dann mit der per TPM- Protokoll gesendeten Framegröße gearbeitet wird. Allerdings funktioniert das Standaloneprogramm dann nicht mehr wie es soll. Soll heißen bei beispielsweise real 80 angeschlossenen Pixeln wandert ein Leuchtpunkt vom ersten bis zum letzten Pixel aber anstatt nach dem letzten Pixel wieder von vorne zu beginnen durchläuft der Punkt auch noch die weiteren 595 virtuellen Pixel bevor er wieder am Anfang erscheint.


    Soviel dazu.


    Und vielen Dank Pesi, sowas ist genau das was ich mir vorgestellt habe. Habe anhand dessen nochmal den Quellcode etwas aufgeräumt und abgesehen davon, dass ich es jetzt für "ordentlicher/ sauberer" halte, habe ich auch noch einen groben Fehler entdeckt. Und zwar war es so, dass ich beim Ausrechnen der maximal möglichen Pixelanzahl von gesamten SRAM minus der reservierten Bytes für den Framesize ect. ausgegangen bin. Was ich aber total vergessen hatte war auch noch den Stack mit zu berücksichtigen. Letztendlich ändert das aber nicht allzuviel, ich musste nur die maximale Pixelzahl von 676 Pixeln auf 675 reduzieren.


    Die aktualisierte Software (Diesmal mit allen Dateien ;) ) befindet sich wie immer im Startpost.


    PS: Ein Video dazu folgt demnächst. Nächste Woche sollte ich nochmal 20 Platinen erhalten mit denen sich die Matrixgröße auf dann 160 Px verdoppelt.


    Gruß
    Dennis

    Hallo Freunde der gepflegten Leuchtakrobatik,


    ich habe im Startpost ein neues Update der µC Software hochgeladen.


    Neu ist das beim Start des µCs die angeschlossenen Pixel gezählt werden und ein Standaloneprogramm wurde implementiert.


    Das Standaloneprogramm besteht aus einem blauen Px welches einmal die Matrix durchläuft und dann wieder von vorne beginnt, daher war es wichtig, dass die Pixel zu Beginn gezählt werden. Nicht dass das Pixel je nach Größe der Matrix am Ende "rausläuft" und irgendwann plötzlich wieder erscheint.


    Wäre nett wenn jemand mit Ahnung mal über den Quellcode schauen könnte. Grobe Fehler schließe ich mal aus - weil funktioniert ja - aber irgendwas gibts ja immer zu verbessern ;)


    Gruß
    Dennis

    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.

    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.

    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.

    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?

    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ß

    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 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

    Schön das es euch gefällt. Danke.


    @bower


    Nein das Pixel ist nicht kaputt aber aufgrund von Bauteiltolleranzen ( ich denke zumindest, dass es daran liegt) reichte die Lichtleistung bei eben diesem nicht aus damit es umspringt. Der Effekt ist jetzt, wenn es draussen dunkel ist, also quasi kein Fremdlicht ausser das der IR- Dioden einfällt, noch stärker, da sind das um die 6 Pixel. Das ist aber kein Beinbruch- ich habe einfach die Spannung für die IR- Dioden erhöht und damit funktioniert alles Ordnungsgemäß.


    Pete the Beat


    die Antwort habe ich ja quasi schon eben gegeben. Ja für meine Schaltung ist der ein Muss. Aber mit einem anderen Aufbau ist es sicherlich auch möglich sowas ohne extra Scheinwerfer zu realisieren. Pesis Ausgangsschaltung funktioniert ja auch ziemlich gut ohne. Muss man dann aber am besten selbst testen, auch schon aufrund unterschiedlicher Bauteile etc. Ich habe mich für die Testaufbauten einmal quer durchs Phototransistoren- Portfolio von Reichelt gekauft und da schon eklatante Unterschiede festgestellt ( auch bei Modellen, die mir recht ähnlich erschienen).


    @ Pesi
    All zu teuer war es glaube ich gar nicht mal, werd mich morgen nochmal ransetzten und das grob kalkulieren. Aber Zeit und vor allem Nerven hat es schon gekostet weil der Aufbau so mega monoton ist. 100 mal die gleiche Schaltung aufbauen, 100 Phototransistoren verkabeln,...
    Besonders wenn man gerade 900 Löcher für die Dioden und Ts gebohrt hat und dann bemerkt, dass die LEDs nicht in die Löcher passen, da man diesen kleinen etwas dickeren Ring unten an den Gehäusen vergessen hat :D


    Von den jetzt verwendeten Bausätzen werde ich mich aber trennen. Erstmal weil, wie oben schon beschrieben die Lichtleistung nicht ganz ausreicht und zum anderen wäre das doch ein super Anschlussprojekt ;)

    Hallo Forum,
    heute will ich euch meine neuste Errungenschaft vorstellen.
    Die Idee eines LED- Tisches hatte ich schon länger, bin allerdings erst in den letzten Semesterferien dazu gekommen das Projekt endlich mal zu verwirklichen bzw zu starten.
    Als Inspiration diente mir Pesis Schattentapete:
    Interaktive Matrix / "Schattentapete"


    An der Schaltung gefiel mir aber nicht, dass die LEDs je nach Lichteinfall faden. Ich wollte lieber etwas abruptes- also entweder LEDs an oder aus. Desweiteren hatte die Schaltung in meinem Testaufbau eine "recht hohe" Stromaufnahme von 1,x mA wenn die LEDs aus sind. Also habe ich weitere Schaltungen simuliert und getestet und bin letztlich zu folgender Version gekommen:


    Der Transistor aus Pesis Schaltung wurde also durch 2 Transistoren (2N5551) in Darlington- Schaltung ersetzt. Die LEDs gehen nun ziemlich abrupt an und aus und auch die Stromaufnahme bei nicht leuchtenden LEDs hält sich in Grenzen ( laut Simulator 50µA pro Pixel, in der Realität aber noch nicht gemessen)


    Insgesamt besteht der Tisch aus 10x10 Pixeln mit je 8 LEDs. Die gesamte Stromaufnahme bewegt sich um die 8A, falls denn alle Pixel leuchten + Strom für den an der Decke angebrachten IR- Scheinwerfer.


    Aber nun erstmal ein paar Bilder von dem Ganzen:
    Rückseite:

    Vorderseite:

    Der Tisch:

    Und fertig:

    Hier nun ein kurzes ( dank mangelhaftem Equipment) 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.


    Als IR- Scheinwerfer kommt zur Zeit eine Parallelschaltung von 4 Pollin- IR- Bausätzen zum Einsatz:

    Diese sind, so wie im Moment "verbaut", natürlich nicht sehr nett anzusehen, desweiteren werden die Widerstände auf der Schaltung, wenn man sie mit den angegebenen 12V betreibt, schon nach wenigen Sekunden so heiß, dass ich mir direkt beim ersten Funktionstest ordentlich die Floßen verbrannt habe. Daher betreibe ich sie nun nur noch mit 7V und mittelfristig werden sie ersetzt, bin da aber noch nicht ganz schlüssig durch was.


    Das wars dann erstmal von meiner Seite. Über Kritik, Fragen etc. würde ich mich sehr freuen.

    Ok, dann nochmal alles auf Anfang:


    Also ersteinmal Variante A mit UART- Abfrage in der Main-Loop. Diese Variante entspricht der angehängten Datei mit der Ausnahme, das die "SUB_Byte_received" leer ist. Brenne ich dieses Programm nun auf den Chip passiert das oben schon beschriebene:

    Zitat

    Der µC reagiert, so wie ich das sehe immer auf das vorletzte Zeichen was
    gesendet wurde, also sende ich per Terminalprog z.B. ein "s" & "d"
    so passiert erstmal nichts. Erst wenn ich ein weiteres Zeichen sende
    geht die LED an, abhängig davon, ob dieses Zeichen ein "d" war, bleibt
    die LED bei einem weiteren Zeichen an oder geht aus.

    So und weiter mit Variante B. Hier habe ich folgende Veränderungen vorgenommen:
    - in der "Interrupt.inc" das zu Rx-Complete gehörende "reti" durch "rjmp SUB_Byte_received" ersetzt
    - der Inhalt der Main- Loop besteht nur noch aus einem nop- Befehl
    - "SUB_Byte_received" sieht nun so aus, wie in der .txt


    Bei dieser Variante tut sich nun gar nichts mehr... Die LED bleibt dauerhaft aus.

    Moin erstmal,

    Zitat

    also wie jetzt, wenn ich das richtig sehe, wertest Du das empfangene Byte 2x aus... ?(

    Nein, das mache ich nicht. Der Einfachheit halber habe ich es erstmal ohne Interrupt versucht. Also besteht mein Programm im Prinzip nur aus meinem ersten eingefügten Codeblock (+ Register- Def. usw). Dies führt, wie erklärt zur verzögerten Ausgabe der empfangenen Daten.


    Anschließend habe ich den Teil aus der Main-Loop ausgeschnitten und in eine Sub gepackt, die von der ISR angesprungen wird.


    Zitat

    darf ich aufgrund des Schriftsatzes richtig vermuten, dass der Teil aus irgendner SW von mir kopiert ist...? ;)

    Ja und nein. Ich muss dazu sagen, dass das mein erstes richtiges Projekt in Assembler ist. (Hatte aber letztes Semester ein Labor an der Uni in welchem die Grundlagen gelehrt, gelernt und angewendet wurden) Daher habe mich erstmal umgeschaut und bin dann ,wie du ja schon richtig vermutet hast, auf deine SW gestoßen. Daraus habe ich aber nichts sinnlos kopiert, sondern nur den "Stil" übernommen, da ich ihn für sehr übersichtlich und nachvollziehbar halte (was bei Assembler meiner Meinung nach recht schwierig ist).


    Zitat

    Frage: ist das nur kopiert, oder weißt Du, was das macht....?

    Siehe oben und ich denke zumindest, dass ich weiß, was ich da tue ;)
    Wobei ich glaube, dass ich in diesem einfachen Fall auch darauf verzichten könnte die Register zu sichern, da das Programm im Moment nur aus einer leeren Main-Loop und dem Rx- Complete- Interrupt (aka SUB_Byte_received) besteht, also die Register woanders gar nicht verwendet werden.

    Zitat

    ... nur, dann passiert folgendes: Du hast Dein empfangenes Byte in temp0,
    anschließend holst Du per pop wieder vom Stack den Wert, der *vorher* in
    temp0 war, überschreibst also Dein empfangenes Byte!

    Grundsätzlich richtig ABER bevor ich temp0 wieder vom Stack hole, werte ich es ja in der ISR direkt aus, von daher sehe ich da eigentlich kein Problem.


    Und die von dir verlinkte SW kenne ich schon (mit DMX-, wie auch tmp2- Empfang)- wie gesagt sind die Teil meines Wissensfundaments, auf das ich versuche aufzubauen. Sofern ich das bestehende Problem gelöst bekomme, sieht mein nächster Schritt erstmal so aus, dass ich versuchen werde das "Glediator-Protokoll" zu implementieren. Das ist dann doch einfacher als tmp2 (wenn auch Fehleranfälliger, denke ich). Mir geht es halt nicht primär um das Endergebnis, sondern darum was zu lernen/ Gelerntes anzuwenden.


    btw der Vorschlag mit den "2- Klassen- Registern" ist sehr gut, den werde ich sicherlich, wenn es etwas komplexer wird, beherzigen.


    Schönen Sonntag noch
    drs

    Hallo,
    ich bin zur Zeit dabei einen ATMega328P in Assembler zu programmieren, der anschließend in der Lage sein soll WS2811 Pixel anzusteuern. Die Daten soll er später von Glediator bekommen.


    Die eigentliche Datenausgabe an die Pixel funktioniert auch soweit korrekt. Probleme bereitet mir nun der Datenempfang.


    Zu Testzwecken habe ich jetzt ein neuen Codeblock geschrieben, welcher einfach eine LED beim Empfangen eines bestimmten Zeichens (hier "d") einschaltet. Wird irgendein anderes Zeichen gesendet so soll die LED wieder ausgehen.


    Packe ich das ganze in die Main-Loop passiert folgendes:
    Der µC reagiert, so wie ich das sehe immer auf das vorletzte Zeichen was gesendet wurde, also sende ich per Terminalprog z.B. ein "s" & "d" so passiert erstmal nichts. Erst wenn ich ein weiteres Zeichen sende geht die LED an, abhängig davon, ob dieses Zeichen ein "d" war, bleibt die LED bei einem weiteren Zeichen an oder geht aus.


    Aber eigentlich soll der Datenempfang bzw deren Verarbeitung per Interrupt ablaufen. Wenn ich nun die Routine aus der Main- Loop lösche und nur bei einem Rx- Complete-Interupt anspringe, ist es so, dass die LED quasi die ganze Zeit aus ist. Erst wenn ich eine Taste gedrückt halte, also Daten ununterbrochen gesendet werden, so flackert die LED. Dabei scheint es auch nicht zu interessieren, ob ich "d" oder eine andere Taste gedrückt halte.
    Daraus schließe ich schonmal, dass die ISR immerhin angespringen wird bzw der Interrupt auslöst


    Hier erstmal mein Code um das ganze etwas zu veranschaulichen:
    Die Block sieht folgendermaßen aus:

    Code
    Main:
    cpi temp0,100			;ist temp0="d"?
    brne ledaus				;nein,also springen
    sbi LED_Port,Test_Pin	;led an
    rjmp Main
    ledaus:
    cbi LED_Port,Test_Pin	;led aus
    
    
    rjmp Main


    Die ISR sieht dan folgendermaßen aus:


    Es wäre nett wenn mich jemand aufklären könnte was ich falsch mache. Denn wenn selbst sowas simples nicht funktioniert, brauche ich mir über komplexere Sachen gar keine Gedanken machen. Falls noch weitere Dinge zur Aufklärung benötigt werden liefer ich die gerne nach.


    Ach so zu sagen wäre noch, dass der µC mit 16MHz läuft und UART für den Moment auf 9600 Baud, 8Bit, 1 Stoppbit, No Parity eingestellt ist.


    Vielen lieben Dnak schonmal

    Ja gut aber bei dem Preis für ein fertigen würd ichs dann doch immer wieder per Hand machen ;)


    Bei dem Mittelpreisigen denke ich, dass der hier gemeint ist:
    http://www.instructables.com/id/Led-Cube-8x8x8/


    Das war m.M.n. einer der ersten und besten, die dort vorgestellt wurden.
    Und der läuft nur über UART, also nur in Verbindung mit PC.


    Ja klar löten schön und gut aber nach 1024 Lötstellen war ich dann auch froh, dass es vorbei war. Musste dabei auch einiges an Lehrleds bezahlen bis ich ein halbwegs gutes System hatte.