Is there a simple way to mod the library to loop the same pixels

Fredrik_Andersson · October 4, 2015, 9:26am

Is there a simple way to mod the library to loop the same pixels x amount of times?
The reason for this is to test more pixels without the need of more memory.

You see, I have this problem with led’s lagging more and more the further out you get.
My setup is an RFduino, 3 meters of 144-leds-per-meter strip and a 24 amp 5V. I’ve also added some extra power wires to make up for the strips internal voltage so I don’t think it’s caused by power problems. I rather think it’s a timing issue.

It looks like the lag starts somewhere around led #150. I have also tried running with a regular Arduino. The memory limit can only get me so far as 200 led’s but it looks like there’s no lag. So, it would be neat to be able to redraw the same pixels multiple times to get past the memory limit of my Arduino to finally see if the lag is a hardware of software issue.

The video shows the issue quite sell, but interestingly some if the patterns are animated smoothly?

Fredrik_Andersson · October 4, 2015, 11:12am

Ok, after testing this example that doesn’t have a memory limit:

github.com

bigjosh/SimpleNeoPixelDemo/blob/master/SimpleNeopixelDemo/SimpleNeopixelDemo.ino


/*
 This is an example of how simple driving a Neopixel can be
 This code is optimized for understandability and changability rather than raw speed
 More info at http://wp.josh.com/2014/05/11/ws2812-neopixels-made-easy/
*/

// Change this to be at least as long as your pixel string (too long will work fine, just be a little slower)

#define PIXELS 96*11  // Number of pixels in the string

// These values depend on which pin your string is connected to and what board you are using 
// More info on how to find these at http://www.arduino.cc/en/Reference/PortManipulation

// These values are for the pin that connects to the Data Input pin on the LED strip. They correspond to...

// Arduino Yun:     Digital Pin 8
// DueMilinove/UNO: Digital Pin 12
// Arduino MeagL    PWM Pin 4

This file has been truncated. show original

The pixels are animated smooth as can be! So what now? There’s a timing issue in the RFduino? Is this something that can be calibrated or is it a problem inherent to the way the ARM Cortex M0 it’s based on works?

Fredrik_Andersson · October 4, 2015, 12:39pm

I found yet another code directly controlling the strip but from an RFduino. Perfect! So I modified the above code with the bit writing code here: http://thomasolson.com/PROJECTS/MIDI/MIDI_WS2812
The timing used in this code does wonders! It animates beautifully with no stuttering at all towards the end of the strip.

So there is clearly some issue in the timing in FastLED for RFduino. I really want to use the awesome features of FastLED so I might look into what needs to be modified. It’s gonna be a daunting task to try to understand the lib, if anyone have better understanding and can do this more quickly than a novice, give me a heads up

Fredrik_Andersson · October 4, 2015, 1:16pm

Nevermind, the source of my problems was that interrupts was enabled. Setting FASTLED_ALLOW_INTERRUPTS to 0 did the trick!

Daniel_Garcia · October 6, 2015, 2:57am

Yeah - I should change the default to disallow interrupts on the rfduino. The problem is that some of Nordic’s Bluetooth soft devices will crash the device if interrupts are disabled for too long - but I don’t know specifics of what rfduino is using (the rfduino port is based on some work that I did on a project that was based on the nrf51822 chip that the rfduino uses as well)

Fredrik_Andersson · October 7, 2015, 9:24am

So are the RFDuino hardware also causing interrupts by default? While I did have interrupts enabled, I can’t think of anything that would cause interrupts, if not the bluetooth module.

Daniel_Garcia · October 7, 2015, 9:38am

The systick timer, fires once a millisecond, 1000 times a second. If the timing of it firing happens to mean prolonging the gap between writing individual led data beyond the threshold (5-10us I believe) then the library stops writing the frame out. Also if you’ve done anything to turn the Bluetooth hardware on, then yes it will also start throwing interrupts.

Fredrik_Andersson · October 7, 2015, 10:01am

Thats’s strange though. Even 5us is a pretty long time in the context. Is the RFDuino lib doing something with the interrupts under the hood?

Daniel_Garcia · October 7, 2015, 10:32am

5us is only 80 clock cycles - dispatching an interrupt eats some number of those and the enter/exit of an interrupt function can quickly turn into another 20-30 cycles - the Arduino library interrupt for the systick timer is pretty expensive. And we haven’t even touched on the interrupt handlers for Nordic’s Bluetooth soft devices, which I have clocked at as high as 1ms. (This is why I should just disable allowing interrupts by default for the rfduino - it’s only a 16mhz clock)