Hallo,
ich habe mir mal zum Spaß einen WS2812 Streifen gekauft und damit
rumgespielt. Es gibt ja hier eine Bibliothek mit der das super
funktioniert. Jetzt habe ich lustige Effekte programmiert und habe auch
noch eine Fernbedienung reingehängt. Dazu habe ich auch den Code aus dem
Forum genommen (IRMP).
Leider habe ich jetzt rießige Timingprobleme.
Beides getrennt funktioniert. Die WS2812 Ausgabe schaltet, um das Timing
einzuhalten die Interrupts ab. Die Ausgabe muss aber recht flott
erfolgen. Leider ließt dann die FB keine Werte mehr ein, da ihr Timing
völlig zerstört wird.
Gibts da geschickte Lösungsmöglichkeiten? Oder braucht man einen zweiten
Prozessor, unter der Annahme, dass die Ausgabe nicht verändert werden
darf?
Selbst wenn die Ausgabe langsammer laufen dürfte, würde die FB doch
Signale verpassen, wenn Sie dann kommen wenn die Ausgabe gerade läuft.
Dank & Gruß
Ohne, dass du deinen Code postest, werden wir hier nur vage Tipps geben
können ;-)
Einen davon hast du ja schon genannt. Nimm einen zweiten Prozessor wenn
du mehrere zeitkritische Sachen gleichzeitig zu erledigen hast. Der kann
ja dann per Handshake zum richtigen Zeitpunkt Daten mit dem anderen
austauschen.
Evtl. kannst du die Libraries die du gefunden hast aber auch mal
analysieren und so zusammenfassen, dass du das Timing von
LED-Stripe-Ansteuerung und FB-Empfang vereinen kannst.
Zudem gibt es noch Alternative zu den WS2812LED-Stripes mit echtem
SPI-Interface, das nicht so ein dämliches Timing erfordert. Leider weiß
ich nicht mehr wie die heißen, hab sie aber mal hier im Forum gesehen,
kann sich da noch wer erinnern?
Nimm nen STM32 und verwende dessen DMA um die ws2812 anzusteuern. Gibts
fertige Libs für die das genau so machen. Dann ist nebenher noch genug
Zeit für das IRMP. Das IRMP gibt es auch für STM32.
Du mußt jetzt sehr tapfer sein: Sowas geht wunderbar mit einem Atmega8
oder halt 328, allerdings muß man das von Hand in Asm programmieren. Nur
werden Dir jetzt die C-Fanboys erzählen, daß Du einen ARM brauchst und
min. 100MHz.
Die Fernbedienung ist gar nicht so kritisch, weil die Signale relativ
langsam kommen. Allerdings muß man das Timing hier von Hand machen und
die Sample-Slots zwischen die 2812 Ausgabe setzen. Das geht dann nicht
mit fertigen Routinen.
Die 100 MHz sind ein wenig übertrieben ;) Was aber bei einem stm32 von
Vorteil sein könnte, ist DMA. Mein Rat: STM32 F103 Board für 5 € aus der
Bucht und dann nimm den Code aus dem WordClock24h Artikel als
Grundlage, da werden auch WS2812 und IRMP genutzt. (Nach einer älteren
Version im Repo gucken, da liefs noch auf dem 103) Der zeitliche Aufwand
dürfte weniger als 15 Minuten betragen bis zu den ersten Ergebnissen,
und wenn du später noch Effekte oder WLAN (ebenfalls in dem Wordclock
Projekt schon mit dabei) dazu haben willst hast du noch fast
"unbegrenzt" Ressourcen übrig.
Beste Grüße
N. J.
N. J. schrieb:> (Nach einer älteren Version im Repo gucken, da liefs noch auf dem 103)
Eher umgekehrt: Die letzte Version nehmen. Den Port von Nucleo mit
STM32F4xx nach STM32F103 habe ich erst in den letzten Versionen
vorgenommen bzw. vervollständigt.
Oh, Pardon.
Ich hatte nur im Kopf, dass es auf dem ST32F103 funktioniert, den aber
im Artikel nicht gefunden, deswegen die falsche Vermutung.
Naja, kann ja morgens mal passieren ;)
Beste Grüße
N.J.
Niels J. schrieb:> Ich hatte nur im Kopf, dass es auf dem ST32F103 funktioniert, den aber> im Artikel nicht gefunden, deswegen die falsche Vermutung.
Der STMF32F103 wird im Artikel nicht erwähnt, weil das Projekt
ursprünglich nicht darauf ausgelegt war. Die Portierung nach STM32F103
war für mich eher aus "sportlichem" Ehrgeiz. Es fehlt auch noch was für
den F103: Die LDR-Messung für die automatische Helligkeitseinstellung.
sadf schrieb:> Die Ausgabe muss aber recht flott> erfolgen.
Ja, die WS2812 sind recht giftig im Timing.
Aber es gibt eine Lösung für die AVRs.
Nimm die UART im SPI-Mode, dann hast Du einen 2 Byte Sendepuffer und Du
kannst Interrupts verwenden.
Das Assembler nötig wäre, ist Quatsch.
Peter D. schrieb:> sadf schrieb:>> Die Ausgabe muss aber recht flott>> erfolgen.>> Ja, die WS2812 sind recht giftig im Timing.> Aber es gibt eine Lösung für die AVRs.> Nimm die UART im SPI-Mode, dann hast Du einen 2 Byte Sendepuffer und Du> kannst Interrupts verwenden.> Das Assembler nötig wäre, ist Quatsch.
Gibt es dazu einen guten Ansatz? In etwa wie mit der Light WS2812?
Peter D. schrieb:> Ja, die WS2812 sind recht giftig im Timing.> Aber es gibt eine Lösung für die AVRs.> Nimm die UART im SPI-Mode, dann hast Du einen 2 Byte Sendepuffer und Du> kannst Interrupts verwenden.> Das Assembler nötig wäre, ist Quatsch.
Ist es nicht. Es mag auch in C gerade noch so gehen, dann bleibt aber
ganz sicher nicht mehr sehr viel Rechenzeit über. Es ist nämlich so,
dass in ein SPI-Byte nur maximal die Info für 2,66... WS2812-Bits passt,
weil nämlich jedes WS2812-Bit zu mindestens 3 SPI-Bits verwurstet werden
muss, wobei die Bitrate 800kHz/3=267kBit/s beträgt. Die Interrupts
erfolgen also mit 267/8=33kHz. Und wenn der ganze C-Overhead bei ISRs
33.000mal pro Sekunde abgearbeitet werden muss, dann kommt alleine
dadurch eine ganze Menge völlig nutzlos verschwendeter Rechenzeit
zusammen, die in Asm einfach mal verfügbar wäre, um noch was Sinnvolles
nebenbei zu tun. Z.B. um das nächste auszugebende Pattern in Echtzeit zu
berechnen, statt es wie ein dümmlicher Nasenpopler in einer überlangen
Reset-Pause des WS2811-Busses zu machen. Das klappt nämlich nur bei
kurzen Bussen (=wenig LEDs) ohne deutlich sichtbare negative
Auswirkungen auf die erzielbare Framerate der LED-Aktualisierungen.
Mal ganz davon abgesehen, dass der SPI-Mode für diese Anwendung sowieso
nicht die beste Lösung ist. Mit der USART fährt man hier deutlich
besser, wenn man sie auch als solche benutzt (und zwar mit 7N1), dann
ist nämlich die Rechnerei zur Abbildung von WS2811-Bits auf USART-Bits
prinzipiell in etwa die gleiche wie beim SPI-Ansatz, aber die
Interruptrate ist hier nur 267/9=29,7kHz und somit wird allein durch
diese intelligente Entscheidung schon knapp 10% weniger Rechenzeit durch
Interrupt-Overheads nutzlos verschwendet. Dazu kommen noch Einsparungen
(auch immerhin mindestens ca. 2%) durch die etwas einfachere
Statusmaschine für die Re-Codierung der Datenbits.
Beides gilt übrigens ganz unabhängig davon, ob man es in C oder in
Assembler umsetzt...
Der Unterschied ist nur: In C können diese 12% schon durchaus darüber
entscheiden, ob die Gesamtlösung überhaupt geht. In Assembler hingegen
hat man selbst bei einem voll belegten Bus mit 1024 LEDs noch erhebliche
Reserven bezüglich der Rechenzeit. Genügend, um etliche Effekte in
Echtzeit zu berechnen, statt deren Daten erst doppelt zeitfressend im
RAM zu verwursten. Das ist inbesondere dann wichtig, wenn man diesen RAM
erst garnicht hat, was bei praktisch jedem AVR8 (mit Ausnahme der
kleinen Handvoll Megas ab M644 aufwärts) nunmal generell der Fall ist...
Nö, gerade die Ansteuerung dieser elenden WS2812 zeigt überdeutlich,
WIE sehr Asm eigentlich im Vorteil ist, denn hier kommt glücklich all
das zusammen, was C nicht so gut kann (und die meisten C-"Programmierer"
(C&P-ler) schon garnicht). Und hier hilft es auch nicht, auf eine
potentere MCU auszuweichen, was sonst ja die Standardlösung dieser
unfähigen C-ler ist.
Allerdings: die größeren Eisen bieten oft viel freier konfigurierbare
serielle Schnittstellen an und darüber hinaus DMA-Fähigkeiten. Und
natürlich mehr RAM. Mit all diesen Goodies kann man dann auch in C das
das erreichen, was in Asm schon auf den bescheidenen AVR8 möglich ist...
Naja, du magst recht haben! Aber du musst auch sehen, was dazu führt.
Wenn man nicht gerade superviel Lust drauf hat ist es oftmals einfach
nicht "wirtschaftlich" ein Programm mühevoll in Assembler zu entwickeln,
anstatt einfach einen potenteren Controller zu nehmen. Es mag ja edler
sein, aber es dauert auch länger, vor allem für den ungeübten.
Moin,
danke für die vielen Antworten.
Assembler ist gerade nicht für mich, habe ich zwar auch schon machen
dürfen, aber da kapiere ich ja nach zwei Wochen meinen Code nicht mehr
:-)
Ich würde gerne bei C bleiben. Die Abfragen zwischen rein fummeln, mag
ich ehr auch nicht.
Ich tendiere gerade zu der Lösung, einfach zwei Prozis zu nehmen. Es ist
ja Hobby und nicht Großserie. Ich benutze diese Atmegasboards nur weil
es die fast geschenkt aus China gibt. In C programmiere ich da ich das
einigermaßen kann (mehr Gründe gibt es nicht). Ich gehöre auf jeden Fall
zu denen die vom c-hater gehatet werden :-)
Gibts für den STM einen billigen Programmer der auch Debuggen kann? Mit
Arduino möchte ich ehr nicht anfangen.
Noch mal vielen Dank für die spannende Diskussion.
Moin,
auf die Gefahr hin, dass ich alten Käse aufwärme:
Hat jemand mit einem MSP430 gute Erfahrungen gemacht?
Momentan nutze ich für den Spass noch ein FPGA, da funktioniert's mit
den Timings prima, aber ist bisschen "Kanone auf Spatz".
Eine Voraussetzung ist, dass noch ein UART für die Kommunikation zu
einem andern Modul verfügbar ist.
Hatte mal noch rumexperimentiert, die Zeilen auf HIGH zu halten, aber
das scheint die Reshaping-Logik der WS2812b zu einem Latch zu zwingen
(d.h. die bisherig reingeclockten Werte übertragen sich auf die PWMs).
Offenbar lassen sich so aber schrittweise die LED-Werte reinclocken,
ohne dass die ganze Kette einen Reset bekommt Hatte allerding noch
irgendwelchen Müll in der LED an Position 1 (zuletzt reingeclockt), die
Sache ist noch nicht so ganz geklärt.
Hier: http://wp.josh.com/2014/05/15/going-nsa-on-pixel-conversations/
hat einer schon weitergehendes erforscht, das erklärt teils einiges.
Gruss,
- Strubi
c-hater schrieb:> In Assembler hingegen> hat man selbst bei einem voll belegten Bus mit 1024 LEDs noch erhebliche> Reserven bezüglich der Rechenzeit. Genügend, um etliche Effekte in> Echtzeit zu berechnen, statt deren Daten erst doppelt zeitfressend im> RAM zu verwursten. Das ist inbesondere dann wichtig, wenn man diesen RAM
Bei 800KHz sind das 30.72ms alleine fur die Ausgabe, wie willst du da
noch irgendetwas in Echtzeit berechnen ?
Und wo ?
512 LEDs / 1.5KB RAM / 6.5 Meter Stripe - das sind die Grenzwerte fur
328p.
Fur mehr haben die 8-bit AVRs ganz einfach nicht genugend RAM, vorallem
da die WS2812 die ganzen Daten in einem Stuck erwarten.
Marc V. schrieb:> 512 LEDs / 1.5KB RAM / 6.5 Meter Stripe - das sind die Grenzwerte fur> 328p.> Fur mehr haben die 8-bit AVRs ganz einfach nicht genugend RAM, vorallem> da die WS2812 die ganzen Daten in einem Stuck erwarten.
Na, wenn's der AVR nicht schafft, dann nimmt man halt einen PIC mit 256
Bytes RAM - ach, eigentlich reicht auch ein 12F1822 mit 128 Bytes RAM,
um ein nettes Lauflicht auf einen 5000er WS2812-Streifen zu zaubern...
;)
http://www.picalic.de/PIC2WS2812/
Marc V. schrieb:> Bei 800KHz sind das 30.72ms alleine fur die Ausgabe, wie willst du da> noch irgendetwas in Echtzeit berechnen ?
Man könnte z.B. 8 Streifen parallel an einen Port hängen, mit 1/8tel
Länge, und die Daten auf Portbreite rausschieben. Das geht dann
natürlich nur in Asm. Und selbst wenn man dabei ein wenig langsamer ist,
gewinnt man erheblich Zeit.
> 512 LEDs / 1.5KB RAM / 6.5 Meter Stripe - das sind die Grenzwerte fur> 328p.> Fur mehr haben die 8-bit AVRs ganz einfach nicht genugend RAM
Es gibt den 644 mit 8k und und den 1284 mit 16k Ram, mit 44 Pins. Wird
ja wohl reichen.
Thomas E. schrieb:> Na, wenn's der AVR nicht schafft, dann nimmt man halt einen PIC mit 256> Bytes RAM - ach, eigentlich reicht auch ein 12F1822 mit 128 Bytes RAM,> um ein nettes Lauflicht auf einen 5000er WS2812-Streifen zu zaubern...> ;)
Ich habe auch ein Knight Rider mit ATTiny2313, aber das ist halt
Spielerei, dient nur zum Vorzeigen. Mit 6 verschiedenen Farben die beim
Zusammenstoss Farben, Richtung und Geschwindigkeit wechseln, braucht
das Ding genau 24 Byt RAM.
Um aber etwas sinnvolles mit WS28xx anzufangen, braucht jeder Pixel
3 Byt RAM - SCHLUSS.
Timm T. schrieb:> Man könnte z.B. 8 Streifen parallel an einen Port hängen, mit 1/8tel> Länge, und die Daten auf Portbreite rausschieben. Das geht dann> natürlich nur in Asm. Und selbst wenn man dabei ein wenig langsamer ist,> gewinnt man erheblich Zeit.
Ja, nur musste man mit dreifacher Geschwindigkeit abtasten und auch die
Daten schon dreifach bereit haben, also 24bit * 3 RAM pro Pixel.
Etwas ahnliches habe ich mit LPD6803 gemacht, aber die haben auch eine
Clockleitung - WS28xx hat nur DATA - das wird so nix.
Marc V. schrieb:> Ja, nur musste man mit dreifacher Geschwindigkeit abtasten und auch die> Daten schon dreifach bereit haben, also 24bit * 3 RAM pro Pixel.
Warum? Du hast einen kurzen Puls 100 oder einen langen Puls 110. Der
erste ist immer high, der letzte immer low.
Und selbst wenn sind 16k durch 3 x 3 immer noch 1800 Werte.
Timm T. schrieb:> Warum? Du hast einen kurzen Puls 100 oder einen langen Puls 110. Der> erste ist immer high, der letzte immer low.
Trotzdem, nach einem Drittel der Bitzeit muss ich prufen, was als
nachstes kommt. Nach 2/3 muss ich zwar nichts prufen aber evtl. den
Zustand andern. Und die Ports dementsprechend setzen. Fur 8 bits geht
das in Echtzeit nicht - zumindest nicht mit 8-bit AVRs.
Also 3 bit senden fur 1 bit Data.
> Und selbst wenn sind 16k durch 3 x 3 immer noch 1800 Werte.
Hier tappe ich im dunkeln ?
Marc V. schrieb:> Trotzdem, nach einem Drittel der Bitzeit muss ich prufen, was als> nachstes kommt. Nach 2/3 muss ich zwar nichts prufen aber evtl. den> Zustand andern. Und die Ports dementsprechend setzen. Fur 8 bits geht> das in Echtzeit nicht - zumindest nicht mit 8-bit AVRs.
Das mag für Arduino zutreffen, da gibts nur PinWrite. In Asm gibts sowas
wie OUT.
Bei 16MHz und 1.25usec pro Bit haben wir 20 Takte Zeit. Wir gönnen uns
pro Drittelbit 0.4375usec, das sind 7 Takte, damit liegen wir gut im
erlaubten Timingbereich
ldi temp1, 0xff
ldi temp2, 0x00
ldi xl, low (daten) ; Start bei 0xZZ00, Vielfaches von 256
ldi xh, high (daten)
ldi temp4, laenge / 256
loop_1:
out Port, temp1 ;1 Takt, Start Bit fur 8 parallele Streifen am Port
nop
nop
nop
nop
ld temp3, X+ ; 2 Takte, mittleres Drittel low oder high
out Port, temp3 ;1 Takt, Mittelstück nach 0.4375usec
nop
nop
nop
nop
nop
nop
out Port, temp2 ;1 Takt, hinteres Drittel low nach 0.875usec
nop
nop
nop
nop
tst xl ; 1 Takt
brne loop_1 ;wiederholen, bis 256 Byte rausgeschoben
;hier IR Fernbedienung pollen.
dec temp4
brne loop_1 ; wiederholen, bis alle Daten rausgeschoben sind
; das gibt nochmal 3 Takte Verlust, aber kurz genug um
kein Reset auszuloesen
laenge = 8 bit x 3 rgb x Anzahl LED pro Strang
Ergibt bei 16kByte Ram 680 LEDs pro Strang und 5400 LED in 8 parallelen
Strängen. Das Ganze reduziert sich naturlich auf 1/3, wenn Du
Uberblenden willst und dafür noch Zielwert und Istwert im Ram ablegen
mußt, Nimmst Du dagegen nur fertige Muster aus dem Flash, ist das
deutlich entspannter.
Ergibt bei 680 LED pro Strang x 3 Byte x 8 bit x 1.3usec pro bit eine
Dauer von 7msec pro Durchlauf. Ergibt ergo 140 Hz. Beschränkt man sich
auf 100 Hz, kann man zwischendurch gut Daten aufbereiten.
Zwischen innerer und äußerer Schleife kann man noch gut den IR Eingang
oder die RS232 pollen, sollte das zu langsam sein, kann man die innere
Schleife abkürzen. Das Pollen darf halt nicht länger als 3usec dauern.
Die Daten müssen natürlich für die Ausgabe aufbereitet werden, aber
dafür ist zwischendurch Zeit.
Da der 1284 genug Pins hat, kannst Du auch 16 Stränge parallel bedienen.
Die Anzahl der LED wird dabei nicht größer, weil Ram beschränkt, aber Du
bist für 16 x 340 LED in 4msec fertig und kannst mit 200 Hz updaten.
Oder halt mit 100 Hz, und nebenbei noch Seti rechnen.
Marc V. schrieb:> Bei 800KHz sind das 30.72ms alleine fur die Ausgabe, wie willst du da> noch irgendetwas in Echtzeit berechnen ?
Ganz einfach dadurch, dass die Hardware (USART) die Ausgabe erledigt.
Genau das ist doch die Grundidee. Genau dadurch hat die MCU die Zeit,
das zu tun, was eine MCU tun sollte: Rechnen, statt blödes stupides
Bitbanging zu betreiben.
> 512 LEDs / 1.5KB RAM / 6.5 Meter Stripe - das sind die Grenzwerte fur> 328p.
Das sagst du, aber frag' mal einen geistig Gesunden! Bei mir steuert ein
Tiny2313A 1024 WS2812B. Und der hat nebenbei noch locker genug Zeit
dafür, Befehle via IR-FB oder I2C entgegen zu nehmen.
> Fur mehr haben die 8-bit AVRs ganz einfach nicht genugend RAM, vorallem> da die WS2812 die ganzen Daten in einem Stuck erwarten.
Du hast definitiv garnix begriffen. Es ging ja genau darum, dass es
möglich ist, die Ausgabe (weitestgehend) unabhängig von der MCU zu
betreiben, wodurch es möglich wird, die MCU statt dessen mit dem zu
beschäftigen, was sie eigentlich tun sollte: rechnen.
Und wenn genug freie Rechenzeit verbleibt, um einen Effekt in ECHTZEIT
zu berechnen, dann braucht man für die allermeisten Effekte schlicht
keinen Framebuffer (also kein RAM), weil all diese Effekte sich
funktional beschreiben lassen auf Grund der Position der aktuellen LED
in der Kette und der aktuellen Framenummer bezüglich des
Startzeitpunktes des Effektes.
Trivialste Logik und trivialste Mathematik. Ja, ganz sicher nix für
Arduino-Fans. Und für die allermeisten C-Programmierer (die ja nicht
wirkliche Programmierer sind, sondern Lib-Nutzer mit minimaler
Eigen-Intelligenz) wohl auch much to much.
Richtige Programmierer hingegen (selbst wenn sie sich aus unerfindlichen
Gründen freiwillig auf die Anwendung von C kastrieren) haben eine echte
Chance, dieses Konzept auch in C umzusetzen, müssen sich dann aber auf
relativ triviale Effekte beschränken, weil halt leider der Compiler viel
zu viele Takte in den ISR-Frames völlig nutzlos versenkt. Mit dem IAR
ist hier schon deutlich mehr möglich als mit dem gcc. Aber gegen eine
optimale Asm-Umsetzung kann auch der IAR nicht annähernd anstinken...
c-hater schrieb:> Du hast definitiv garnix begriffen. Es ging ja genau darum, dass es> möglich ist, die Ausgabe (weitestgehend) unabhängig von der MCU zu> betreiben, wodurch es möglich wird, die MCU statt dessen mit dem zu> beschäftigen, was sie eigentlich tun sollte: rechnen.>> Und wenn genug freie Rechenzeit verbleibt, um einen Effekt in ECHTZEIT> zu berechnen, dann braucht man für die allermeisten Effekte schlicht> keinen Framebuffer (also kein RAM), weil all diese Effekte sich> funktional beschreiben lassen auf Grund der Position der aktuellen LED> in der Kette und der aktuellen Framenummer bezüglich des> Startzeitpunktes des Effektes.
Jajaja, nur reden wir hier von 2 verschiedenen Sachen:
Ich rede von Ansteuern und du redest von Blinken und Spielerei.
Irgendetwas "berechnen" ohne die entsprechenden Daten im RAM zu
haben, ist ganz einfach Blödsinn. Und dumme Farbwechselei ist
dasselbe wie LED blinken lassen, also lass es lieber sein.
> Das sagst du, aber frag' mal einen geistig Gesunden! Bei mir steuert ein> Tiny2313A 1024 WS2812B. Und der hat nebenbei noch locker genug Zeit> dafür, Befehle via IR-FB oder I2C entgegen zu nehmen.
Wetten, dass mein Knight Rider älter als deiner ist, weniger RAM
braucht und viel besser aussieht ?
c-hater schrieb:> Ja, ganz sicher nix für> Arduino-Fans
Hey, kannste mal bitte damit aufhören, mich zu beleidigen?
Wenn du die ganze abwertende Sche*ße aus deinen Texten raus lassen
würdest, dann ist wirklich einiges davon lesenswert.
Aber so ergibt das Gesamtbild: Gequirlte Sche*ße, mit Rosinen!
Bäh..
Marc V. schrieb:> Fur mehr haben die 8-bit AVRs ganz einfach nicht genugend RAM, vorallem> da die WS2812 die ganzen Daten in einem Stuck erwarten.
der atmega 1284p hat 16 KB SRAM gibts auch als mighty Arduino fertig
die IRMP benötigt nur 1-2µs im IRQ das stört die Ausgabe kaum,
jedenfalls habe ich da noch nix bemerkt, aber evtl. ist denn Berechnung
nicht mehr möglich.
Timm T. schrieb:> Da der 1284 genug Pins hat, kannst Du auch 16 Stränge parallel bedienen.> Die Anzahl der LED wird dabei nicht größer, weil Ram beschränkt, aber Du> bist für 16 x 340 LED in 4msec fertig und kannst mit 200 Hz updaten.> Oder halt mit 100 Hz, und nebenbei noch Seti rechnen.
Muss ich dir absolut Recht geben. Habe nicht viel daruber nachgedacht,
vor allem weil die Muster schon am PC aufbereitet sind und AVRs
brauchen diese nur von der SD zu lesen. Irgendwie schien es leichter
und einfacher die AVRs zu vernetzen und nur die Framenummer zu senden.
Werde mir das Ganze nochmal uberlegen, aber ob wir jemals wieder einen
Auftrag mit mehr als 600 LEDs haben werden, ist fraglich.
Joachim B. schrieb:> der atmega 1284p hat 16 KB SRAM gibts auch als mighty Arduino fertig
Es gibt auch relativ billige Mega2560, aber wir haben nun mal jede
Menge Motherboards mit entsprechend rausgefuhrten Steckern fur Arduino
PRO machen lassen und es ist immer leichter nur zu stecken, als das
Gehirn ein bisschen einzuschalten.
P.S.
Arduino-PRO weil es ganz einfach billiger ist als einzelne 328p.
