Search results

Spun up FastLED 3.3.1 w/the fix for this in place.

Yeah - I discovered this the other night - someone made changes to the arm m0 clockless cose that’s breaking this - until I get a fix checked in (there’s one on a branch for other work, need to merge it over) put: #define FASTLED_ALLOW_INTERRUPTS 0 Before the include FastLED.h (their change...

FastLED 3.3 w/Teensy 4.0 support now up And just pushed/released FastLED 3.3 with Teensy 4.0 support (all 3 and 4-wire chipsets that FastLED supports are supported, uses hardware SPI for the 4-wire chips, non-DMA based parallel output available for the non-SPI based chipsets, will add in...

FastLED + Teensy 4.0 Sorry for the delays in getting this up and running - I've put up a branch here - https://github.com/FastLED/FastLED/tree/teensy4 - with Teensy 4.0 support for FastLED (after I pushed that branch I saw a comment someone made on the FastLED reddit pointing at a preliminary...

But did you set the type in addLeds to OCTOWS2811?

You can always used fastled'a octows2811 driver to get the best of both worlds.

Sadly, it has less to do with the APA102 and more to do with the wiring/mounting I think. I have a 768 led apa102 board that I've been able to drive glitch free at 24mhz. And I have some apa102 strips that I can't drive more than 100 leds above 6mhz :/

I haven't yet done the Teensy 3.5/3.6 porting for FastLED (other than a bunch of datasheet digging) - a somewhat surprise job change and dealing with an injury has thrown me off on timing (combined with my electronics setup/testing area not being usable at the moment) . I'll do a staged rollout...

Use the pin number not the port bit and also no ;'s on the #define lines.

Unlike the SK6812 whose timing is pretty close to the WS2812 (down to a 1.25µs bit timing) the SK6822 appears to have a slower timing rate (a ~600hz data rate) that is 1.7µs per bit data rate. If the SK6812 timing doesn't work for it, grab the latest master of FastLED, where I've just added in...

It's possible there's something off with the 16-way code, it's been a while since i've tested it (most of my setups are happy with 8-way). In the meantime, you can do something like: [CODE] #define NUM_STRIPS 16 ... LEDS.addLeds<WS2811_PORTD,NUM_STRIPS/2>(leds, NUM_LEDS_PER_STRIP)...

FastLED has a controller for OctoWS2811 - it's actually faster than just using OctoWS2811 on it's own - there's an example of using it here - https://github.com/FastLED/FastLED/tree/master/examples/Multiple/OctoWS2811Demo -- you don't even need the octows2811 breakout board, especially if you're...

WS2812 led timing requires interrupts be blocked for the 30µs of writing out 24 bits of data - which is why I had the recommendation to switch leds to something like the APA102/LPD8806 which don't have timing requirements. Another possibility would be to use FastLED's OctoWS2811 controller...

FastLED's disabling of the interrupts for 30µs at a time is still going to be occurring, however (again, assuming that you're using the 3.1 release or master@HEAD - if not, then they will be disabled for about 300µs at a time. Increasing the priority doesn't override __disable_irq().

What version of FastLED are you using? More recent versions of the library have the ability to allow interrupts to be handled on the teensy 3.x - though interrupts will be fully disabled for 30µs at a time. I don't know whether or not this is going to end up being too long for the server...

Use master, not the teensy-lc branch, that branch is way out of date.

Excellent! I have four on order and the datasheet open in another window. I think this'll be the first post fastled3.1 update! EDIT: never mind on the library update, read the mcu as being a different model at first - easiest new platform port ever!

Get the most recent version of the FastLED3.1 branch - there were some problems with how I was computing SPI multipliers at higher clock speeds.

I got the 20khz timings from here - https://cpldcpu.wordpress.com/2014/08/27/apa102/

APA102's have a > 20Mhz data rate (I've heard of people driving them as high as 32Mhz) and a 20kHz PWM refresh rate, how this is too slow for POV?

You are still limited to a frame rate of 425 - even worse, with WS2812's if you try to update them at a higher rate than 425Hz they will glitch out like no tomorrow, and so you have _have_ to cap off your refresh rate at that. Seriously, don't use WS281x for POV.

Use the apa102 with the teensy 3.x.

Just re-ran with FastLED3.1 latest checkout, arduino 1.6.5 and Teensyduino 1.24 -- works for both 24 and 48mhz clock rates, optimized and non-optimized.

For chipsets like the WS2812 where your timing is pretty tightly set by the chipset, when it comes to raw writing out of the led data, all the libraries involved are going to be close. Here's where you can get performance differences: * pushing led data in the background, instead of eating up...

You could always report bugs on the github tracker for the library - http://fastled.io/issues - make sure you've grabbed the latest pull of the FastLED3.1 branch - I did a bunch of major work for the teensy-lc (and other cortex m0 arm chipsets) a couple weeks ago, it'll go over to master in the...

Also be sure to grab the FastLED3.1 branch - I need to move it over to master soon but it has a bunch of fixes for both teensy 3/3.x as well as teensy-LC support.

What kind of math are you doing? 36 bits at 48Mhz gives you about 23 minutes before rolling over (2^36 is about 68 billion, divide that by the 48Mhz and you get 1431 seconds).

