platforms/avr/led_sysdefs_avr.h: No such file or directory

[stevesparks]

Veryfing code using this library in Particle Build fails with this error:

FastLED/led_sysdefs.h:19:43: fatal error: platforms/avr/led_sysdefs_avr.h: No such file or directory
 #include "platforms/avr/led_sysdefs_avr.h"
                                           ^

My code is cribbed from the "Fire2012" example.

[simetin]

Thanks it's working right now ! :)

[lessavyfav]

As always, thanks to Dan and all for the huge efforts they make. Please post a paypal donate address! I am so happy the you've ported to photon but am struggling with lots of noise and chatter/flickering on larger chains of APA102c. 1m of 30 per works well, one I get to 2 m things fall apart. I hope to get an 11/66 matrix running for these kids I'm volunteering with so the situation has me sweating.

Using the dotstar library works a lot better... Spidiey senses tingle around data rate, maybe the speed is less forgiving over greater lengths? But get an error with this declaration while plugged to default(?) A5 data and A3 clock

FastLED.addLeds<APA102, RGB, DATA_RATE_MHZ(12)>(leds, NUM_LEDS);

It doesn't like I looked a bit into dividing SPI rate in Photon reference materials but am out of my league with clock level stuff. Do I need to run SPI begin? Set its frequency? . Maybe someone have advise on pin setting/best timing with photon and APA102s.

I'm converting to 5v levels for data with a 74hct245. I'm going to try distorting powers more frequently first but ask about the clock assuming I'll be back soon ;-)

Thanks for reading This prattling comment. Sorry.

[focalintent]

https://github.com/FastLED/FastLED/wiki/SPI-Hardware-or-Bit-banging documents how to adjust the SPI data rate. The dotstar library defaults to an 18Mhz data rate, slower if you are bit-bnaging (e.g. using non-hardware SPI pins) - FastLED defaults to 24Mhz, and I've seen that be a problem with longer strips. FastLED is pretty aggressive in the bit-banging code, it's possible it is running too quickly (I can toggle clock lines _really fast- very easily :) - changing the data rate down to something like 10-12Mhz might help with what you're seeing.

(Also - in the future - more conversational help type stuff should go to the g+ community - http://fastled.io/+ - or into new issues - having an issue veer off into a half dozen different things makes them far less useful in the long run :)

[focalintent]

Ah! Now I remember - I haven't actually implemented hardware SPI support for the photon/spark core (their web ui/dev environment got to be too irritating for me to keep working on it) - so everything is going to use bit-banging - which, if the data rate is set to high may result in flipping ports too quickly. (As it is, I think there's a performance optimization in there that I have to take out because it causes too many problems - but in the meantime, changing the data rate to something lower should help).

[blownupp]

Just to add to what lessavyfav was saying I am having the same issue - 1m 144led apa102 string glitching out quite a bit. I'll have to give the data rate a shot though. How difficult would it be for one to add support for hardware SPI? I'm not expert programmer but if it isn't anything too difficult I wouldn't mind poking around...

On Tue, Dec 15, 2015 at 12:54 AM, Daniel Garcia notifications@github.com wrote:

Ah! Now I remember - I haven't actually implemented hardware SPI support for the photon/spark core (their web ui/dev environment got to be too irritating for me to keep working on it) - so everything is going to use bit-banging - which, if the data rate is set to high may result in flipping ports too quickly. (As it is, I think there's a performance optimization in there that I have to take out because it causes too many problems - but in the meantime, changing the data rate to something lower should help).

— Reply to this email directly or view it on GitHub https://github.com/focalintent/FastLED-Sparkcore/issues/2#issuecomment-164651316 .

[Hotaman]

@focalintent 1+ on the pita web IDE (I maintain the Particle (Spark) OneWire lib) and Thanks for your work on this one. I have been playing with 1m x 60 DotStars using my own code and hardware SPI on the Photon and Electron. I'm driving the interface directly (3.3v I'd only switch to 5v if I had long wires between the Photon and the strip, bout 12" now) to the DotStars and running the data at 50MHz without issue. The OneWire lib is all bit banged and when doing high speed banging on bits you need to take some special care depending on the specific platform if using fast pin functions (I haven't looked yet but I will be). I have a 4mx60 strip on the way that I will test with this coming weekend. I'll post the results using hardware SPI and your bit banging if I can get the lib to compile and run.

Since I'm only planning to use the APA102 LEDs, I vote for hardware SPI support, forget the bit banging!

This repo was last updated 2 months ago, I pulled it a couple days ago for local dev and had the AVR error. In the webIDE, switching to 3.1.4 passes that error which makes me wonder 'where is the latest code for Particle?'

I'm sure I'll figure it out, once I get a test running I'll test on the Electron as well for you.

[kri5]

:+1:

[kri5]

@Hotaman You might want to open an new issue and ping @focalintent

[Hotaman]

@kri5 I have it compiling now in dev with the Fire2012 demo on a Photon. I just needed to track down all the required defines and values. The json indicates it is the correct code and it does work just fine when properly configured.

Probably the biggest problem is that none of the examples currently work out of the box so there is no base reference as to how to get it to work. You have to want it!

[RickDB]

For a working sample of Fire2012 with programmable Color Palette with FastLED and Photon you could go with this one:

https://gist.github.com/RickDB/aec4cdc3a84310f81f05

[wmoecke]

Make sure to use this at the top as some of the samples out there are invalid.

#include "FastLED/FastLED.h"
FASTLED_USING_NAMESPACE;

#if FASTLED_VERSION < 3001000
#error "Requires FastLED 3.1 or later; check github for latest code."
#endif

Hooray! Adding FASTLED_USING_NAMESPACE; is exactly what I needed to do in order to fix my FastLED code written on a local build environment (using the CLI tools to compile on the cloud). It fixed the fatal error: platforms/avr/led_sysdefs_avr.h: No such file or directory error I was getting with the ColorPalette.ino example (this particular one didn't have that statement) - was driving me crazy!

Thank you, thank you, thank you @RickDB for the fix, @focalintent for this lib. I'm stoked. I modified the NoisePlusPalette.ino code to spread the visuals across a 8x8x8 LED cube made out of 512 WS2812B's.

Happy.