First, this is what I want to do .... Control an apa102 ledstrip with a teensy 3.2 (arduino compatible).
I first used an uno and ws2813... found out, that is not going to work.
Second tried the ws2813 with a teesny 3.2 because it is a lot faster but still couldn`t capture the ir signals when fastled was updating the leds...
Now third got myself the apa102 which uses data and clock, that should be the best solution (at least that is what I read) but still no joy...
I still cant seem to get capture the ir code when FastLED.show(); is called.
So now I think probally Im doing something wrong with the code... but what?? My coding skills arent that good. Read a lot online about interrupts and fastled turning them off but that was only using the ws2813 because of the timing...
Ive attached the code, it quiet messy but its a work in progress,
Hopefully someone can point me in the right direction
// ===========================================================================
// Sound recieving ==
// ===========================================================================
if (effect==2){
// Time variables to find the peak-to-peak amplitude
unsigned long startTime= millis(); // Start of sample window
unsigned int PTPAmp = 0;
// Signal variables to find the peak-to-peak amplitude
unsigned int maxAmp = 0;
unsigned int minAmp = 1023;
// Find the max and min of the mic output within the 50 ms timeframe
while(millis() - startTime < sampleTime)
{
soundValue = analogRead(soundPin);
if( soundValue < 1023) //prevent erroneous readings
{
if (soundValue > maxAmp)
{
maxAmp = soundValue; //save only the max reading
}
else if (soundValue < minAmp)
{
minAmp = soundValue; //save only the min reading
}
}
}
PTPAmp = maxAmp - minAmp; // (max amp) - (min amp) = peak-to-peak amplitude
int si = map(PTPAmp, 23, 500, 1, 30); // control for the ledstrips
vuLed = si;
//Serial.println(si);
}
// ===========================================================================
// Led control ==
// ===========================================================================
static unsigned long lastUpdateTime;
// effect 1
if (effect==1){
// void sinelon()
// a colored dot sweeping back and forth, with fading trails
fadeToBlackBy( leds, NUM_LEDS, 20);
// insert a delay to keep the framerate modest
FastLED.delay(10);
int pos = beatsin16( 13, 0, NUM_LEDS-1 );
leds[pos] += CRGB :: Red;
// Serial.println(pos);
FastLED.show();
}
/*
if (di==1 && currentTime - lastUpdateTime> 25){ // speed blinking IR active led
lastUpdateTime = currentTime;
leds[dot] = CRGB ::Red;
if (i==0){
leds[dot -1] = CRGB ::Red;
// leds[dot -2] = CRGB ::Red;
}
if (i==1){
leds[dot + 1] = CRGB ::Red;
// leds[dot + 2] = CRGB ::Red;
}
// FastLED.show();
di = 2;
}
if (di==2 && currentTime - lastUpdateTime > 25){
lastUpdateTime = currentTime;
// leds[dot] = CRGB ::Black;
if (i==0){
leds[dot - 2].fadeLightBy(200);
leds[dot -3] = CRGB ::Black; }
if (i==1){
leds[dot + 3] = CRGB ::Black;
leds[dot + 2].fadeLightBy(200);
}
di = 1;
if (i==0){
dot++;
}
else{
dot--;
}
}
if (dot < -2){
i = 0;
}
if (dot > 29){
i = 1;
}
}
// leds.fadeToBlackBy( 15 ); test
/*
// Turn the first led red for 1 second
for(int dot = 0; dot < NUM_LEDS; dot++) {
leds[dot] = CRGB::Blue;
// FastLED.show();
// clear this led for the next time around the loop
leds[dot] = CRGB::Black;
delay(500);
}
*/
// Serial.println(pos); // for debugging
}
I still cant seem to get capture the ir code when FastLED.show(); is called.
That would be the wrong time to try to capture the IR code. The show() method is called after all the pixels have been set, to commit the data to the strip.
You want to, on every pass through loop(), read the IR data, and, if you got something, set up the pixels and call show().
If you are using a Teensy, try using Makuna-NeoPixelBus DMA-mode (default for any ESP..) or even the FastLED DMA-mode (someone has an idea and someone else copies it and adds it to their stuff, but that is how life is...) this does not turn off the interrupts and your issue should be resolved.
Well, on the FastLed github site it states when using the apa 102 the interrupts dont need to disabled ... As I dont know how to disable them I persume that when the fastled librarie is is updating the leds
it still turns off the interrupts even though Im using the apa 102 ?? Im probaly doing something wrong ..... but what ??
Ah sorry, No your issue must be somewhere else i was not aware that an APA102 is a 4 wire system, the extra wire is there to transmit the 'clock' which means that timing is no longer critical (if the signal is delayed, so is the clock signal) Since you are selecting that type when creating the object, the library will just 'not' turn interrupts 'off' (it should not turn them off anyway) so you issue will be elsewhere. Mind you !! since you are using a teensy, you should be able to use the WS2813's using Makuna-Neopixelbus DMA mode (this does limit your choice of data pin)I am not sure about the FastLED library DMA's mode but i am no fan of FastLED at all.. either way get rid ofFastLED.delay(10);there must be something more important that your processor can do than firing FastLED.show() all the time (and screwing up accuracy of frame-rate timing in the process) I looked through your sketch, but even though all of the stuff in there is sorted by category, i completely lost overview, (until i realized the closing brace for loop() was really just all the way down there.)
Deva_Rishi:
(until i realized the closing brace for loop() was really just all the way down there.)
Sorry about that, the code is a bit messy still. First get the ir capture thing working then clean it up a bit.
Deva_Rishi:
either way get rid of FastLED.delay(10);
removing this changes the pattern ... and not for the better :o
But I still have no idea why I cant recieve my IR codes correctly when the ledstrips are constantly updated. Im using a teensy3.2 and 4 wire led strip apa102, that should work (as I read it on multiple sites)
so what am I doing wrong ......
I’d start from scratch. There’s nothing about APA102s, Teensy 3.2, or FastLED that should be causing problems. The current code is rather convoluted and poorly organized, scrap it.
Start simple and build up, constantly testing along the way. Begin with the LED strip(s) and implement the effects you want using only non-blocking code -- no delay() or FastLED.delay(), do all timing with millis(). Only call FastLED.show() when one or more LEDs need to change. In all likelihood, that will NOT be every time through your loop() function.
After LEDs are working properly, add minimal IR code. Call irrecv.decode() every time through loop, but don’t try to use the ‘results’ variable unless a new command has been received. Don’t mess with it on every pass through loop() if there’s nothing new to do.
Roonie:
removing this changes the pattern ... and not for the better :o
replace it by delay(10); then at least that leaves the processor available for other stuff.
Take Gfalvo's advice, clean up your code and use only non-blocking methods, if you still have the WS2813's try those ! with the other library.
The resume() call simply clears the last recorded data. It does NOT cause new data to be read. The decode() method does that.
This is a matter of interpretation, decode() parses the data received, resume() resumes reception interrupt and stores anything received in the buffer (after it has cleared it ?)
In all likelihood, that will NOT be every time through your loop() function.
it is at the moment though, and while the actual time to show() the LED's is actually less than 1ms, FastLED.delay() just calls show() repeatedly until 10ms have passed.
There's nothing about APA102s, Teensy 3.2, or FastLED that should be causing problems
Have you actually checked in the FastLED code that the interrupts aren't just getting turned off regardless of the chip being used ? (even though there is no need)
Deva_Rishi:
Have you actually checked in the FastLED code that the interrupts aren't just getting turned off regardless of the chip being used ? (even though there is no need)
With AP102 on a T3.2, FastLED only disables interrupts during two writes of the pixel data to two SPI hardware registers -- I assume so that the operation of loading the data and triggering the SPI transfer is atomic. So, interrupts are enabled while the data is being serially clocked out of the SPI hardware. Any external interrupts that occur during those two register transfers would be serviced after they complete (not too long a wait on a 96 MHz processor).
correct me if I`m wrong, but that would that I have to connect the data to pin 11 and clock to pin 13 on the teensy ??
I tried that but still IR recieving works until I press effect 1 on the remote and the effect starts running. Then no
IR signal is been picked up correctly...
I have tried the adafruit dorstar libary and it looks like it works fine.... how ever I can`t seem to find any animation / patern code or sketches for it ... only the test one included in the libary...
gfvalvo:
With AP102 on a T3.2, FastLED only disables interrupts during two writes of the pixel data to two SPI hardware registers -- I assume so that the operation of loading the data and triggering the SPI transfer is atomic. So, interrupts are enabled while the data is being serially clocked out of the SPI hardware. Any external interrupts that occur during those two register transfers would be serviced after they complete (not too long a wait on a 96 MHz processor).
Cool, great so that shouldn't be to much of an issue (unless you call .show() repeatedly for about 10ms)
so change FastLED.delay(10); for just delay(10); or the waiting loop
uint32_t moment=millis();
while (millis()-moment<10) yield();
so at least it really is just that moment during the 2 writes. (and not that moment 30 or 40 times)
Roonie:
correct me if I`m wrong, but that would that I have to connect the data to pin 11 and clock to pin 13 on the teensy ??
That's the simplest way, but there are ways to switch Hardware SPI to certain other T3.2 pins.
I tried that but still IR recieving works until I press effect 1 on the remote and the effect starts running. Then no
IR signal is been picked up correctly...
As I said in a previous reply, the problem is in your code. That's why I told you to scrap it and produce a better-organized program from the ground up using all non-blocking techniques.
Deva_Rishi:
Cool, great so that shouldn't be to much of an issue (unless you call .show() repeatedly for about 10ms)
so change
FastLED.delay(10);
for just
delay(10);
or the waiting loop so at least it really is just that moment during the 2 writes. (and not that moment 30 or 40 times)
That nearly did the trick ..... I saw that the IR signal was working a little while then it stopt...
But when I disconnected the usb cable it started to recieve correctly .....
So it looks like Im back on track I will still take you guys advice and clean the code up, but at least were making progress