Got the Pi claimed and up and running beautifully, tinker lets me fiddle an LED, and I now have VNC set up so I can hit up the pi to watch what is happening. Super excited about this environment.
Predictably, a library I completely take for granted, FastLED, has some compilation issues when the Pi is the target. Same sketch works beautifully on a Photon, but on the Pi, I get:
In file included from /workspace/FastLED/FastLED.h:34:0,
from /workspace/pooper.cpp:2:
/workspace/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"
Once upon a time I had to make some tweaks to an included library, and I could have sworn there was a part of the Web IDE that allowed me to do so for a specific sketch. Is there a way for me to import the FastLED library as actual files associated with this project any more? Or do I have to go in and create new files and paste each one?
Essentially, is there a way to do an in-web-IDE fork so I can see about fixing this library issue?
Alternatively, anyone know a way I can bribe the FastLED authors to fix it?
There will definitely be tweaks to very specific libraries like this one for the Pi.
What kind of LEDs are you using?
We’re in the final steps of reworking the library system to make working with libraries in any tool (Web IDE, Desktop IDE or command-line) easier. Currently you have to fork the library on GitHub, do your changes and publish a new private version through the Library panel of the Web IDE. Stay tuned for instructions on how to do this with the new library system!
Of course, I should have expected some friction on very hardware specific libraries like this, and I am just trying to navigate out of it.
The rub is I am only using a single one of the giant 8mm neopixels adafruit sells - so a lot of FastLED’s power is wasted here, and I could easily use the neopixels library (which appears to be updated for the Pi) - however, the project that I am moving from a photon to a Pi uses HSV color fades.
My current line of thinking is to replace FastLED with the Neopixels library, and figure out a way to do the HSV fade math myself, instead of relying on FastLED. I have done some RGB/HSV math before though, and it’s pretty brain hurty, so I’m hoping to find some ready made code for that.
I will look forward to the changes to the library system, but will see if I can find an immediate workaround for this little hiccup.
Hi - FWIW I did see mention on adafruit site of an alternative library for Pi and neopixels. This library uses a pin and sets up DMA to do the very timing specific transfer to the Neopixel that bypasses the issues of your task being pre-empted during a neopixel transfer.
Of course if I had been quick enough I would have got on to the Raspberry pi particle test - and would have tested the new library with particle…
It’s worth a lot actually. The security camera demo that we put together uses a PWM + DMA library to drive Neopixel from the Raspberry Pi. It’s not wrapped up in a nice library yet but it works!
and then found that the Neopixel library explicitly does not work on the Pi, and that I need to look more closely at the difference between “Pi” and “P1” on the library compatibility icons in the web IDE
I appreciate the detailed HSV code example, and I know many others would probably take advantage of it if it was available as a library. Simplifying HSV math is one of the best features of FastLED.
I will see if I can bash the camera example into doing what I am looking to do, or use the rpi_ws281x lib directly - they appear to expect RGBW LEDs rather than RGB, so I’ll see if I can figure that out-
Beginning to think I may be overthinking this, and I should just use a Photon. My PIR sensor for this project can switch-hit to 3.3v, and the LED is already solved, so I could save the Pi for something more interesting, and less dependent on interrupt handling code…
