I’ll see if I can get the FastLED master branch working on the Photon. 
“Improved Arduino library compatibility: Most Arduino libraries can now be copy/pasted into our library manager without modification”
Good luck, I’ve got one somewhere, looking forward to using it with the latest FastLED.
So far, in the past, their library management didn’t work terribly well for libraries with complex layouts (like, say, FastLED) - but curious to hear if it works, it’d be nice if, when I got back to dealing with FastLED regularly, I didn’t have to keep a separate tree just for the particle folks.
Well, no luck so far, giving up for the night. I followed the instructions here: https://docs.particle.io/guide/tools-and-features/libraries/#contributing-libraries
Had to rename the library (otherwise it gave an error saying I didn’t own the library). Had to add #define STM32F10X_MD to the top of my example sketch to get it to compile without trying to use AVR defs.
Here’s the build error output, if anyone’s interested: FastLED build errors with Particle Libary Manager · GitHub
I’ll pick up here tomorrow night.
FYI - It looks like they removed that post from the particle blog. I could still find a cached version via google though.
It looks like it may have been posted a bit early? https://community.particle.io/t/particle-libraries-v2-0/25478/16
+Keith Evans thanks, it looks like they jumped the gun on the blog post. Might explain why I had to jump through so many hoops to get the tools downloaded and running, only to encounter build errors.
I hope that they have a non-beta release soon, and then you have a better experience. I’m new to FastLED, but do have some Particle boards and am looking forward to being able to use the main release. I’m excited to be able to do OTA updates to remote systems without having to do much work 
Yeah, agreed. Have you tried out an ESP8266 yet? I’ve been really impressed with the Arduino support for them lately. I use the Wemos D1 Mini a lot.
Yes - I’ve seen your work and need to take a closer look at some of your projects. Thanks for putting all of the code and writeups online. For fun I built a simple example for an Arduino Leonardo, Particle, and ESP8266 board just to confirm that they all work. I want to be able to work with a friend remotely and the Particle OTA may be very handy to have since he’s not a programmer. I don’t think that I could easily remotely load a new release on an ESP8266 board could I? (e.g. from another city.) But I should order some Wemos boards as well. My only ESP8266 board is a old SparkFun board that’s quite limited.
It’s certainly not as easy to do OTA updates with an ESP8266 as with a Photon, but it’s possible.
Do you have any pointers to someone doing an OTA to an ESP8266 on a different network? That would be interesting to see. (I also thought that Particle’s cellular options are potentially interesting for some people if the costs are low enough. There’s another company http://hologram.io that also has cellular, but I’m not sure how easy it would be to get FastLED up on that.)
Here’s an article on the subject: http://esp8266.github.io/Arduino/versions/2.0.0/doc/ota_updates/ota_updates.html
You could update a device on another network by forwarding the port (exposing it to the internet), or by having it check a remote web server for updates (periodically, when a button is pressed, etc).
Make sure to read the sections on security & safety.
I think that using the remote web server would be most appropriate for me. It’s definitely a good idea to consider security carefully. If it can be made to work, then it would be nice to have a method that would work even if the particle cloud ceases to exist.
One thought on the compile errors you’re getting: Particle may not support nested folders yet, even with Libraries 2.0. An easy way to check might be to take an existing simple library, and move a header file (and the references to it) into a nested folder.
I just got an email from Particle with the Libraries 2.0 announcement, and the blog post is back up.
Has anyone been building FastLED apps on the Particle cloud? Today I’m having some issues. So I just tried creating a brand new empty app and including FastLED (3.1.5) and it won’t build. The error is a conflict for the RwReg typedef.
As far as I can tell the issue is using system firmware 0.6.0 versus 0.5.3. I guess the webide updated this behind my back. It’s not a real fix, but I’ll revert to 0.5.3 for now. If anyone else can confirm this problem that would be great.
There are issues with the 0.6.x firmware and FastLED. I just tried 0.6.1 and we get multiple define on the interrupt functions (sei, etc) and it won’t build. I’m still buiding with 3.0.3 from an old setup, but I’m assuming that stuff hasn’t changed.
I think getting FastLED for Particle is going to take a lot of work and defining a unique device to compile with. Something like -DPHOTON and then enable/disable some parts as needed. I wish I had the time, but for now, 0.5.3 still works with 3.0.3.
I can’t give up the new device management console they have. I love being able to push an update to all my online devices at once (backyard install of tiki lights on a big 12V solar recharge battery). I have close to 10 photons running a neat little candle display with wifi off 99% of the time to limit current draw. It’s a very pleasant and low key kinda thing. Having to push updates to each one and manage that would be difficult no matter what. This is just super easy. It wakes up, checks in, and downloads if needed. Always works.
Hoping someone can get it working. I may give it another spin in a few (4-6) weeks, but right now just don’t have time.
Try 0.6.2, they broke some Arduino library compatibility in 0.6.1 and this specifically addresses that. Also try including Arduino.h as they mention. I haven’t tried yet myself.
OK, I get to FastLED compile errors with some work to command line build and FastLED directly included as a subdir of my project. I patch based on the ekelex 3.0.3 Photon github repository which adds the Photon -D options to enable the HW. @Daniel_Garcia , would it be OK to submit a patch that adds -DSTM32FXX from that github for Photon HW support? It doesn’t get all the way there, but is a start.
There are a ton of scoping issues with CPixelView it seems. I have been investigating, but haven’t figure out what the root cause is. I also noticed that they build system didn’t like ::scale8 even though the namespace is declared. Changing to scale8 or NSFastLED::scale8 fixes it.
If I can find time, I’ll move back to a version prior to CPIxelView and see if that builds.
OK, so basically, pixelset.h seems to do things a bit differently than other files in the system, but I don’t see why. The file pixelset.h doesn’t define FASLED_NAMESPACE_* so it seems to scope funny in my environment. But when you add the namespace to the header, then the global scope resolution functions fail. I hardcode them to NSFastLED:: and the whole thing compiles.
I would bet money this is a compiler version/build issue as I noticed now that I’m using the mac arm-none-eabi-g++ (4.9.3) which is what I remember the Particle folks used to recommend for getting it up and running with Eclipse. I have done it this way for a while, so I assumed I used a cross from them. Seems not.
Can anyone tell me why pixelset.h is done this way? I get that it uses the same function names internally, which causes some issues, but it seems to both depend on the namespace, and not depend on the namespace at the same time.