FastLED not compiling to Photon

Does the lib still build when you target some firmware pre 0.6.0?

There are some threads that discuss this problem too, maybe there are some hints you haven’t tried yet.
https://community.particle.io/search?q=crgb%20fastled

1 Like

Hey, try adding FASTLED_USING_NAMESPACE; just below #include "FastLED.h".

You can ready more about it here: https://github.com/focalintent/FastLED-Sparkcore/blob/master/firmware/README.md

3 Likes

Adding the namespace worked like a charm. Thanks guys!

I thought i had dug through all the readme files for FastLED but this one in the firmware folder must have snuck by me. Thanks again!

Regardless of FASTLED_USING_NAMESPACE, there appears to be a build issue with the 0.6.0 firmware release. I just tried creating a brand new empty app and including the FastLED library (3.1.5) and it won’t build. The error is a conflict for the RwReg typedef. This builds fine with 0.5.3.

lib/FastLED/src/led_sysdefs_arm_stm32.h:36:32: error: conflicting declaration 'typedef volatile uint8_t RwReg'
 typedef volatile       uint8_t RwReg; /**< Read-Write 8-bit register (volatile unsigned int) */
../wiring/inc/spark_wiring_arduino.h:153:27: error: 'RwReg' has a previous declaration as 'typedef volatile uint32_t RwReg'
 typedef volatile uint32_t RwReg;

I can confirm this problem. It doesn’t seem to work in 0.6.0. Don’t have a solution though.

Just fleshing this issue out – when I add the FASTLED_USING_NAMESPACE line, I’m able to get the code to compile for 0.6.0 or 0.5.3 firmware versions, but when I compile for 0.6.1, I get the RwReg error that people are mentioning above.

I’m using the particle web IDE, compiling the sample fastLED code below

#include <FastLED.h>
FASTLED_USING_NAMESPACE;

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

works fine for 0.5.3 and 0.6.0 firmware targets, for 0.6.1 I get the following error:

In file included from /src/fastledtest.cpp:2:0:
lib/FastLED/src/FastLED.h:12:2: warning: #warning FastLED version 3001000 (Not really a warning, just telling you here.) [-Wcpp]
 #warning FastLED version 3001000  (Not really a warning, just telling you here.)
  ^
In file included from lib/FastLED/src/led_sysdefs.h:16:0,
                 from lib/FastLED/src/FastLED.h:34,
                 from /src/fastledtest.cpp:2:
lib/FastLED/src/led_sysdefs_arm_stm32.h:26:0: warning: "cli" redefined [enabled by default]
 #define cli()  __disable_irq(); __disable_fault_irq();
 ^
In file included from ./inc/application.h:92:0,
                 from /src/fastledtest.cpp:1:
../wiring/inc/spark_wiring_arduino.h:141:0: note: this is the location of the previous definition
 #define cli() (void)HAL_disable_irq()
 ^
In file included from lib/FastLED/src/led_sysdefs.h:16:0,
                 from lib/FastLED/src/FastLED.h:34,
                 from /src/fastledtest.cpp:2:
lib/FastLED/src/led_sysdefs_arm_stm32.h:27:0: warning: "sei" redefined [enabled by default]
 #define sei() __enable_irq(); __enable_fault_irq();
 ^
In file included from ./inc/application.h:92:0,
                 from /src/fastledtest.cpp:1:
../wiring/inc/spark_wiring_arduino.h:136:0: note: this is the location of the previous definition
 #define sei() HAL_enable_irq(0)
 ^
In file included from lib/FastLED/src/led_sysdefs.h:16:0,
                 from lib/FastLED/src/FastLED.h:34,
                 from /src/fastledtest.cpp:2:
lib/FastLED/src/led_sysdefs_arm_stm32.h:36:32: error: conflicting declaration 'typedef volatile uint8_t RwReg'
 typedef volatile       uint8_t RwReg; /**< Read-Write 8-bit register (volatile unsigned int) */
                                ^

In file included from ./inc/application.h:92:0,
                 from /src/fastledtest.cpp:1:
../wiring/inc/spark_wiring_arduino.h:153:27: error: 'RwReg' has a previous declaration as 'typedef volatile uint32_t RwReg'
 typedef volatile uint32_t RwReg;
                           ^

make[1]: *** [../build/target/user/platform-6src/fastledtest.o] Error 1
make: *** [user] Error 2

@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:

#define PARTICLE_NO_ARDUINO_COMPATIBILITY 1
#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

#define PARTICLE_NO_ARDUINO_COMPATIBILITY 1
#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.

Legacy

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.

Present

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
#endif

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

#ifndef MY_ARDUINO_SYMBOL 
  #define MY_ARDUINO_SYMBOL 
#endif

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 !
#endif

##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

 #define PARTICLE_NO_ARDUINO_COMPATIBILITY 1
 #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?

thanks!
–alex

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 https://github.com/spark/particle-api-js/blob/master/docs/api.md#compilecode

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 project.properties. But then I was thrown one more error:

../FastLED.h: No such file or directory
/src/FastLED.h:1:24

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