Hallo Leute! Ich beschäftige mich jetzt schon etwas länger mit LED Leisten, die ich in den Fahrradspeichen befestige und dort einen Schriftzug, oder auch die aktuelle Geschwindigkeit anzeige. Mein letztes Projekt besteht aus 4 LED Leisten á 16 LEDs, die die Geschwindigkeit anzeigen. Anschauen könnt ihr das ganze hier: http://www.myvideo.de/watch/2227951 Meine nächste Umsetzung soll jetzt aus 4 x 32 RGB LEDs bestehen, die alles von Bildern bis zu kleinen Animationen anzeigen können. Mein Problem ist, wie sich einige bestimmt schon gedacht haben die Ansteuerung, da jede LED 3 Steuerleitungen hat, also insgesamt 96 Steuerleitungen pro Leiste. Um mehr als 8 Farben erzeugen zu können (inclusive weiß und "schwarz") muss jedes Steuersignal auch noch über eine PWM individuell ansteuerbar sein. Jetzt stehe ich vor der Frage ob ich pro Leiste 3 ATmega16 verbaue oder das ganze auf irgendeine andere Art und Weise (vielleicht Schieberegister??) umsetzen sollte. Hat da jemand eine Idee? Gruß Kai
So weit ich weiß wird so was normalerweise mit FPGA's oder CPLD's gemacht. Deinen Tacho finde ich übrigens klasse!
Machen das die meisten nicht über Schieberegister? Ich bin noch nicht wach genug, um die SPI-Frequenz auszurechnen, aber ein ähnliches Vorhaben solltest du hier im Forum finden.
und wenn du pro LED od. für 2 LEDs (R+G+B) einen kleinen Atmel verbaust? Dann brauchst du vom Hauptcontroller nur die Daten schicken, die sich auch verändern. Das spart je nach Anwendung auch einiges an zu schaufelnden Bits. Außerdem können die kleinen ausgelagerten MCUs gleich die PWM übernehmen.
>Dann brauchst du vom Hauptcontroller nur die Daten schicken, die sich >auch verändern. Schon mal ausgerechnet wieviel Daten das so sind?? >us 4 LED Leisten á 16 LEDs, d => je Leiste 2Byte bei an/aus >aus 4 x 32 RGB LEDs => je Leiste 12Byte Je nach Gesamtauflösung (zb 128SPalten) ist das noch zu multiplizieren. Wird jetzt jede Farbe nicht nur ein/ausgeschalten, sondern JE EINE 4bit PWM (also je 16Farbstufen für eine Farbe, 4096 für RGB) so erhöht sich die Datenmenge auf: >us 4 LED Leisten á 16 LEDs, d => 8Byte bei 4bit PWM >aus 4 x 32 RGB LEDs => 48Bytes Diese Angaben sind je Spalte und je Frame. Rechne mal aus, welche Datenraten du da so brauchst. Diese Daten müssen irgendwo hergeholt, gespeichert, verarbeitet und erzeugt werden. Somit bist du mit so nem Atmel schnell am Ende...
Folgender aufbau ist mir gerade in den Sinn gekommen: Du nimmst einen Speicherbaustein (je nachdem wie flexibel du sein willst ein Flash - der könnte nur ein Standbild anzeigen - oder ein SRAM). An die Datenausgänge des Speichers schließt du deine LEDs an. Jetzt musst du nur noch den Adresszähler hoch laufen lassen (mit einer Geschwindigkeit entsprechend der U/min des Rads). Für PWM kannst du die Bilder vorberechnen und musst den speicher dann halt schneller durchlaufen (und die Bilder würden dann auch mehr Speicher einnehmen).
Ah ja, das schreiben der Bilder in den Speicher und ansteuern der Adressleitungen könnte ein AVR erledigen. Du müsstest die LEDs dann halt beim schreiben auf der nicht am speicher liegenden Seite abschalten (auf der Seite haben die dann ja wohl einen gemeinsamen Anschluss) damit der Datenverkehr nicht sichtbar wird.
Danke für die Ideen, dass das ganze mit Schieberegistern zu langsam wird hab ich mir schon gedacht. Was Lupin da vorschlägt verstehe ich nur ansatzweise, es hat aber glaube ich Ähnlichkeiten zu meinem Vorhaben. Ich habe mir zwei Möglichkeiten überlegt: 1: 3 ATmega8515L auf eine Leiste, von denen jeder für eine Farbe zuständig ist. Der Vorteil zum mega16 ist, dass dieser 4 1/2 Ports hat, ich kann somit auch den Hallsensorkontakt auslesen und habe eventuell noch ein paar Pins Luft. Jeder ATmega hat das anzuzeigende Bild in seinem Flash (oder EEPROM) für die entsprechende Farbe gespeichert, berechnet bei jedem neuen Reedkontakt die "Refreshgeschwindigkeit" für die Spalten neu und zeigt die Einträge des Arrays an. Das mit der PWM hab ich mir folgendermaßen vorgestellt: ein Compare Match Interrupt wird alle paar µs aufgerufen und zählt den Index vom Array +1 und legt dann die Daten an die Ports an, dadurch wird die Größe des Array zwar sehr hoch, allerdings habe ich ja auch 3 Controller auf die das Array aufgeteilt ist. Damit das ganze auch von der Zeit ausreichend ist, weil ich schließlich in C programiere hatte ich mir folgenden Ablauf überlegt:
1 | // Timer 0 output compare interrupt service routine
|
2 | interrupt [TIM0_COMP] void timer0_comp_isr(void) |
3 | {
|
4 | if (i < sizeof(BILD)) |
5 | {
|
6 | PORTA = BILD[i]; |
7 | i++; |
8 | PORTB = BILD[i]; |
9 | i++; |
10 | PORTC = BILD[i]; |
11 | i++; |
12 | PORTD = BILD[i]; |
13 | }
|
14 | }
|
Dadurch, dass es sich um ein Compare Match handelt, lässte es sich also fast stufenlos an die Geschwindigkeit anpassen. Der Vorteil an dieses Idee wäre, dass ich alles programmieren kann und sehr wenig Hardware habe. Was ist eigentlich der 0815 LED Treiber für soetwas? Nun zu Idee 2: Ich habe beim Suchen in diesem Forum LED Treiber entdeckt, die manche auch für RGBs verwenden, da jeder Kanal individuell dimmbar ist. Der Vorteil an diesen Treibern ist klar: Der µC wird entlastet und kann sich auf die Berechnung der Geschwindigkeit und das Senden von Daten konzentrieren. Ich weiß nur nicht ob ich wieder Probleme bekomme, dass die zu sendenden Daten zu groß sind und das wie bei den Schieberegistern zu lange dauern würde. Mein Liebling ist der TLC5922, allerdings habe ich keine Ahnung wie ich an den rankommen soll :( So und nun nehmt doch bitte meine Ideen auseinander :D
ja genau die erste Idee hatte ich auch, nur hätte ich die portpins des megas nur als addresszähler her genommen die dann einen externen speicher ansprechen dessen datenleitungen dann die LEDs schalten. Vorteil ist halt, dass du dir einen großen SRAM besorgen kannst und da dein Bild dynamisch mit einem mega von einer SD Karte rein laden kannst. Warum willst du eigentlich 4 Leisten an dein Fahrrad bringen und nicht nur eine? Flackert das mit einer zu sehr? Spezielle LED Treiber würde ich seien lassen - bringt dir glaube ich nix.
Angehängte Dateien:
-
DSC00082.JPG
1,1 MB
>ei den Schieberegistern zu lange dauern Das stimmt nicht. Schieberegister schaffen locker 20MHz Schiebetakt! Bevor du hier mit Hardware und Software um dich schmeist, solltest du dir klar festlegen: -wieviele Flügel -wieviele LEDs pro Flügel -welche LEDs, also einfarbig, rgb... -wieviele "Spalten" also die Winkelauflösung -welche Helligkeitsstufen (an/aus, 4bit,8bit PWM..) -welche Daten (statisch, dynamisch-dann wie schnell soll sichs ändern) -Verbindung zur "Aussenwelt" ? -... Dann kann über eine Realisierung nachgedacht werden...
ich habe jetzt schon drei verschiedene Versionen entworfen. Die ersten beiden hatte nur eine LED, allerdings dreht sich das Rad dafür viel zu langsam. Bei der letzten Version (siehe Video) sind 4 Leisten verbaut, die ausreichen, damit es nicht mehr so arg flackert. Wenn ich ein Bild darstellen will brauche ich also mindestens 4 Leisten, oder mus kräftig in die Pedale treten. Ich habe mir jetzt mal den Treiber genauer angeschaut und bin begeistert was der alles kann! Allein, dass er 128 Dimmschritte hat, die nicht über eine PWM, sondern über Konstantstrom funktionieren. Wenn ich es ohne diesen Treiber mache, habe ich das Problem, dass die PWM sehr hoch sein muss, damit kein Versatz auftritt und dann ist mein Controller wahrscheinlich zu langsam... Ich hab mir jetzt mal ein paar Samples davon bestellt und werde die mal versuchen anzusteuern. Das einzige Problem ist, dass ich noch keinen deutschen Distributer gefunden habe, der die auf Lager hat :(
Hab mir auch eine RGB Propeller Clock mit SPI Schieberegistern gebaut. Als LED Treiber nehme ich 2 MAX6957 die von einem LPC2106 befeuert werden. Die MAX6957 Treiber machen über 20MHz am SPI und funktionieren als einstellbare Konstantstromquelle -> Kein PWM = Kein Flimmern. Farbtiefe bei RGB ist 12Bit.
Der sieht doch auch ganz nett aus, auch wenn 16 Stufen schon etwas übertrieben ist, da komm ich ja auf was weiß ich wie viele Billiarden Farben. Hast du von deinem Projekt vielleicht einen paar Bilder/Codefetzen/Schaltplanfetzen? Würde mich sehr viel weiter bringen. Wo hast du den MAX6957 überhaupt her? Gruß Kai
Bin erst am Montag wieder an meinem eigenen Computer. Poste dann mal was ich habe (Achtung C Noob :-),Schaltpläne in Protel ). Die MAX6957 hab ich als Samples bestellt. Momentan bastel ich das ganze auf CPLDs um,da fliegen die MAX raus.
bevor es jemand merkt... ich habe 16 Stufen mit 16 Bit verwechselt. Mit 16 Stufen komme ich auf gerademal 4096 Farben, sollte aber reichen. Der Vorteil an dem Chip ist, dass man mehrere LEDs an nur einen Chip hängen kann. Freue mich auf Schaltplan und Bilder :) PS: C-Noob bin ich übrigens auch, sobald ein << Befehl drin ist, steig ich aus, ich mach das immer mit Zahlen^^
@Matthias: sorry, hatte den Beitrag komplett überlesen Da ich schon mehrere Projekte damit gemacht habe, ist mir das fast alles schon klar, aber für euch schreibe ich das gerne nochmal auf -wieviele Flügel beliebig viele -wieviele LEDs pro Flügel abhängig von der Realisierung, mindestens 32, maximal 60 -welche LEDs, also einfarbig, rgb... RGBs von ebähh (taugen die überhaupt was?) -wieviele "Spalten" also die Winkelauflösung 256 oder 512, mal sehen -welche Helligkeitsstufen (an/aus, 4bit,8bit PWM..) hängt von der Realisierung ab, mindestens sollte es aber 256 Farben sein, da ich Bilder darstellen möchte -welche Daten (statisch, dynamisch-dann wie schnell soll sichs ändern) statische Daten, also ein Bild, das in einem festen Array gespeichert ist -Verbindung zur "Aussenwelt" ? keine, Akku ist onboard, einzig und allein ist ein Magnet an der Gabel notwendig -... ...
Hab mir gestern auch mal ein paar Samples vom Max bestellt und werde mal schauen wie weit ich damit komme. Der Schaltplan sollte kein Problem sein, habe hier auch ein Eigenbauprovisorium zur Platinenherstellung, mein Problem ist einerseits die Ansteurung (sollte aber machbar sein) und dann später das Programm für die Bilder. Das werde ich wohl nicht selberschreiben können. Wie hast du das gemacht? Ich müsste Bilder laden können, die dann in mein Radialdisplayformat umgerechnet werden. Wie hast du das gemacht?
Hallo Kai, gibts eine Internetseite mit Details zu dem Tachoprojekt?? Randy
nein, ich habe das alles selber programmiert und sogar die Zeichen alle mit einem selbst geschriebenen Programm designed. Wenn du Interesse am Nachbau hast, kann ich dir gerne den Code zuschicken, einen Schaltplan habe ich nicht, der ist aber auch so simpel, dass ich den in 3 Sätzen erklären kann. Bei Interesse am besten ICQ : 177183299 Gruß Kai
So , hab mal alles zusammengepackt was ich gefunden hab. Da das Projekt schon etwas älter ist und ich nach dem Chaotischen Ordnungsprinzip Arbeite ist natürlich nicht mehr alles so schnell auffindbar :-) Da es immerhin 14MB sind hab ich es auf meinen Server hochgeladen, Du kannst es hier saugen : http://drunken.intershit.com/Rotoblink_MC.net.rar
Und noch ein paar Infos dazu: Der Rotorkopf ist eine Videorekorder Kopfscheiben Einheit (Panasonic). Spannungsversorgung und Daten werden Induktiv zum Rotor gekoppelt. Knapp 2MBit bekomme ich zum Rotorkopf. Die Position des Rotors wird per Hall an den uC gemeldet. Die Auflösung ist momentan durch den RAM und der SPI Geschwindigkeit des uCs begrenzt , deswegen ist das ganze erstmal auf Eis gelegt bis ich das alles auf CPLDs portiert habe.
vielen Dank erstmal, ich hoffe das bringt mich weiter, es ist auf jeden Fall ein gut dokumentiertes Projekt! Was ich sehr geil finde ist die induktive Datenübertragung :) Ich werde die Daten entweder über ein RFM12 Funkmodul oder über eine Speicherkarte übertragen. Ist die SPI Übertragung so langsam, dass man nichts anzeigen kann? Wenn ja hoffe ich, dass das bei meinen Geschwindigkeiten (Fahrrad) nicht auftreten wird. Kanns du dazu irgendwas sagen ob das reichen wird? Ich habe vor bis zu 40 RGB LEDs zu benutzen, brauche dafür also 6 Controller. Hast du vielleicht eine ICQ Nummer falls ich noch Fragen zu dem Projekt habe? Gruß Kai
Eigentlich nicht , den uC den ich benutzt habe war ein Fehlgriff. Der LPC2106 macht "nur" ca. 7MHz SPI Takt. Ein Pinkompatibler uC , LPC2103, macht da schon einiges mehr hat aber leider etwas zuwenig RAM. BTW: Hab Dich mal im ICQ geaddet.
Das mit ICQ hat wohl nicht funktioniert, bei mir ist keine Anfrage reingekommen...schick mir doch einfach deine über das Nachrichtensystem vom Forum. Ich möchte einen ATtiny2313 oder ATmega 8 benutzen. Den tiny bekomme ich auf 20MHz, den mega8 auf 16MHz, was für einen SPI Takt die schaffen weiß ich nicht, werde ich aber sofort mal nachschauen, der MAX schafft ja biszu 20MHz. Außerdem werde ich mal ausrechnen wie viele Byte/sek ich überhaupt senden muss, wenn ich bis zu 40 RGBs füttern will.
[Doku existent?] > nein, ich habe das alles selber programmiert und sogar die Zeichen alle > mit einem selbst geschriebenen Programm designed. > Wenn du Interesse am Nachbau hast, kann ich dir gerne den Code > zuschicken, einen Schaltplan habe ich nicht, An den Teil hätte mich eher die mechanische Konstruktion interessiert, denn das wäre für mich die größere Herausforderung. Wie hast du das Teil an den Speichen befestigt? (Bei 40km/h und einer 28" Felge wirkt außen auf die Konstruktion immerhin eine Beschleunigung von 35g, "irgendwie" festtackern ist da nicht mehr) Randy
und ich dachte, ich könnte die mechanische Konstruktion verschweigen.... irgendeiner kommt einem doch immer auf die Schliche *grrrrr Der "Trick" besteht darin die Akkus so nah wie möglich am Mittelpunkt zu "montieren", da die Platine nicht viel wiegt, machen die Beschleunigungskräfte gar nichts aus. Die "Montage" besteht aus fast 2 Stangen Heißkleber *schäm
so einen Nabendynamo hab ich sogar am Rad, allerings funktioniert der genau anders herum. Die Spannung kann man leider nur von außen abgreifen
Kleine Frage, dreht sich dein Rad überhaupt schnell genug, um das "Propeller Clock" Prinzip anzuwenden? Meiner Meinung nach braucht es eine recht hohe Drehzahl um ein Bild "stehend" hinzubekommen. Oder bist du sowieso ein Downhill Rennfahrer? :)
wenn ihr euch mal das Video im ersten Thread anschaut, seht ihr, dass es zwar etwas flimmert, aber dennoch gut lesbar ist. Ich hatte auch längere Zeit nur eine Leiste im Rad und auch das konnte man, wenn auch nicht so leicht, erkennen. Wie irgendwo oben schonmal geschrieben komme ich mit 24km/h auf 12 Bilder/sek mit Leisten. 20 wären nötig um ein stehendes Bild hinzubekommen. Und wenn 4 Leisten nicht reichen sollten, spricht ja nichts dagegen mehr als 4 zu verbauen
@ Fly (Gast) >Kleine Frage, dreht sich dein Rad überhaupt schnell genug, um das >"Propeller Clock" Prinzip anzuwenden? Meiner Meinung nach braucht es >eine recht hohe Drehzahl um ein Bild "stehend" hinzubekommen. Mal rechnen. Bei 40 km/h (11,1 m/s) hat ein 28' Rad (71cm Durchmesser, 2,23m Umfang) eine Drehzahl von ~5 Hz, macht bei 4 LED-leisten effektiv 20 Hz. Naja, geht so, wird noch ein wenig flimmern, aber cool isses schon. Die Dinger gibts auch für Autos, dort ist die Drehzahl weniger das Problem ;-) MFG Falk
danke für die Rechnung, wenn ich 40km/h fahre, wird man das Bild nur nicht sehr lange sehen können :P Und ja, für Autos gibts das auch schon, allerdings bezahlt man da locker mal 15000$ Um jetzt wieder etwas produktives zu tun wollte ich mal fragen wie ihr die Datenübertragung am besten findet. Idee 1: externe Speicherkarte für den Cardreader Idee 2: Funkübertragung der Bilder mit einem RFM12 (hab ich schon aufgebaut) Idee 3: Bluetooth
also ich finde das ganze wird mit einer externen Speicherkarte wohl am leichtesten realisierbar sein, weil ich sowieso mehr Speicher brauche als mir der ATmega8 bieten kann... Infrarot finde ich ein bissche ungeschickt, weil man da einen Laptop braucht, der Infrarot hat. am Benutzerfreundlichsten wäre wohl das Funkmodul, weil man dann von seinem Zimmmer aus das Rad programmieren kann, das vor der Tür steht.
>weil man da einen Laptop braucht, der Infrarot hat.
Nein. Das was du meinst, ist IRDA.
Ich meinte RS232, also Tx, Rx über Infrarot...
>Und ja, für Autos gibts das auch schon, allerdings bezahlt man da locker mal 15000$ 15.000$ reichen nur knapp, waren fast 24.000 ;-)) http://www.clipfish.de/player.php?videoid=NTIxMXwyNDk%3D&cat=1
Ich würds per Schleifkontakt machen. Muss ja dort nicht sonderlich klein sein, nur gegen Dreck und Wasser resistent.. Wollte sowas schonmal bauen, habs aber aus TÜV-Bedenken sein gelassen..
Die Felgen haben sogar ein "Wireless Modem" integriert, habe ich gerade gelesen. 15.000 USD stimmen übrigens doch, sorry... Googlefutter "pimpstar led rims"
Doch zurück zum Thema (BtT?) http://www.adafruit.com/index.php?main_page=product_info&products_id=5 Wir waren ja beim Fahrrad :-)) edith http://www.instructables.com/id/EQ8CBZBN7DEP286MR8/
der Link ist hier glaube ich schonmal aufgetaucht, aber das ist doch auch nicht das, was ich will Ich möchte eine RGB Lösung, außerdem haben die nichts innovatives... Die Übertragung für neue Bilder geschiet über einen Dongle, den man noch dazukaufen muss und wie es aussieht muss man ebenfalls entweder das Rad zum PC bringen, oder die Leiste jedes Mal ausbauen. Die Lösung 'wireless' finde ich eigentlich am interessantesten, weil man wie schon geschrieben den PC nicht zum Rad bringen muss. Falls das ganze im Auto verbaut werden soll, kann ich nur empfehlen das alles in eine Radkappe reinzupacken, die kann man ja vor dem TÜV Besuch schnell abnehmen... zu den Preisen von den Pimpstarfelgen, ich glaube die haben mal über 20000$ gekostet, sind jetzt aber billiger geworden Schleifkontakte finde ich persönlich keine schöne Lösung weil es sehr schwer ist diese am Rad/Auto anzubringen und dann auch noch wasserdicht zu machen. Ich finde es spricht nichts dagegen (zumindest beim Fahrrad) die Akkus/Batterien mitrotieren zu lassen. Bei Auto muss man das nochmal überdenken, weil es auch bei einer etwas schnelleren Autobahnfahrt drin bleiben soll :P
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.