Hallo, für die Entwicklung einer großen (70 RGB LEDs Radius) Propeller Clock benötige ich wie sich einiges schon denken können eine Menge Daten. Für die Ansteuerung möchte ich einen ATmega128 mit 16MHu benutzen, der aber allein mit der Ansteuerung der LED Treiber schon zu 86% ausgelastet ist. Da die Daten über Hardware SPI übertragen werden, kann ich während der Übertragungszeit selbstverständlich auch andere Dinge tun, deshalb sind die 86% eher eine Nenngröße... Da ein Bild eine Größe von ca 86kByte hat, kann ich gerade mal ein Bild speichern, was selbstverständlich zu wenig ist. Jetzt bin ich am Überlegen wie ich den Speicher erweitern kann. Ich könnte beispielsweise den ATmega2560 verbauen, dann hätte ich doppelt so viel, allerdings würde auch das nicht reichen, da ich mind 10 Bilder, besser mehr speichern wollte. So... und jetzt kommt die eigentliche Frage: Was könnt ihr mir empfehlen? Habe mir FRam angeschaut, ist aber recht teuer dafür, dass man nur so wenig speichern kann... Wie wäre es mit Flash Eeprom? Da würde Preis und Speichervolumen passen. Wegen der kurzen Zeit in der die Daten übertragen werden müssen (6,9MBit/s) kommt eigentlich nur eine Parallelansteuerung in Frage... Was habt ihr da für Ideen? Vielen Dank schonmal wiedermal der Kai
70 RGB LED's? Wuff. Bekommt man da nicht so langsam unter anderem Probleme mit der Ansteuerung, da ja die äusseren LED's eine dann erheblich grössere Fläche als die inneren LED's abdecken? Und die 86KB jetzt können ja wohl nur FLASH sein? Dürfte ja relativ langsam zu lesen sein, zumindest als Daten? Aber Hardware-SPI und nebenbei was machen? Nicht so wirklich mit den AVR's, wenn der SPI schnell sein soll. 1 Byte jeweils als Sende- und Empfangs-Puffer sind ja eher ein Witz.
>iner großen (70 RGB LEDs Radius) Propeller Clock Haben wir schon gebaut. 64 RGB Leds. aber GROSS?? >schon zu 86% ausgelaste Da machst du was falsch. >bertragungszeit selbstverständlich auch andere Dinge tun Träumer! >Bild eine Größe von ca 86kByte hat, kann ich ger Welche Auflösung hast du? >6,9MBit/s) kommt eigentlich Nochmal: TRräumer!
Hallo Kritiker (ist nicht böse gemeint) Ich habe schon eine Propeller Clock mit 72 SMD RGB LEDs und den MAX6957 am Laufen. Auflösung ist allerdings nur 240 Aktualisierungen/Umdrehung. Natürlich drehen sich die äußeren LEDs schneller, als die Inneren, dafür habe ich allerdings ein VB Programm geschrieben, das mir das umrechnet. Bilder/Videos kann ich heute hoffentlich machen und hochladen. Jetzt zu der großen Propeller Clock. Ich möchte 70 Stück 10mm RGB LEDs (Treiber wird diesmal TLC5922) nehmen und komme damit wohl auf einen Durchmesser von über 1,5 Meter, was man durchaus als groß bezeichnen kann. Als Auflösung habe ich mit 440 Aktualisierungen/Umdrehung gerechnet. Sicherlich kann man die Zeit während der Übertragung auch beim AVR nutzen! Genau das tue ich nämlich bei der Version, die bereits läuft denn die Übertragung von einem Byte braucht immerhin 16 Clocks, währendessen man einiges machen kann. Die 86% habe ich folgendermaßen berechnet: Ein Treiber kann 5 RGB treiben und braucht 112 Bit mit 70 LEDs und 10U/s komme ich auf 6,9MBit/s was bei einer SPI Frequenz von 8MHz durchaus möglich ist. 6,9 / 8 = 86% Gibt es denn solchen Speicher, den ich etwa in der geforderten Geschwindigkeit ansprechen kann? Grüße Kai PS: Ein Bild von der Platine mit den 72 RGB SMDs hab ich schonmal angehängt
Nimm einen 128k oder 512kByte SRAM (gibts z.B. bei Reichelt billig). Pro Byte benötigt ein mega128 4 Takte (mit 1 Waitstate). Viel nebenbei machen geht daher nicht, da du zwar nur 5 der 17 Takte was machst, aber da noch sinnvoll eine Nebentätigkeit einbauen wird nichts. Wenn ich richtig gerechnet habe, brauchst du 1568Bits für die 70 LEDs, macht 196Bytes, also 3332 Takte bzw. 208,25µs. Mit dem ganzen Overhead der noch dabei ist (Interrupt usw.) ganz grob rund 220µs. Theoretisch sind also bei 440 Aktualisierungen pro Umdrehung 10,3 Umdrehungen pro Sekunde drin (bei 100% Auslastung !)
Wenn ich mich nicht irre ist SRAM doch flüchtig und fällt daher raus. Die verschiedenen Bilder sollen nach Möglichkeit auch bei Power-off erhalten bleiben. Wenn das allerdings die geschickteste Möglichkeit ist, werde ich das SRAM eben konstant mit Strom versorgen, ist nur ein bisschen unschön wegen Batteriewechsel usw. 10U/s sind das, was ich erreichen will, da ich zwei Propeller habe und damit auf 20U/s komme. Eine Nebentätigkeit außer den Reedkontakt abfragen ist nicht geplant.
@ Kai Franke (kai-) >10U/s sind das, was ich erreichen will, da ich zwei Propeller habe und >damit auf 20U/s komme. ??? Es sind immer noch 10U/s, nur eben dann 20 Bilder/s. >Eine Nebentätigkeit außer den Reedkontakt abfragen ist nicht geplant. Ich würde lieber einen Hallsensor nehmen. Kostet praktisch auch nix und ist schneller und verschleissfrei. MfG Falk
hast Recht, wollte auch 20 Bilder/s schreiben... Bin noch am überlegen ob ich einen Reedkontakt, Hallsensor oder IR Schranke nehme, ist aber auch erst einmal uninteressant. Wie mach ich das jetzt mit dem Speicher? Ist Flash Eeprom schnell genug? @Benedikt: hab versucht deine Rechnung nachzuvollziehen, allerdings weiß ich nicht wieso du 196Byte x 17 und nicht x 5 rechnest? Wenn es tatsächlihc nur 5 Clocks braucht um 1 Byteabzuholen, wär das doch ideal! Dann könnte ich doch über SPI ein Byte rausschicken (dauert 17 Clocks) und hole dann während der Übertragung ein neues aus dem SRAM (dauert 5 Clocks). Dann kann ich wieder senden. Jetzt müsste man Flash Eeprom nur noch genauso schnell ansteuern können und ich wär super glücklich :)
Kai Franke wrote: > Ist Flash Eeprom schnell genug? Geht auch. Gibts bei Reichelt auch für wenig Geld. Ich würde die 29Fxxx nehmen und nicht die 29Cxxx. Die sind zwar beim Löschen langsamer, lassen sich aber Bytweise beschreiben. > @Benedikt: hab versucht deine Rechnung nachzuvollziehen, allerdings weiß > ich nicht wieso du 196Byte x 17 und nicht x 5 rechnest? Du brauchst: - 4 Takte zum Lesen eines Bytes (aus einem SRAM oder Flash, ab und zu noch etwas mehr, da du ja nur 32kByte wirklich per Hardware ansteuern kannst, die restlichen Adressleitungen musst du per Software machen) - 1 Takt zum Schreiben in das SPIDR Das SPI Interface braucht aber 17 Takte um ein Byte zu senden. Mit anderen Worten: Du hast nach jedem Byte 12 Takte Zeit, die du irgendwie verbringen musst.
Ins FLASH speicherst du deine Bilder in kompimierter Form. Beim PowerUp enpackst du diese Bilder ins SRAM. Statt internen FLASH könntest du aber auch einen externen SPI FLASH oder sogar eine SD/MMC Karte nehmen. Deine Auslastung von 89% könnte man noch drastisch reduzieren. Dazu musst du aber höchst wahrscheinlich deine Verdrahtung der Shiftregister verändern. Du hast sie jetzt wohl als einfache Kaskade verschaltet an der die RGB LEDs gemischt verschaltet sind, also RGB von 1. LED dann RGB von 2. LED usw. Die bessere Verdrahtung wäre es den Rot-Grün-Blau Kanal separat zu kaskadieren. Also für 70 Rot-LEDs eine Kaskade, eine weitere für alle Grün und noch eine für Blau. Du hast also dann 3 Daten-eingänge für 3 Kaskaden. Statt nun auf einer Datenleitung per SPI die Daten zu senden wird per Software auf 3 Datenleitungen in parallel die Daten rausgeschoben. Wenn man jetzt noch das Pixelformat der Farbbytes entsprechend wählt und einen Port des ATMegas als programmierbaren Multiplexer konfiguriert dann hast du eine direkte Hardwarebasierte Dekodierung der Farbpixel. Damit kommst du auf einen höheren Datendurchsatz pro AVR Takt samt Dekodierung als wenn du das SPI dafür benutzt. Bei 64 RGB LEDs und 512 Spalten pro Umdrehung und 64 darstellbaren Farben, kommst du auf ca. 20% Prozessorlast. Man benötigt dann pro 1 Datenbit für Rot+Grün+Blau Kaskade exakt 5 AVR Takte um aus dem externen SRAM das Pixel zu laden, dekodieren und in die 3 Kaskaden zu schieben. Das *64 LEDs ergibt 320 AVR Takte in der ISR. Diese ISR muß pro Pixelspalte 2 mal aufgerufen werden um effektiv pro Pixel mit 64 Farben arbeiten zu können. 640 Takte * 512 Spalten = 327680 Takte pro Umdrehung, grob gerechnet also 350000 Takte = 21ms = 47 Bilder pro Sekunde = 100% CPU Auslastung. 20/47*100% = 42% Auslastung bei 20 Bilder/sec. Gruß Hagen
Vielen vielen Dank! Du hast mir echt geholfen, ich werde also wohl ein Flash ansteuern und das ganze byteweise während der Übertragung auslesen. Die Übertragung wollte ich wie bei der schon funktionierenden PropClock machen. Ein Reedkontakt (oder ähnliches) gibt ein Signal, woraufhin der Controller die benötigte Zeit durch 440 teilt und den OCR1 auf den Wert setzt. Während des Interrupts werden die Treiber angesteuert (so schnell wie möglich). Danach springe ich wieder in die main routine und habe Zeit (wird nciht viel sein) auf den nächsten Reedkontakt warten. Na dann.... auf in den Kampf, das Projekt gibts dann hoffentlich bald in der Codesammlung :)
@ Hagen: Das Prinzip klingt wirklich logisch und vielversprechend, allerdings wird das auf meiner Platine schlecht umsetzbar sein, da ich nur ein Doppellayer machen wollte. Verschiedene Treiber für verschiedene Farben würden einen riesigen Routingaufwand auf meheren Layern geben. Die TLC5922 mögen eben nur SPI. Verkabelt habe ich sie so, dass ich die Daten und Clock Leitung parallel angeschlossen habe und jeder Treiber hat sein eigenes CS Sollten es mehr LEDs werden, muss ich aber wohl die Darstellung ändern
Wieviele Fraben pro Pixel willst du darstellen ? Gruß Hagen
mit dem Treiber schaffe ich 128 Stufen, also über 2mio Farben und das ist hübsch, muss aber nicht sein :P
@Kai Franke: Du hast weiter oben geschrieben, das du bereits eine "kleine" version geaut hast. Hast du da mal Bilder von? Würde gerne mal sehen, wie es fertig aussieht. gruß Gunni
Hallo nochmal, mir ist dank Hagens Beitrag eben noch eine Idee gekommen: Da das daisy-chaining bei diesem Treiber eine zu hohe Verzögerungszeit hat, steuer ist jeden Treiber über seinen eigenen CS an. Wäre es nicht viel sinnvoller alle SCLK und CS Signale parallel zu schalten und jedem seinen eigenen Dateninput geben? Klar müsste ich die SPI dann über Software steuern, allerdings könnte ich alle Treiber gleichzeitig und viel viel schneller mit Daten versorgen und ich habe genausoviele Pins verbraucht. Dann wäre eventuell auch noch der Anschluss einer SD Karte denkbar, da die SPI Schnittstelle wieder frei wäre.
Angehängte Dateien:
-
Bildklein.JPG
52 KB
@gunni: Ein Bild von der Platine habe ich weiter oben schonmal angehängt, im Betrieb habe ich noch kein Bild gemacht, weil ich es für meine Handy Kamera nicht schnell genug drehen konnte. Sobald ich es schaffe, werde ich auch Bilder posten. Im Anhang hab ich mal den Vorgänger mit nur 20 RGB LEDs und noch keiner Entstreckung wegen der Drehung (schon länger her). Das ganze ist in den Fahrradspeichen betrieben, deshalb das Loch in der Mitte
SD Karte kann Probleme geben, außer du verwendest einen externen RAM. Das Problem bei der SD Karte ist nämlich, dass diese nur 512Bytes ununterbrochen liefern kann, danach muss sie den nächsten Sektor in den internen Puffer nachladen. Das geht zwar meist sehr schnell, aber ob das schnell genug ist, müsste man ausprobieren. Was du machen könntest: 8 von den LED Treibern parallel schalten, RD\ an den SPI Clock, D0-7 an die 8 Dateneingänge. Bei jedem Lesen eines Bytes aus dem externen RAM/Flash würden die Bits dann automatisch in den LED Treibern landen. Quasi so eine Art Pesudo DMA. Damit wären bei 4MHz bis zu 4MByte/s möglich... Wenn der SRAM groß genug ist, könnte man im Hintergrund an einer anderen Stelle in diesem das nächste Bild laden, und dann die Anzeige auf dieses umschalten. So würde die Geschwindigkeit der SD Karte keine Probleme machen, man könnte ein richtiges Dateisystem verwenden, und sogar die Bilder als 24bit BMP Dateien speichern. Die Umwandlung des Formates würde dann beim Laden in den RAM passieren.
externes SRAM brauch ich bei der SD Karte wohl nicht, da ich einen mega128 verwenden wollte und der ja schon 4kB hat wenn ich mich nicht irre. Wegen den 512Byte habe ich eine SD Karte auch anfangs ausgeschlossen, weil die Schnittstelle bis zum Ende der Übertragung "blockiert" ist. Das mit dem RD hab ich ehrlich gesagt nicht kapiert, scheint zur Speichererweiterung des mega128 zu sein, aber SDRAM kommt wie gesagt nicht in Frage, da ich die Bilder auch noch bei Power OFF gespeichert haben möchte. Mit meiner "Idee" könnte ich die Daten allerdings um einiges schneller übertragen. Nehmen wir an ich wollte 80 RGBs ansteuern, dafür bräuchte ich 16 Treiber. Also wären zwei PORTs für die Datenübertragung zuständig. Der Code könnte zB so aussehen: unsigned char Bild[ne Menge]; CS = AN; PORTD = Bild[0]; PORTB = Bild[1]; SCLK = 1; SCLK = 0; PORTD = Bild[2]; PORTB = Bild[3]; SCLK = 1; SCLK = 0; . . . CS = AUS damit wär ich bestimmt um einiges schneller als 4MBit/s und hab noch genug Zeit das nächste Bild zu holen
>PORTD = Bild[0];
Bist du sicher, dass das so geht??
Du gibst die Bits ja so parallel aus, und nicht, wie beim Empfänger(SPI)
seriell erwartet wird...
ich bin mir eigentlich recht sicher, dass das funktionieren sollte, da der Empänger ja seine SPI bekommt (über Software SPI mit CS und SCLK) selbstverständlich müssen die Daten in der richtigen Form vorliegen, der Helligkeitswert der ersten roten LED ist somit in dem Array unter dem Index Bild[0], Bild[2],...., Bild[10], Bild[12] immer als MSB gespeichert. Ein VB Programm bekommt das locker hin
Ja, ok. Da du ja nur darstellen willst, sollte das gehen.
Also ich würde schon mit externem SRAM arbeiten und SD Karte. Normalerweise möchte man in einer einfachen Animation zb. pro Sekunde 1 Bildwechsel vollziehen, und damit jedes dieser Bilder für zb. 20 Umdrehungen anzeigen. Also würde man im SRAM den dekodierten Bildpuffer und die FAT-/Datei Buffer für die SD Karte ablegen. Während der Display-Puffer angezeigt wird wird im Hintergrund von der SD Karte gelesen und das neue Bild dekodiert in einen 2. Display-RAM-Puffer. Wenn die 1 Sekunde rum ist schaltet man nur zwischen diesen beiden Displaypuffern um. Zudem bestehen viele Animationen defakto nur aus 2-3 Hintergrundbildern und dadrüber dann vereinzelte Sprites=kleinere bewegte Objekte. Auch dafür lohnt es sich einen 64-512Kb SRAM anzuschließen. Wenn man es geschickt anstellt so kann man also ganz in Ruhe von SD Karte die Daten im Hintergrund lesen, dekodieren und in SRAM Objekte umwandeln. Im Vordergrund steuert der AVR die LEDs an und berechnet die Animationen, eg. bewegt die Sprites. Je mehr SRAM vorhanden ist desto besser. Gleiches gilt für Fonts. Problematischer finde ich den 7Bit/LED Modus der Shiftregister. Denn die Dekodierung der Pixeldaten und anschließende Umformung in 7 Bit Packete für das 8 Bit SPI kompatibel, halte ich für relativ Zeitaufwändig. Diese verbrauchte Prozessorzeit musst du nämlich auch noch berücksichtigen, neben der reinen Ansteuerung der Shiftregister. In meinem obigen Rechenbeispiel ging ich von anderen Voraussetzungen aus. Dort wird keine Softwaredekodierung der Pixeldaten mehr benötigt. Ein Pixel = 8 Bits = 6 Bit Farbinformation jeweils 2 Bit für RGB. Das lässt sich über das DDR Register eines Ports des AVRs quasi als Multiplexer geschaltet, 3* 2 zu 1, dekodieren. In meiner Rechnung ist also keinerlei Softwaredekodierung der Pixeldaten mehr notwendig, ergo: die 47% Auslastung beinhaltet die komplette Darstellung einer 64 Farbenbitmap. Gruß Hagen
Kai Franke wrote: > externes SRAM brauch ich bei der SD Karte wohl nicht, da ich einen > mega128 verwenden wollte und der ja schon 4kB hat wenn ich mich nicht > irre. Kai Franke wrote: > Da ein Bild eine Größe von ca 86kByte hat Irgendwas passt an deinen Aussagen also nicht....
>>Denn die Dekodierung der Pixeldaten und anschließende Umformung in 7 Bit >>Packete für das 8 Bit SPI kompatibel, halte ich für relativ >>Zeitaufwändig. Die Sache ist, dass der Controller ein 7 x 16 = 112 Bit Register hat in die ich Daten reinschiebe. Da 112 wieder durch 8 teilbar ist, muss ich 14 Byte reinschieben um 5 RGBs anzusteuern (ich benutze aus Gründen der einfachereren Rountingmöglichkeiten nur 15 Ausgänge) Um ehrlich zu sein ist mir die Dekodierung um Hintergründe und Fonts usw zu unterscheiden ein wenig zu kompliziert, mir reicht es wenn ich mehrere Bilder anzeigen kann. @ Benedikt Ich hatte es nicht so gedacht, dass gleich ein ganzes Bild ausgelesen wird, sondern, dass immer 512Byte in das SRAM geladen werden (über hard SPI) und dann über Soft SPI an die Treiber verteilt werden. Währendessen kommen die nächsten 512Byte von der SD Karte an. Wenn das nicht möglich sein sollte lass ich mich auch gerne etwas besseren belehren, habe noch nie mit SD Karten gearbeitet PS: Echt super Unterstützung hier im Forum!
Kai Franke wrote: > Ich hatte es nicht so gedacht, dass gleich ein ganzes Bild ausgelesen > wird, sondern, dass immer 512Byte in das SRAM geladen werden (über hard > SPI) und dann über Soft SPI an die Treiber verteilt werden. > Währendessen kommen die nächsten 512Byte von der SD Karte an. Wie bereits gesagt: Gleichzeitig ausgeben und die neuen Daten einlesen ist nur schwer möglich. Das was ich beschrieben habe, ist genau das was Hagen nochmals genauer erklärt hat: Bild von der SD Karte in ein externes RAM laden und die Bits so umformen, dass diese optimal ausgegeben werden können. Für jedes Byte das aus dem externen RAM gelesen wird, erzeugt der AVR einen Impuls auf der RD\ Leitung. Diesen kann man auch als Schiebetakt für SPI nutzen. Nur so erreicht man wirklich 4MByte/s.
>PS: Echt super Unterstützung hier im Forum!
Natürlich. Sind ja hier alles Leute, die den ganzen Tag (auf Arbeit)
nichts anderes zutun haben, als diese Seite hier zu pollen ;-)
**duck und weg**
hab bei deinem ersten Beitrag wohl das Byte überlesen und es durch Bit ersetzt ;) Das wär wohl wirklich die schnellste Möglichkeit, allerdings muss ich mir überlegen ob ich deshalb wirklich noch externes SRAM anschließen will oder ob mir die paar MB, die ein externer Flash hat auch reichen
hab gerade mal ein Testprogramm für den mega8 geschrieben, weil ich gerade keinen mega128 da habe, aber vom Timing sollten die ja gleich sein... habe zwei Ports zur Datenübertragung, einen Pin für CS und einen für SCLK gewählt und die Datenübertragung von 16mal 112Bit simuliert. Vorher den Timer1 resettet und danach den Wert auf dem LCD ausgegeben. Ergebnis: 1411 Clocks Wenn ich mich nicht vertan hab, komme ich bei 16MHz dann auf 2,54MByte/s Nach den 1411 Clock hab ich dann genug Zeit die nächsten 112 x 16 Bit aus dem Speicher ins SRAM zu laden
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.