FastLED not compiling to Photon

@kasper, the errors look to be due to the default Arduino compatibility used in the new pre-processor. Try putting this line at the beginning of your code:

#include "Particle.h"

I think this has to be done throughout the library? Because just adding these two lines as first lines of my application.cpp doesn’t work.

What is the difference between application.h and Particle.h?

@kasper, application.h is now deprecated and replaced with Particle.h

@Peekay123, I’m still getting that same RwReg error even with

#include "Particle.h"

in my code, when I try to compile for 0.6.1 (using particle web IDE). It looks like a regular old namespace conflict, but I’m at a loss for why it works in 0.6.0 but not 0.6.1 – can you think of any difference in 0.6.1 that might be causing this?

@enjrolas, v0.6.1 is the version where all the Arduino stuff kicks in.


To provide maximum compatibility for Arduino libraries, and still support hundreds of libraries that were ported from Arduino to Particle, we include Arduino defines by default now.

In the past, users would get Arduino defines without the need to add #include "Arduino.h" to their code. And there was no Arduino.h, so that had to be commented out in libraries for them to compile.


Now Arduino.h just includes Particle.h (which in turn includes the legacy application.h). Also legacy libraries would include application.h directly in many cases. If application.h is included, PARTICLE_ARDUINO_COMPATIBILITY will be defined. And by default it will be included and set to 1. If that is the case, all of the defines in spark_wiring_arduino.h will be included in your code. So RwReg will be defined.

There is no way to get ahead of the application.h include if it is included in a library and that is added to your app in the Web IDE. It appears to compile the library first.

If we could get the app to compile first, and compile the library once the include for the library is found, we could juggle something like this perhaps:

#include "Particle.h"

#ifdef RwReg
  #undef RwReg

#include "FastLED.h"
#define NUM_LEDS 60
void setup() { FastLED.addLeds<NEOPIXEL, 6>(leds, NUM_LEDS); }
void loop() { 
    leds[0] = CRGB::White;; delay(30); 
    leds[0] = CRGB::Black;; delay(30);

But that’s going to be a mess I think because there’s bound to be a bunch of things to redefine.

Suggested Way Forward (0.6.1)

I think the proper thing to do here to maintain compatibility with the library and older AND newer firmware, is to wrap the arduino-based defines embedded in the library with


These defines would have been needed in the past for older firmware when we didn’t have a lot of arduino defines by default. Now that we include everything and the kitchen sink, you don’t need to include these any more.

If you have your arduino defines grouped in one place, a test for ARDUINO might be a good way to include them all. That way you don’t have to put #ifndef on each of them, even though it’s still a good idea.

So that might look like this:

#ifndef ARDUINO
  // add my arduino defines here to be included for firmware < 0.6.1-rc.2 !

##Future Thoughts
A way around some of the issues we are having now might have been to not include the new big list of arduino defines by default, but instead just include the small list of defines from 0.6.0 by default and require users to include #include Arduino.h to get the big list. That sounds easy enough, but still might be tricky depending on when Arduino.h is included. It would likely involve undef/redef of the small list of defines from 0.6.0. This could also allow above proposed changes to libraries for 0.6.1 to remain working for >=0.7.0 as the small list of defines did not include ARDUINO.

1 Like

BDub, thanks for the detailed answer!

Here’s my predicament – I’m in charge of cubetube, which is a code-sharing site for LED cubes that are running on particle photons. A bunch of people in our community use the fastLED library to write programs for their cube, but now their programs aren’t compiling. I get that a more permanent fix would be to fork fastLED and throw all the conflicting defines, but I’m not super familiar with the inner workings of fastLED and my hunch is that it’ll take me a couple days to get that working right.

In the interim, the easy fix would be to just tell my system to compile with 0.6.0 firmware and throw in the couple lines of preprocessor code that lets fastLED compile with 0.6.0

 #include "Particle.h"

On the site, I send the “flash” command through particle’s JS API, but I don’t see anything in the docs about how I could specify a firmware version number. Is there a way that I could specify a firmware version through the JS API?


I think you mean 0.6.1, yeah? Well unfortunately you’ll still have issues with fastLED because it gets compiled first and is including application.h before PARTICLE_NO_ARDUINO_COMPATIBILITY 1 is defined, which will define RwReg, and fastLED then redefines RwReg.

I think for right now in your situation I would advise sticking with 0.6.0 firmware until we sort out a solution (I think as described in Future Thoughts above). You don’t need PARTICLE_NO_ARDUINO_COMPATIBILITY with 0.6.0.

You can specify targetVersion: '0.6.0' with the JS API

I’m also interested in a fix or possibly a branch of FastLED with the necessary changes until Particle has a better solution.

For me it worked to just comment the problematic line out in “led_sysdefs_arm_stm32.h”.

//typedef volatile uint8_t RwReg; /**< Read-Write 8-bit register (volatile unsigned int) */

Ok, I converted my project folder structure to V2 and I was able to comment out the RwReg line after copying the library to my project folder and removing it from But then I was thrown one more error:

../FastLED.h: No such file or directory

Deleting the lib/FastLED/src/FastLED folder got rid of the error and I was able to compile. Why do V2 libraries have this folder filled with .h files referencing their parents? Seems messy.

That is a legacy header so that older Web IDE projects that still use the #include "libName/libName.h" scheme will build with v2.0 libs too.
But the side effect on Dev and CLI was not considered

Hence I filed this issue a few days ago

Thanks, @ScruffR. It looks like I spoke too soon about compiling success. After making the change suggested by @bmencke, Particle Dev reports “Success!” sometimes but doesn’t actually download a .BIN file. Other times (with no code changes) it just throws a red error message at the bottom of the screen that says, “build didn’t produce binary Error: Command failed: In file included from /spark/com…”.

I compiled using particle-cli to get more verbose error info, and I get the following stream of errors. Any suggestions? The same code (minus @bmencke’s change) compiles fine for 0.6.0 in Particle Dev.

Try CLI with the switch --target 0.6.0

@enjrolas Just checking to see if you have tried 0.6.2-rc.1 with FastLED. We would like to make this the default firmware soon so I’d appreciate it if you can give this a test today or tomorrow and let me know if things are working for you :slight_smile:

Works for me with the Internet Button and this code:

#include "FastLED.h"
#define NUM_LEDS 11
void setup() { 
    FastLED.addLeds<NEOPIXEL, WKP>(leds, NUM_LEDS); 
    for (int x=0; x<NUM_LEDS; x++) {
        leds[x] = CRGB::Cyan;

Is it possible to test this with Particle Dev? My project is not easily transferred to the Web IDE.

If you update Dev to the latest version (1.8.0) you should be able to select 0.6.2-rc.1 as the build target version

Compiled successfully on 0.6.2rc1 with my existing FastLED project, which had been broken before.

EDIT: This project lives in the Web IDE.

I had stepped it down to 0.6.0 and included Particle.h in order to be able to continue to make updates to that project on my side, and followed this thread so that I would know when I could set it back to using the current firmware.

I haven’t run the project through its full paces, but it verified and flashed just great. Big sigh of relief from me. Thanks!


Great! My project (which was severely busted in 0.6.1) also compiles and flashes without any problem with 0.6.2-rc.1.


Confirmed - this works now for me too with 0.6.2-rc.1

1 Like