Hallo zusammen. Ich habe ein Matrix-Panel gebaut mit 64 RGB-Dioden, welches komplett über DMX ansteuerbar ist (192 DMX-Kanäle): Es klappt wunderbar und funktioniert auch alles bestens und sieht genial aus, :-). Ich probiere nun die Steuerung zu optimieren, denn zur Zeit benötige ich 22 Atmegas (9 Kanäle pro Atmega), welches einen enormen Löt- und Kostenaufwand mit sich trägt. Wer hat erfahrung mit einer speziellen Steuerung dieser Art, ich möchte gerne jede einzelne LED ansteuern können (linear dimmbar, jede einzelne Farbe), sowie bisher auch, sprich bei einer Matrix von 8x8, welche ich aber auf 9x9 aufstocken möchte, benötige ich natürlich 192 DMX-Kanäle, bei 9x9x3 wären das dann: 243 Kanäle. Ich habe mich schon ein wenig schlau gemacht, aber ich bin noch nicht so der FPGA-Spezialist. Einen sehr interessanten Link habe ich bei "Digital-enlightenment" gefunden, aber bisher erhalte ich dort keine konkreten Antworten: http://home.rz-online.de/~wdreschm/de_projects/RGB%20Matrix.rar Website: http://www.digital-enlightenment.de Wer hat lust sich dort mit mir in Verbindung zu setzen, denn ich möchte gerne eine große Matrix-Wand bauen, welche natürlich erweiterbar sein wird. Liebe Grüße und Danke schon einmal für Eure Beiträge. PAT-S
>(9 Kanäle pro Atmega) Da geht noch Einiges! Mit Soft-PWM gehen an einen ATmega8515 rund 30 Kanäle bei 8-Bit Auflösung. 3-Pins sind dann noch zum 8x Multiplexen frei und zwei für die serielle Kommunikation. Komme dann auf höchstens 7 Controller ohne Multiplexing. Willst du überhaupt dimmen? Sonst geht's noch einfacher - auch ohne FPGA. Kannst auch gerne auf unserer (nicht ganz auf dem aktuellsten Stand gehaltenen) Projektseite vorbeischauen: http://chamaeleon.tothecore.de Nenne mal ein paar Eckdaten. Gruß Kai
Eckdaten: Ich arbeite mit 5mm RGB-Dioden mit einer gemeinsamen Anode. Diese muss komplett dimmbar sein, das ist sehr, sehr wichtig. Weiterhin benutze ich den ATmega8515-16. Jede einzelne Farbe, sprich Diode, ist über DMX ansteuerbar. Wie kommst Du auf rund 30 Kanäle bei 8-Bit Auflösung??? Hast Du die "DMX-Kommunikation" bei Deiner Kalkulation mit berücksichtigt? Ich habe FPGA nur angedacht, wegen der größeren Kapazität an Kanälen und der linearen Dimmfunktion usw., welches der Michael von "Digital-Enlightenment" schon probiert hatte, aber noch nicht vollendet hat. Was denkst Du oder Ihr, soll ich am besten machen??? Gruß PAT
>Hast Du die "DMX-Kommunikation" bei Deiner Kalkulation mit >berücksichtigt? Nope! Wie viele I/Os braucht man? Ich würde nach Möglichkeit einen Controller mit der DMXerei beauftragen und die Daten per USART an die Einzelcontroller verteilen - ist wahrscheinlich nicht die sinnvollste Lösung, sollte aber machbar und bezahlbar sein. Wir machen das ähnlich mit einem Mastercontroller, der über USB gefüttert wird und die 24 anderen Controller per Software-USART steuert. Schwieriger wird das, wenn man aus den Einzelcontrollern auch Daten auslesen will/muss. >Was denkst Du oder Ihr, soll ich am besten machen??? Auf jeden Fall nichts überstürzen. Wir haben eine ganze Menge Geld dadurch gespart, dass wir wenig Zeit für das Projekt haben und viel Zeit mit der Planung verbracht haben. Bei 8 Bits PWM-Auflösung ist aber nicht viel mit linearem Dimmen. Je nach Anspruch sollten 12 Bits ok sein. >Ich habe FPGA nur angedacht, wegen der größeren Kapazität an Kanälen und >der linearen Dimmfunktion usw., welches der Michael von >"Digital-Enlightenment" schon probiert hatte, aber noch nicht vollendet >hat. FPGAs sind natürlich mit deutlich mehr I/Os bestückt. Wir haben die aus folgenden Gründen nicht verwendet: - Ich habe (noch) kaum Ahnung davon - Ich kenne mich mit den AVRs ganz gut aus - EUR/Farbkanal hat sich am Ende nichts gegeben - Wenn wir mehr I/Os brauchen gibt's auch dickere AVRs Gibt's 'nen Link zum obigen Projekt? Würde mich interessieren. >Wie kommst Du auf rund 30 Kanäle bei 8-Bit Auflösung??? - 30 I/Os pro Farbkanal (= 10 RGB-LEDs) - 2 I/Os Rx/Tx für die Kommunikation - 3 I/Os für's Multiplexing - 0 I/Os für DMX weil keine Ahnung davon und bereits durch USART abgedeckt = 35 General Purpose I/Os
@ Patrick Sobieray (Firma PGS) (pat-s) >Weiterhin benutze ich den ATmega8515-16. Für den DMX-Kram etc. OK, für die Matrixdimmung wesentlich unterdimensioniert. >Jede einzelne Farbe, sprich Diode, ist über DMX ansteuerbar. >Wie kommst Du auf rund 30 Kanäle bei 8-Bit Auflösung??? Mit seiner "Zaubersoftware", streng geheim. ;-) Naja, real braucht man dazu einen PWM-IC, etweder findet man was fertiges oder man muss ihn selber per CPLD oder FPGA bauen. CPLD sollte reichen. Der CPLD mach die PWM, der AVR steuert den CPLD und füttert ihn immer mit DMX-Daten. Klein und billig. >Was denkst Du oder Ihr, soll ich am besten machen??? AVR + CPLD. MFG Falk
>Wie kommst Du auf rund 30 Kanäle bei 8-Bit Auflösung???
Ach ja die 8 Bits Auflösung: War jetzt aus der Luft gegriffen, da das
noch relativ einfach zu realisieren ist. Bis 17 wäre technisch maximal
machbar (bevor es irgendwie flimmert), bis 16 wäre gerade noch sinnvoll
- aber wenn ich das so deutlich schreibe kommt Falk wieder aus der
Versenkung ;)
ps: Mist, da isser schon ;)
>Mit seiner "Zaubersoftware", streng geheim. ;-)
Naja... 8 Bits Auflösung gehen auch mit normaler Programmierung locker
8 mal:
load from sram (2 Cycles)
compare (1 Cycle)
shift carry (1 Cycle)
Und dann einfach das zusammengeshiftete Byte an den Port schicken.
Macht:1 | 16000000 MHz / 256 Stufen / (2 + 1 + 1) Cycles / 30 LEDs = 520 Hz Refresh-Rate. |
Selbst mit dem Overhead, den ich ausgelassen habe schafft man damit locker 400 Hz. USART kann man pollen oder man stört sich nicht an Interrupts. oder halt AVR + CPLD, wenn man sich damit auskennt ;) Gruß Kai -- frohe Weihnachten gehabt zu haben!
@ Kai Giebeler (runtimeterror) >Naja... 8 Bits Auflösung gehen auch mit normaler Programmierung locker Zeig mir ein VOLLSTÄNDIGES, lauffähiges Programm, dann reden wir weiter. >16000000 MHz 256 Stufen (2 + 1 + 1) Cycles / 30 LEDs = 520 Hz >Refresh-Rate. Nur dass deine 4 Takte pro Kanal nicht reichen. >Selbst mit dem Overhead, den ich ausgelassen habe schafft man damit >locker 400 Hz. Reicht für ein 8:1 MUX nicht. Ausserdem waren es letztens noch 16 Bit PWM-Auflösung. Naja, so langsam nähern wir uns der Realität. MFG Falk, aus der Versenkung ;-)
@Falk, aus der Versenkung Tach auch. >>Naja... 8 Bits Auflösung gehen auch mit normaler Programmierung locker >Zeig mir ein VOLLSTÄNDIGES, lauffähiges Programm, dann reden wir >weiter. Tickert bei mir im Moment mit einem Port auf dem STK500 vor sich hin... wollte ich eh in die Code-Sammlung aufnehmen - vielleicht tu ich dir ja den gefallen und werfe die anderen drei Ports auch noch mit rein, ist ja nur Copy'n Paste >>16000000 MHz 256 Stufen (2 + 1 + 1) Cycles / 30 LEDs = 520 Hz >>Refresh-Rate. >Nur dass deine 4 Takte pro Kanal nicht reichen. weil... >Selbst mit dem Overhead, den ich ausgelassen habe schafft man damit >locker 400 Hz. >Reicht für ein 8:1 MUX nicht. Hab ich auch nicht behauptet - nur, dass er zum Muxen noch 3 I/Os frei hätte. Scheint er aber eh nicht nutzen zu wollen. >Ausserdem waren es letztens noch 16 Bit PWM-Auflösung. Naja, so langsam >nähern wir uns der Realität. Keine Sorge, >>Naja... 8 Bits Auflösung gehen auch mit normaler Programmierung locker die 16 Bits gelten immer noch ;) - natürlich nicht mit dem obigem Ansatz.
Hab dir da mal was aneinandergehäkelt, Falk. Läuft bei 8 MHz Clock mit über 220 Hz PWM-Frequenz. 32 x 8 Bits PWM auf allen 4 Ports. Wenn man unter 28 zu berechnende PWM-Kanäle geht kann man die Frequenz nochmal fast verdoppeln. Und das ist nur der oben beschriebene Bilbo-Algorithmus... Ist auch nur auf die Schnelle zusammengeklöppelt und kaum kommentiert. Ach ja, der Code ist für's STK500 geschrieben, also invertierte I/Os. Bitte bei anderer Beschaltung die Compares verdrehen oder die Bitmasken vor dem Setzen invertieren. Das Übliche: Clock auf intern 8 MHz, JTAG per Fuse abschalten. Sollte auf 'nem ATmega8515 auch problemlos laufen... ach nee. Die Animation verschwendet Unmengen an RAM. Und jetzt wiederhol doch bitte mal, was daran nicht gehen soll?
@ Kai Giebeler (runtimeterror) >32 x 8 Bits PWM auf allen 4 Ports. Wenn man unter 28 zu berechnende >PWM-Kanäle geht kann man die Frequenz nochmal fast verdoppeln. Und das ??? Wie sollte das gehen? >Ist auch nur auf die Schnelle zusammengeklöppelt und kaum kommentiert. Sieht man, stellenweise sehr schlechter Programmierstil. >Und jetzt wiederhol doch bitte mal, was daran nicht gehen soll? So wie du es geschrieben hat geht es schon. Wenn gleich das nur eine PWM mit konstanten Daten ist (aus dem Flash). Mit geringfügiger Einschränkung der PWM-Frequenz kann mn sicher noch ne UART/wasaucimmer Anbindung hinbekommen. OK. Aber nützt für die MUX von 9x9 RGB-LEDs wenig bis nichts. Denn dort muss nach JEDEM PWM Zyklus ein neues Muster geladen werden. Und das bei ~900 Hz. MFG Falk
1 | ldi ZH, high(sin << 1) |
2 | clr ZL |
Was soll das? Ist das cool?
1 | inc counter_reg |
2 | breq no_pwm |
3 | rjmp pwmLoop |
4 | no_pwm: |
5 | |
6 | rjmp animationLoop |
1 | .org 0x0100 |
Vollkommen unnötig, schlechter Stil.
Hallo Leute! Wer kann mir denn nun eine konkrete, wenn es geht mit linerarer Dimmfunktion der LED's, Schaltung (Steuerung) bauen (entwerfen), die auf DMX-Basis läuft und wo ich nicht so viele Atmegas benötige, ohne das DMX-Befehle verloren gehen usw. Es ist relativ dringend, soll ja auch nicht umsonst gemacht werden. Das Panel ist jetzt schon, es kommen nächste Woche ein paar Bilder und Videos, richtig fett und es macht riesen Spaß dabei zuzusehen, wie die RGB-Dioden ein Zauberspiel an Animationen erzeugen. Ich wäre Euch sehr verbunden. Viele Grüße PAT
Bin gerade auf dem Durchflug... Also die 9x9-Matrix bei 8 Bits könnte ich dir kurzfristig zusammenkopieren - das wäre kein Problem. Bei linearem Helligkeitsverlauf muss ich auf die Schnelle passen, das ist deutlich aufwendiger. Wenn du überwieged satte Farben (also nicht Pastell oder dunkel) darstellen willst könnten die 8 Bits reichen. Wie Falk schon sagte ist CPLD wahrscheinlich die sinnvollste Variante - also die CPLDs einfach als 'bessere Schieberegister'. Schau mal bei Texas Instruments, die bieten für common Anode-LEDs brauchbare Matrix-Treiber mit guter Farbauflösung - einfach ein Sample schnorren. Denke das ist auf die Schnelle die einfachste Lösung. und tschüss...
Für solche Aufgaben gibt es spezielle ICs von vielen Herstellern. TI hat u.a. einen mit 16 LEDs, bis zu 80mA pro LED (bei geringem Duty-Cycle wichtig), I2C Anbindung usw... Gibts auch direkt mit integriertem Spaltentreiber. Maxim hat z.B. den MAX6966 - 10x LED mit 17MHz SPI-Interface und vielen komfortablen Dimm-Optionen. Der sollte doch eigentlich prima gehen ;-) Linear bietet auch solche Dinger an, ST auch, usw... Die ICs haben alle den Vorteil, dass sie Konstantstrom liefern, den man auch komfortabel einstellen kann und teilweise auch global (über hunderte ICs hinweg) Bit für Bit kalibrieren kann (die von TI haben das). Denk immer dran, dass sich andere Leute schon für dich den Kopf zerbrochen haben, wie würde man sonst Stadion-Anzeige und Ähnliches bauen?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.