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.
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.
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.
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.
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
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.
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
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.
[...]
ldi temp0, Px_Anzahl ; Zahl der angesteuerten Pixel
[...]
dec temp0 ; Alle Pixel durch..?
brne Einlesen ; Nein => Nächstes ausgeben
[...]
Alles anzeigen
Das habe ich nun folgendermaßen umgeändert:
Code
[...]
ldi YH, high(Px_Anzahl) ; Zahl der angesteuerten Pixel
ldi YL, low(Px_Anzahl)
[...]
sbiw Y,1 ; Alle Pixel durch..?
brne Einlesen ; Nein => Nächstes ausgeben
[...]
Alles anzeigen
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
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.
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.
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:
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 Link2 Link3 Link4
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äß.
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
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:
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.
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.
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.
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:
Code
SUB_Byte_received:
push temp0 ; Register sichern
in temp0, SREG
push temp0
lds temp0,UDR0 ;hole Daten
cpi temp0,100 ;ist temp0="d"?
brne ledaus ;nein,also springen
sbi LED_Port,Test_Pin ;led an
rjmp weiter
ledaus:
cbi LED_Port,Test_Pin ;led aus
weiter:
pop temp0 ;Register wiederherstellen
out SREG, temp0
pop temp0
reti
Alles anzeigen
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.
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.
Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen.Weitere InformationenSchließen
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.
