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 WS2812 LED-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.
:
Bearbeitet durch Moderator
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: > Das Assembler nötig wäre, ist Quatsch. Bei gleichzeitiger Abfrage einer Fernbedienung?
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.
sadf schrieb: > Gibts für den STM einen billigen Programmer der auch Debuggen kann? http://www.aliexpress.com/item/FREE-SHIPPING-ST-Link-V2-stlink-mini-STM8STM32-STLINK-simulator-download-programming-With-Cover/1950727356.html oder http://www.ebay.de/itm/141803544334 wären günstige eigentständige Programmer und Debugging-Probes. Der ST-Link v2 ist aber auch auf allen Discovery-Boards von ST gleich mit drauf.
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.
Marc V. schrieb: > Es gibt auch relativ billige Mega2560, die haben weniger SRAM als der 1284p und sind als Arduino fetter von der Platine
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.