The problem is that the teensy, being an M0, lacks the instruction that multiplies two 32 bit values into a 64 bit value, which is what you need for that magic number trick to work. You compiled the code for the M4, which is why it used the magic numbers.

What about this to get microseconds: 96Mhz: return (uint32_t)(((uint64_t)0xAAAAAAABULL * (systick>>5)) >> 33); 48Mhz: return (uint32_t)(((uint64_t)0xAAAAAAABULL * (systick>>4)) >> 33); 24Mhz: return (uint32_t)(((uint64_t)0xAAAAAAABULL * (systick>>3)) >> 33); (Found here...

Huh, ok. I'll have to do more testing when I get back to the hotel tonight. Because it seemed to be taking ~120 clocks to hit overflow when I set FTM2_MOD to 60. I also was having some weird cases where it seemed like sometimes I would suddenly get things that looked like closer to 90 clocks...

Also there's a teensy-lc specific branch (based off of FastLED3.1) here - https://github.com/FastLED/FastLED/tree/teensy-lc

I've currently got a local branch with most of FastLED building and running on there. Working on the support for WS2812/TM1809/LPD1886/etc... now. The lack of a clock cycle accurate counter is proving to be a pain/problem however. I can't seem to get the FTM clocks to run at higher than 24Mhz...

http://fastled.io/wiki has a bunch of docs - there's also a dedicated g+ community for the library - http://fastled.io/+

pictographer - the other person I work on the FastLED library with has been working on basically that type of system (basic rough numbers for per-led consumption) where you give it the max amperage you want to use, and it will automatically scale the brightness down behind the scenes for you if...

(filling in here from the g+ discussion in case people are following here) The flickering is caused by having dithering enabled at low frame rates (you're running ~30fps) The bug in FastLED.delay is likely something to do with how i'm attempting to compensate timing from having disabled...

the WS2812B has the same issue - 400hz refresh rate. Most of the folks I know doing POV type stuff are using the LPD8806 (which has something like a 2.4khz refresh rate, give or take, not to mention a 20Mhz data rate).

The biggest problem that you are going to have with the WS2812B's is refresh rate. You can't go above 400fps with them otherwise you start messing with their own internal refresh rate and things start getting wonky. Most of the folks I know who are building POV things are using chips like the...

That's assuming you are spending 100% of your time pushing bits (I haven't gotten to doing a DmA SPI implementation on the teensy yet). The lpd8806 is really the best option out there for a long chain of LEDs where splitting up the lines to use something like octows2811 isn't doable for some...

I have documented the information I have (and others have tracked down) about clock speeds, pwm rates, and dark power draws on the FastLED documentation wiki here - https://github.com/FastLED/FastLED/wiki/Chipset-reference

Roughly, you want something like the below - then you can just access led pixels by x/y locations without eating up a bunch of ram for the array. #define NUM_LEDS_PER_STRIP 50 #define ZIGZAG 1 int xy(int x, int y) { if(ZIGZAG && y & 0x01) { return (y * NUM_LEDS_PER_STRIP) +...

The WS2801 and the WS2811 are going to be running at different data rates, 1Mhz vs. 800khz. If you want to connect 3000 leds in series and get decent framerates out of it, used the LPD8806 which the teensy 3 can drive at somewhere around 20Mhz.

Did you also change the type of the ptr variable as well? You're going to run into problems if you try to stuff a 32-bit pointer (those high 16 bits are sometimes important!) into a 16 bit value, depending on what portion of the address space malloc is playing in.

Coming down to MakerFaire (Bay Area) 2014?

The problem is that while on the teensy++2 a pointer is only 16 bits (so you can use a uint16_t to hold a pointer), on the teensy3 a pointer is 32 bits, so a uint16_t can't be used to hold a pointer anymore. Change the type of your variable ptr to be a proper pointer, rather than a uint16_t and...

(And chased down and fixed, thanks again for the response/link!)

So, outside of the timing problems at 24/48Mhz (which i'm looking into) - when I run the code that you've pasted above, it runs through all the output in loop - no hanging anywhere, no matter whether or not i have any calls to delay, or delay vs. FastLED.delay. At 48Mhz and 96Mhz, it runs and...

It is, life is pretty happy at 96mhz, I just wanted to sanity check before I go chasing down timing demons in the 24 and 48 MHz clocked worlds :)

Your setup loop should only have setup code in it - the rest of that code should be in loop, I wouldn't be shocked if that was interfering with things, though I'd have to dig into why. FastLED.delay simply calls show and delay alternately behind the scenes to drive the dithering algorithm...

The teensy 3.1 page lists the core clock speed as 72Mhz, overclockable to 96Mhz, but the dropdown selections available to me in teensyduino are 24Mhz, 48Mhz, and 96Mhz (overclock), and F_CPU is set to 24000000, 48000000, and 96000000 respectively. Do any of these map to 72Mhz? (Asking because...

Does it hang or do the LEDs stop processing updates? I've found that if voltage drifts above 5v (e.g. 5.2 or above), that WS2812 strips start having problems w/the teensy's 3.3v signals and stop processing updates. While I'm poking at moving to level shifters for projects going forward where I...