Ich habe einen LED-Streifen mit WS2801 Controllern und 5V, Gnd, Data- und Clocklines, an welche ich mit FastLED und der Methode FastLED.show(); die Anweisungen übertrage.
Dazu sollen gleichzeitig die Werte der Fernbedienung eingelesen werden, um später ausgewertet werden zu können. Allerdings scheint FastLED.show(); die Interrupts zu unterbrechen, weshalb keine IR-Werte eingelesen werden können. Ohne FastLED.show(); funktioniert das einwandfrei.
Gibt es eine Möglichkeit, das Problem zu beheben ohne extra einen zweiten Mikrokontroller dazuschließen zu müssen?
Beispielcode
while(true){
for(int Led = 21; Led != -1; Led--) {
drillStrip[Led] = CRGB::Blue;
drillStrip[Led - 1] = CRGB::DarkBlue;
FastLED.show();
delay(30);
}
if (irrecv.decode(&results)) {
irrecv.resume();
if ( results.value == 16734885)
return;
}
}
Das Problem wird hier wohl eher die Programmierung sein. Mir ist jetzt nicht bewusst, ob die FastLed Lib Interrupts im SPI Modus (WS2801) sperrt. Es würde aber schon Sinn machen, die Programmierung der While und For schleife anzupassen. So kannst du nur alle ~600ms auf iR zugreifen
ich hab' dasselbe vor jahren probiert und hatte die selben probleme. weil ich es dann anders gelöst habe (keine fernbedienung, sondern webseite), hab' ich mich nicht weiter damit beschäftigt.
später hab' ich dann gelesen, daß es lösungen dafür gibt. soweit ich mich erinnere, war es ein post von helmuth (ist hier derjenige, der sich am meisten mit den LED-streifen beschäftigt). vielleicht meldet er sich noch, wenn nicht, mach ihn doch morgen mit einer PN aufmerksam.
Probleme mit Interrupts gibt es nur in der Kombination AVR + clockless Ledcontroller (Neopixels, WS2812, TM1809).
Mit den extern getakteten WS2801 funktioniert IR + FastLED problemlos. Interrups werden auf AVRs nur bei o.g. Chips gesperrt während LED Daten geschrieben werden.
Das Problem ist in diesem Fall also der Code, nicht FastLED. Willkommen im Forum und noch ein Hinweis: Bitte immer den vollständigen Sketch posten, das Problem liegt i.d.R. dort, wo Du es nicht vermutest.
oder einen kleinen arduino dranschrauben, der dann einzelne bytes rüberschickt. das problem ist ja offensichtlich nicht, daß er nicht bytes empfangen kann, sondern nur nicht "aufpasst", wenn zu irgeneiner zeit grad IR-signale kommen.
für serial hab' ich das byte puffer, für IR nicht.
