Archiv verlassen und diese Seite im Standarddesign anzeigen : 81Fullcolor Led Bild
Hi,
mein Vater hatte die Idee ein Bild mit 81 Fulcolor Leds zu machen die
dann angesteuert werden sollen.
Meine Frage wäre jetzt wie ist das am einfachsten Soft- und Hardware
technisch zu realieseiren?
am einfachsten
Ein Handydisplay nehmen.
Wie kommt man eigentlich auf 81? Wie soll das Bild denn aufgeteilt sein?
Sollen die einzelnen LEDs noch gedimmt werden können? Also das man auch zwischenfarben erzeugen kann?
Wie willst du programmieren?
Was für Gedankenhast du dir bis jetzt schon gemacht?
HI,
Also das Bild wird in 9*9 Flächen eingeteilt und pro Fläche eine Led.
Es wäre schön wenn man die LEds auch dimmen kann. ZUsätzlich
wird das ganze mit einem TSOP ausgestattet um dann verschiedene
programme zu wählen. Die Leds sind schon bestellt (110006526553 EBAY).
Brauch mann für die Led`s noch ein Transitor wegen dem 20mA.
Programieren wollen wir das ganze in Bascom.
Am Ende soll das Bild an der Wand für Stimmung sorgen.
Nee, pro LED drei Transistoren, wg. RGB
oh man
das wären 243 Transistoren. Wo bekommt man die billig her?
Wieß das jemand.
BC 237 Kostet 4ct oder weniger, macht bei 250Stk <=10€
Hi,
habe was gefunfen bestelle warscheinlich bei Pollin.
Aber bein Elektro Heini um die Ecke kostet das mal locker 20ct.
Frag den Elektroheini doch einfach, ob er Dir 250 Stk für 13€ liefern kann. Dann sparst Du etwas wg. Versandkosten) und hast den Heini um die Ecke unterstützt.
... ist Dir klar, daß Du das Multiplexen mußt, brauchst also nur 1 x 3 x 9 Transistoren für RGB und 1 x 9 für die einzelnen 9 Stränge .... das sind imemrhin 36 Ausgänge vom ATmega belegt :-)
Oder Du machst das Ganze über Schieberegister ... wenn die dann auch noch 20mA pro LED können, bräuchteste keine Transistoren ;-)
Hmm, mal überlegen:
81 LED's a 3 Farben = 243 Kanäle ...
Da er es "schön fände" diese Dimmbar zu gestalten, wahrscheinlich um bestimmte Einzelfarbwerte einzustellen, kann ich nur sagen ich sehe da relativ schlechte karten das mit einem ATmega zu erledigen ...
Vielleicht mal ein paar Hintergrundinfos:
Mir persönlich ist es bisher nur gelungen mit einem ATmega 16 LED's mittels einer 8 Bit Software PWM anzusteuern (mehr hab ich noch nie gebraucht). Rein rechnerisch dürften auch 24 LED's im Bereich des möglichen liegen.
Allerdings sehe ich da ür Bascom sehr schwarz.
Der Grund ist relativ einfach:
Für eine Software PWM benötigt man einen Timer mit der entsprechenden Routine. Bascom sichert jedoch komplett alle Register in einer ISR (egal ob sie überhaupt verwendet werden). Mit dem daraus resultierendem zeitlichem Mehraufwand wird das Ganze sehr schwer zu realisieren sein (wenn es nicht sogar unmöglich ist).
Mein Lösungsvorschlag für ein voll ansteuerbares LED Raster dieser Größe wäre daher wohl:
Einige Mega 16 mit Software PWM.
Das Ganze mittels eines einfachen Protokolls über USART vernetzen.
Einen Steuercontroller einplanen.
Die andere Möglichkeit die hier angesprochen wurde zieht den Nachteil mit sich, das die RGB LED's eben nicht voll Dimmbar sind.
Denk mal drauf rum.
Grüße,
da Hanni.
Ja, 9X9 sind 81. Da hab ich noch nicht drüber nachgedacht :D
Aber 81 Bildpunkte sind nicht wirklich viel für ein Bild!
Ich bleibe bei meiner Meinung, Handydisplay!
Allerdings sehe ich da ür Bascom sehr schwarz.
Der Grund ist relativ einfach:
Für eine Software PWM benötigt man einen Timer mit der entsprechenden Routine. Bascom sichert jedoch komplett alle Register in einer ISR (egal ob sie überhaupt verwendet werden). Mit dem daraus resultierendem zeitlichem Mehraufwand wird das Ganze sehr schwer zu realisieren sein (wenn es nicht sogar unmöglich ist).
Im Grunde stimmt die Aussage mit den Registern. Aber es ist nur so eine in den Raum gestellte Behauptung! Wieviel Zeit geht beim pushen und pullen der Register denn verloren???
Außerdem kann man selbst das in Bascom ausschliessen. Womit der angebliche zeitliche Verlust auch nicht mehr da ist.
243-fache Software-PWM. Der Code interessiert mich. Ich sage nicht, das es nicht geht. Aber ich glaube es erst wenn ich es sehe.
Im Grunde stimmt die Aussage mit den Registern. Aber es ist nur so eine in den Raum gestellte Behauptung! Wieviel Zeit geht beim pushen und pullen der Register denn verloren???
Außerdem kann man selbst das in Bascom ausschliessen. Womit der angebliche zeitliche Verlust auch nicht mehr da ist.
32 Register die 'ge"popt / -pusht werden
Das SREG wird in ein Register geschoben und ebenfalls auf den Stack geschickt.
Macht:
33 pop (2 Takte)
33 push (2 Takte)
1 in (1 Takt)
1 out (1 Takt)
macht 66 * 2 Takte + 2 Takte = 134 Takte ...
Wenn man dabei bedenkt, dass man bei einer Software PWM möglichst ohne Prescaler arbeitet ist das für einen 8 Bit Timer sehr viel Zeit. (Takt / PWM Auflösung / Timerzählschritte -> 16 MHz / 256 / 256 ~ 244 Hz ...).
und das nur um in einer ISR zu sein ....
Sicher kann man dieses in Bascom abschalten nur sollte man dann wirklich wissen was man tut :D
Nur zum Vergleich: die letzte Software PWM die ich geschrieben hab benötigt ca 80 Takte insgesamt
Das ganze mit 16 Kanälen und 500Hz Refreshrate. Möglich wären auch mehr ... nur soll der µC nebenbei noch was anderes tun ausser LED's ein und auszuschalten.
Allerdings muss ich der Fairnesshalber sagen, das diese eben nur von 0 - 254 regelbar ist (also nicht 100%ige 8 Bit Auflösung sondern eben nur 2^8 - 1 mögliche Zustände).
243-fache Software-PWM. Der Code interessiert mich. Ich sage nicht, das es nicht geht. Aber ich glaube es erst wenn ich es sehe.
Nuja, wenn man das ganze über mehrere Controller verteilt ist das sicher kein Problem. Mit nur einem dürfte es nicht funktionieren.
Nachtrag: Ich will hier definitiv nicht gegen Hochsprachen hetzen. Ich möchte nur auf mögliche Fallstricke der vom Treadersteller favorisierten hinweisen. Sollte dieses dennoch so rübergekommen sein bitte ich hiermit um Entschuldigung.
Grüße,
da Hanni.
66 Takte?
Ich finde es gut, das du eine Antwort auf diese Frage hattest! Das zwuegt schonmal davon das du weisst was du da sagst. Aber was sind 134 Takte bei 20.000.000 Takten in der Sekunde?
0,0000067 Sekunden, bzw. 6,7µS.
Wenn jede LED mit 30Hz "flackern" darf, sind wir da bei etwa 7500Hz pro Durchgang. Damit bleiben über 2500 Takte pro LED und Durchgang un etwas zu bewirken.
Und da ist das sichern der Registern schon abgezogen.
Ok, ich habe jetzt mal einen neueren AVR mit 20MHz genommen ;)
Aber wenn ich das so lese, 2500 Takte. Ich hoffe, ich hab die Rechnung jetzt nicht falsch angestellt! Aber dann denke ich, das man auch an die 100Hz Freshrate gehen könnte.
Ich gebe zu, das ich das nicht erwartet habe. Ich hätte das Projekt als Hoffnungslos abgestempelt ;)
Und von 8 Bit bin ich auch nur ausgegangen. Alles über 8 würde nur wieder Takte "verbrauchen".
243-fache Software-PWM. Der Code interessiert mich. Ich sage nicht, das es nicht geht. Aber ich glaube es erst wenn ich es sehe.
Diese Aussage ziehe ich hiermit zurück.
243-fache Soft-PWM, das mit Bascom, glaube ich erst, wenn ich es sehe :D
Das Projekt mit nur einem Controller in Bascom geht nur, wenn man sich zuvor Gedanken drüber macht, was Bascom aus den Hochsprachenbefehlen macht.
Da erzeugt ein Befehl, der das gleiche bewirkt wie ein anderer Befehl nämlch einen anderen Assemblercode und hat damit eine andere Laufzeit.
Ich würde das ganze wohl mit 10 vielleicht auch nur 5 AVRs machen. Pro (zwei) Zeilen ein AVR und einer für die Bildverwaltung.
Und durch diesen großen Hardwareaufwand wird das Projekt schon wieder uninteressant.
Wobei ich schon gerne mal einen vielfach-Soft-PWM-Code in Bascom sehen würde. Muss ja ncht gleich dreistellig werden ;) 16-fach reicht auch schon.
Um das ? hinter den 66 Takten nochmal aufzugreifen.
Ich hatte dafür eine andere Zahl im Hinterkopf. Zwar auch so in der Größenordnung aber leicht abweichend. Ich muss nochmal in mein schlauches Buch schauen, was dazu steht.
Dennoch hast du vollkommen Recht! Jeden Takt den man da einsparen könnte sollte man nutzen.
Und die 2500 Takte lassen mir keine Ruhe. Ist die Rechnung wirklich richtig so? Die ISR ist da natürlich auch it drinne, aber trotzdem...
Wenn de Rechnung so stimmen sollte, sieht man mal wieder gut, das 16/20MHz für viele Anwendungen mehr als ausreichend sind.
(Außer wenn der AVR USB sprechen können soll)
Aber was sind 134 Takte bei 20.000.000 Takten in der Sekunde?
0,0000067 Sekunden, bzw. 6,7µS.
6,7 µs hören sich vielleicht sehr wenig an. wenn man aber bedenkt, das bei 20 MHz für 256 Takte (8 Bit Timer ohne Prescaler) eben nur 12,8 µs zur Verfügung stehen ist das ganze schon wieder sehr viel Zeit.
Es ist halt alles eine Sache der Betrachtungsweise.
Und die 2500 Takte lassen mir keine Ruhe. Ist die Rechnung wirklich richtig so? Die ISR ist da natürlich auch it drinne, aber trotzdem...
Wenn de Rechnung so stimmen sollte, sieht man mal wieder gut, das 16/20MHz für viele Anwendungen mehr als ausreichend sind.
(Außer wenn der AVR USB sprechen können soll)
Fosz = 20.000.000 Hz
Fref = 100 Hz
Auflösung = 8 Bit = 256
Takte = Fosz / Aüflösung / Fref
Takte = 20.000.000 / 100 / 256
Takte ~ 781 Takte
So, ich hoffe dir damit etwas weiter geholfen zu haben.
Grüße,
da Hanni.
HI,
???. Heißt das das geht oder das geht nicht.
Und was ist denn die beste Lösung
- 3 86 i/o Avr`s
-Schiebregister
-oder dieses 9*3*9
wenn die LED mit 30Hz flackern darf, hast Du bei einem 20 MHz AVR und 243 LEDs 2743 Takte pro LED um deren Helligkeit zu regeln.
Wie's mit Bascom aussieht kann ich nicht beurteilen, aber mit C und SoftPWM sollte das schon klappen.
Sofern Du das in einer Matrix 27x9 aufbaust, kommst Du je nach AVR auch ohne Schieberegister, I2C Port-Extender o.ä. aus.
hi,
hat jemand so etwas schon einmal in Bascom gemacht, wenn ja
kann er ja mal das prog posten
Hallo Furtion,
also ich programmier Dir das gerne - allerdigns in C, mein Stundensatz entspricht dem Deutschen Normal, wir können auch gerne über einen Pauschalpreis reden, Schaltplan und Layout inkulsive :-)
digitali
22.07.2006, 20:14
Mein Gedanke: 4 Bit DA-Wandler mit Widerstandsnetzwerk Stichwort R2R-Netzwerk. Damit koennte man eine Led und eine Farbe in 16 verschiedenen Helligkeiten ansteuern. Das ganze ueber Schieberegister angesteuert. Da muss man dann nichts mehr takten und multiplexen.
Also nochmal: ein 4 Bit Signal wird seriell vom Atmel in ein Schieberegister geschoben. Am Ausgang desjenigen befindet sich ein DA-Widerstandsnetzwerk. An dessen Ausgang wiederum die eine Farbe einer LED. Bei ner 0 0 0 0 leuchtet se gar nicht. Bei ner 1 1 1 1 leuchtet se mit voller Helligkeit. Und das ganze schaltungstechnisch dann pro LED dreimal.
Somit kann man seriell mit 3x4 Bit die ganze LED ansteuern und ziemlich viele Farben erzeugen. Ok, ist zwar ein wahnsinniger Schaltungsaufwand...
Naja aber man hat keine grossartigen Timingprobleme was Takten, Multiplexen usw. betrifft. Einmal nur den ganzen Datensatz in alle Schieberegister schieben und das "Bild" steht. Und dann denke ich ist so was auch mit einem Atmel loesbar.
(Sowas aehnliches hatte ich uebrigens auch schon mal vor. Auch ca. 80 LED's, aber hinter einer Milchglasscheibe und jeweils so 10cm auseinander. Und das ganze in einem Rahmen an die Wand gehaengt. Dann langsam verschiedene Farben und Muster rotieren lassen. Sieht bestimmt huebsch aus).
Hi,
ich dachte jemand hatte so etwas schon geproggt. und das ich das als
vorbild nehme ud dan mit meinem Vater rumprogge. Aber Danke
fürs Angebot.
HI,
???. Heißt das das geht oder das geht nicht.
Und was ist denn die beste Lösung
- 3 86 i/o Avr`s
-Schiebregister
-oder dieses 9*3*9
Es geht.
Allerdings ist der Aufwand davon abhängig was die 81 RGB LED's können sollen.
Gedimmter Betrieb (fast freie Farbwahl der einzelnen LED's):
Bei einer recht weichen 8 Bit Rastung wirst du um mehrere Controller nicht herumkommen, wenn das Bild am Ende nicht flackern soll.
Bei einer wesentlich gröberen Rastung von 6 Bit ist es vielleicht möglich das ganze im Multiplex Betrieb laufen zu lassen.
ungedimmter Betrieb
Einsatz von Schieberegistern / Portexpandern
Um auf den Anfang des Treads zurückzukommen:
Meine Frage wäre jetzt wie ist das am einfachsten Soft- und Hardware technisch zu realieseiren?
Der am wenigsten aufwändige Weg dürfte ein Netzwerk aus mehreren Microcontrollern sein.
Die Gründe die dafür sprechen:
Kein riesiges absolut undurchsichtiges Layout, sondern ein kleines und durchschaubares welches für jeweils 8 LED's zuständg ist und daher mehrfach genutzt wird.
man braucht sich nicht mit den Feinheiten und Fallstricken des Multiplexings zu beschäftigen (sowohl von der Hard- als auch der Softwareseite)
Man hat ein modulares und vor allem erweiterbares System.
@ vajk:
Dein Angebot ist sicherlich lobenswert, wenn er aber Spass an der Sache hat und etwas lernen möchte, wird er es sicherlich ausschlagen. Zumal ihn diese Leistung sicherlich nicht wirklich günstig kommt.
@ ogni42:
Nur, sind mir bei den 20 MHz Typen keine bekannt, welche ähnlich viele IO Ports wie ein Mega 16 oder gar 64 haben
So, ich hoffe zumindest etwas geholfen zu haben.
Grüße,
da Hanni.
HI,
@digitali
Mein Vater will das ganze hinter aufgeplasenen Plastikkissen mit einer Größe von glaube 5*5cm anorden.
Noch eine Frage :
ich kann mir aussuchen ob die RGB`s eine Anode oder eine Kathode
als gemeinsamen port nimmt. Was isit denn wohl besser?
ICh werde warscheinlich diese Wariante mit den pro 8 RGB`s ein Cpip
nehmen. Kann man die dann auch alle in Bascom (voll) dimmen.
ich kann mir aussuchen ob die RGB`s eine Anode oder eine Kathode
als gemeinsamen port nimmt. Was isit denn wohl besser?
Vom Prinzip her ist es relativ egal.
Mein Tip dazu: mach dich einfach mal kundig, welche du persönlich einfacher von der Hardware her ansteuern kannst.
Danach entscheide dich.
ICh werde warscheinlich diese Wariante mit den pro 8 RGB`s ein Cpip
nehmen. Kann man die dann auch alle in Bascom (voll) dimmen.
Diese Frage kann ich so nicht beantworten, allerdings halte ich es für recht schwer. Meine Annahme in der Antwort oben ging von Assembler aus, da ich in dieser "Sprache" wesentlich mehr Flexibilität habe wenn es zeitkritrisch wird.
Mal angenommen, diese sollen mit 100 HZ "flackern" was bei einem Stillstehendem Objekt durchaus als Flimmerfrei bezeichnet werden kann, hat man pro LED (3 * 8 = 24) so ca 26 Takte Zeit um diese zu refreshen (16 MHz Quarz).
Allerdings sollte man dabei bedenken, das man auch noch etwas Rechenzeit benötigt um die Komunikation zu bewerkstelligen.
Mal eine andere Frage: was für LED's sollen es werden ?
(also vom Typ und der Helligkeit her).
Grüße,
da Hanni.
HI,
Diese RGB`s sollen verwendet werden (110006526553 EBAY)
Hi,
also ich habe mich entschieden:
- ich nehme 4 Atmega128 mit 53 I/O`s
- mache das ganze nicht 9*9 sondern 8*8
- so kann ich jedem Controller ein Feld von 4*4 zuweisen
- die Controller vernetze ich dann mit Ic2
- Ein Atmega8 wird dann der Master und steuert alles
- Der MAssepol der 4 Felder wird mit einem PWM ausgestatet
somit kann ich realitiv viel steuern.
Gibt es eigentlich Fassungen für den Atmega128?
ja, gibt es .. nur sind die unbezahlbar ....
... und wie gehts dem Projekt .. schon fertig, Bilder, Berichte ?
Naja eigentlich ist es Latte ob common A oder common C, aber ich würd eher common K nehmen, damit du keine inverse Logik hast. Allerdings liesse sich das bei common A mit einem (bzw drei) vorgeschalteten PNP-Transistor wieder kompensieren, und da du die Transen eh brauchst und PNP und NPN das gleiche kosten sollten, ist es EGAL. Nur halt drauf achten, dass du in der Kombination eine High-Active-Logik herausbekommst.
Das war mein Senf zur letzten Frage, nun mein eigenes Anliegen: Ich hatte sowas auch mal geplant, und hab auch lange drüber nachgedacht. Ich bin zu 2 Möglichkeiten gekommen: Entweder Zeilenweise alle LEDS über einen Controller, also pro Zeile 1 Controller. Diese Controller kriegen über nen Bus ihre Daten, von einem zusätzlichen Controller, der dann auch die Schnittstelle zum User bietet. Andere Möglichkeit: PWM-Multiplexing. Eine Zeile wird von 1 Controller mit Software-PWM versorgt. Dann die nächste, usw. Wie beim Fernseher. Allerdings gingen die ersten Experimente mit einem Software-PWM-Multiplexing auf einer 3x4-einfarb-LED-Matrix ziemlich in die Hose. Das dargestellte Muster ließ sich kaum erkennen. Ich weiss nicht ob es am Timing lag oder an der Idee überhaupt. Ich hatte dann auch keine Zeit mehr für weitere Experimente... die leidigen Prüfungen! ;) Aber ich bleibe immerhin hartnäckig an der Idee dran. Weil Es wurde oft genug bewiesen, dass sowas geht, z.B. hier:
http://www.youtube.com/watch?v=jkqoPkuJaMI
Hi,
es gibt Neuigkeiten im Bezug auf meine 3*3 Matrix. Sie ist soweit fertig.
Ich habe mich am Wochenende hingesetzt und programiert (mehr oder
weniger mit meinem Vater :-(. Nach einer sehr langen zeit bin ich zu dem
entschluss gekommen das die Pull up wiederstände für I²C ja auch wichtig seien könnente, und habe promt gemerk, dass die zwar an den SCL SAL
angeschlossen waren, aber nicht an Plus. Tja also angelötet und es ging.
Heute habe ich noch ein wenig an der Übertragung gearbeitet und an
der Helligkeit. Hier ein paar Bilder weitere + ein Video folgen.
Hi,
ich habe mal ein video gemacht. Goblin wird sich freun *g*
http://video.google.de/videoplay?docid=-7134544193494967718
bei wievielen controllern wirst du rauskommen? du musst ja nicht so viele pwms erzeugen wie ich. ach und gesegnet sei der, der einen lötkolben hat. ich hab keinen, lötstation ist in der reparatur. wenn ich den dann endlich wieder hab kann ich mit ein wenig glück auch meine ersten 20 leds in betrieb nehmen :)
@ Goblin:
Mich würden ein paar Details zu deinem Projekt interessieren.
Zum Beispiel:
- Wie viele Slave Controller hast du?
- Wie viele LED`s steuert ein Controller an?
- In welcher Sprache programmierst du (also die Controller)?
- Wie gleichst du die Lichtempfindlichkeit des Auges aus ?
und so weiter ....
Grüße,
Hanni
@ Goblin:
- Wie viele Slave Controller hast du?
- Wie viele LED`s steuert ein Controller an?
- In welcher Sprache programmierst du (also die Controller)?
- Wie gleichst du die Lichtempfindlichkeit des Auges aus ?
1.: 25
2.: 100/25 = 4
3.: Bascom + Inline-ASM
4.: Bisher gar nicht, wenn nötig per Software
Antworten auf alle Fragen gibts überigens in meinem Blog auf der ersten Seite. (1. Seite != Aktuelle Seite) Das ist die Planung verdeutlicht
Antworten auf alle Fragen gibts überigens in meinem Blog auf der ersten Seite. (1. Seite != Aktuelle Seite) Das ist die Planung verdeutlicht
Nuja, nicht auf alle Fragen :D
Wäre es deiner Meinung nach möglich, die Lichtempfindlichkeit des Auges durch die folgende Vorgehensweise auszugleichen ?
Anstatt einer 8 Bit PWM eine 10 Bit PWM nutzen und die 8 Bit Daten die über den Bus kommen mittels einer Tabelle auf 10 Bit umzumünzen.
Grüße,
Hanni
MartinFunk
15.03.2007, 20:01
dazu braucht man keine tabelle es reicht doch wenn man 8 bit *4 machen
martin
Ich dachte du meinst die nichtlineare Helligkeitsempfindung des menschl. Auges. Wieso willst du denn auf ne höhere Auflösung?
Weil ich mit ner 10 Bit PWM 1024 theoretische Helligkeitsstufen zur Verfügung habe. Theoretisch könnte man darin eine Kurve mit 256 Werten abbilden.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.