Is this how you're expecting us to use the HSV stuff?

Archive FastLED Archive
1

Is this how you’re expecting us to use the HSV stuff?

#include “FastSPI_LED2.h”

#define NUM_LEDS 110

struct CHSV leds[NUM_LEDS];
struct CRGB ledsRGB[NUM_LEDS];

void setup() {
// sanity check delay - allows reprogramming if accidently blowing power w/leds
delay(500);

// For safety (to prevent too high of a power draw), the test case defaults to
// setting brightness to 25% brightness
LEDS.setBrightness(64);
LEDS.addLeds<WS2811, 12>(ledsRGB, NUM_LEDS);
LEDS.clear();

}

void loop() {
for(int seed = 0;seed < 255;seed++){
// do cool stuff with hsv
for(int iLed = 0; iLed < NUM_LEDS; iLed++) {
leds[iLed].h = iLed+seed;
leds[iLed].s = 255;
leds[iLed].v = 255;
}
// copy csv array to rgb array
hsv2rgb_rainbow(leds, ledsRGB, NUM_LEDS);
LEDS.show();
delay(5);
}
}

2

That’s one way to do it. The other variation on how to do it would be to get rid of the CHSV array and your call to hsv2rgb_rainbow and instead do this:

for(int iLed = 0; iLed < NUM_LEDS; iLed++) {
hsv2rgb_rainbow(CHSV(iLed+seed, 255, 255), leds[iLed];
}

which uses the variation of hsv2rgb that works on a single CHSV object and a single CRGB object. This way you wouldn’t necessarily be doubling your memory usage.

Mark and I are still giving some thought to how we want to consider more tightly integrating the hsv transformations into the library automatically, and if we want to. I think we need to work on a couple more projects using things the way it currently is to work out some ideas.

3

The variety and flexibility of various ways to do things is one of those pieces that we’re going to have to work on documenting :slight_smile:

4

Yep, that should work. You could also do this, which is faster and uses only half the memory:

struct CRGB leds[NUM_LEDS];

void loop() {
for(int seed = 0;seed < 255;seed++){
// do cool stuff with hsv
CHSV temphsv;
for(int iLed = 0; iLed < NUM_LEDS; iLed++) {
// prepare HSV values
temphsv.h = iLed+seed;
temphsv.s = 255;
temphsv.v = 255;
// convert HSV into RGB,
// storing directly into the led array
hsv2rgb_rainbow( temphsv, leds[iLed]);
}

    LEDS.show();
    delay(5);
}

}

5

For pretty-rainbow-demo purposes, you can also just use fill_rainbow. We figured people might want that as a nice quick demo and starting point.

struct CRGB leds[NUM_LEDS];

void loop()
{
static uint8_t startinghue = 0;
startinghue = startinghue - 1;
fill_rainbow( leds, NUM_LEDS, startinghue);
LEDS.show();
delay(5);
}

6

This last one falls into the realm of “things we need documentation and example code” for :slight_smile:

7

but now, I’m going to step away from this for a few hours and go to a bbq - I was up late last night, accidentally implementing support for two more led chipsets. Oops.

8

Thanks guys. That helps. It seemed a little odd to me to have two arrays. In my real code I need to individually address the pixels I was just trying to create the simplest sample. Converting from hsv2rgb each time I change a color should be more efficient. It would be awesome at some point to be able to create a controlled with a HSV array instead and try to live in that color space all the time… That’s how I thought at first that it would work (without giving it much thought to be honest). Enjoy your BBQ. The weather’s sure set for it.

9

Zeke: that’s exactly where we want to get to. It’s not going to be easy, given the technical fact that the strips only speak RGB, and the MCUs have limited RAM and CPU power-- but that’s definitely the vision we’re trying to head toward.

10

That is the eventual plan - but time :slight_smile:

That said, i do have a proof of concept that interleaved the translating hsv to rgb with writing led data out without impacting the speed of writing led data out - meaning you not only save the memory but you incur no time cost for the translation.

Because that’s what we’re about, giving you more in less :slight_smile:

11

This is amazing on so many levels. Thank you!

12

Awesome. Right now I’m not CPU bound so converting as I go will work, but I look forward to the future. I’d better buy some shades, it seems like it’s going to be bright.

13

Our intention is to keep you from being CPU bound for as long as possible :slight_smile:

14

Also, if it gets too bright you can just lower the global brightness level (for free :wink:

15

You’re telling me timbuk3 got it wrong… They. Just needed FastSPI!

16

I think Dan and I could probably get it down to Timbuk1.8

17

New game - optimization poker I’ll see your 1.8 and lower you to a 1.4.

It was pointed out to me that this could also be called government contract bidding.

18

This is awesome. Thanks!!!