Profile cover photo
Profile photo
Daniel Garcia
727 followers -
I play in waves
I play in waves

727 followers
About
Daniel's posts

Post has attachment
A handful of administrivia things:

* Because of a recent death in our family, +Mark Kriegsman and myself are going to be stepping back from FastLED for a little bit. One of the things we love about this community is how helpful all of you are with each other, and we're extra thankful for that right now. There's more in Mark's post here: https://plus.google.com/112916219338292742137/posts/5h1K2DSGd9w?sfc=true

* In light of the above, +Jason Coon offered to help out with moderation here, so I've bumped him up to moderator to help out with when g+ decides to auto-moderate posts.

* Also - I believe I have discovered what it is that's causing g+ to auto-moderate posts - it appears to do so when folks use pastebin for posting code. In that case, please use gist.github.com, not pastebin for posting code - I've updated the faq at http://fastled.io/faq to reflect this.

I'm going to pin this post, and will update it as we figure out more things (we haven't decided yet whether or not to add another admin to the FastLED github yet, for example).

Thank you again, everyone, for your support, for being a fantastic community, and for all the light.

Post has attachment
4200 leds, 18 esp8266 controllers syncing to each other, lots of noise, wifi interference based motion/presence detection:

https://youtu.be/hh6tYmGo31c

Post has attachment
Heads up, folks that like to play with betas. It appears that the CH340 driver from here http://blog.sengotta.net/signed-mac-os-driver-for-winchiphead-ch340-serial-bridge/ - causes kernel panics on the macOS 10.12 beta that was released earlier this week. Note that many of the ESP8266 boards out there use the CH340 instead of FTDI... Going to see if I can find drivers that work, but in the meantime, be careful out there!

Just pushed new code to master enabling 4-way parallel output on the ESP8266.

It seems to be working pretty solidly, though as with other parallel outputs, you have to be careful about cross talk between your data lines since all of them are being written to at the same time.

(Why only 4 way? Because while the ESP8266, in theory, has 17 GPIOs, 6 of them are permanently unavailable to us, and they're right in the middle of the pack. This leaves the block of 4 pins at raw GPIO's 12,13,14 and 15 and/or the GPIO's at the low block of pins 0-5. I elected to only support parallel on the high block for now, since in the 0-5 block, pin 1 and 3 are used by the USART, so once again, no contiguous pins on the port to use for parallel output).

Enjoy!

Post has attachment
POV folks pay attention:

One of the things that has nagged +Mark Kriegsman and I about FastLED's scaling math of late (specifically, the math that we use for everything - including the inline brightness/color correction) is that it has a small quirk, in the name of speed.

Many of you folks have run head long into this.

I'm talking about the dreaded scale8(255,255) = 254 'issue'. (If this hasn't ever bothered you, feel free to skip the rest of this, just know it's been fixed :)

This was a side effect of a performance decision made early on - but we've put work into being able to fix it (I did up a blog post a bit ago on optimizing this for avr - https://gist.github.com/focalintent/0d2de5159f6f9d47fcec).

The big trick was making sure that everything else in the library was in line. This includes the asm code for 3-wire led chips on AVR and ARM M0 chips. This also includes various other places in the library that may have tried to account for this (or exploited this).

In a fit of cascading changes and choices to not sleep, last night +Mark Kriegsman and I finished getting this fix across the entirety of the library, and it's now been pushed to the master branch.

What does this mean for you? Well - now, if you're running with setBrightness(255) (and no color correction/temperature defined), then the bits that are in your CRGB array are exactly what's getting written out. (For POV folks, this will be great - no more extra gap for solid, full bright colors. For POV folks using WS2812's, first off - WHY?!? Secondly, you're still going to see gaps, because the WS2812 does one dark cycle between every PWM cycle, even at all on).

What else does it mean for you? This will cut back on cascading errors across multiple scale8 calls. You'll see smoother ramps in lower HSV values.

The rumors about cats and dogs sleeping together are just that, rumors, and even if true, no one can prove that has anything to do with us fixing scale8.

If you need to turn it off - you can edit the file fastled_config - and change the value for FASTLED_SCALE8_FIXED to 0.

(And for the folks playing along at home, this was the last major bug/issue that I wanted to get fixed before turning my attention to RGBW/RGB16)

Hey look!

ESP8266 support!

It basically supports everything in FastLED - all the led chipsets, all the library, etc... It doesn't have hardware SPI support (yet) but there is bit banging support that's more than enough for pushing APA102's right now.

It also doesn't yet have parallel output support, the jury is still out as to whether or not that will end up working or working well.

(currently only tested with the http://arduino.esp8266.com/stable/package_esp8266com_index.json board definitions in Arduino).



PEOPLE: Even though I ask constantly, and even though it's near the top of the faq that the group description links to and asks people to read before posting (http://fastled.io/faq), etc.. etc... I still find myself having to constantly ask people for basic information in trying to help.

So - again, if you're posting asking for help with code that doesn't compile or doesn't work right - please include:

* what platform you're using to build (arduino, code bender, something else)
* what hardware you're building for (be specific! Trinket Pro 5v/16Mhz or Teensy 3.2, etc...)
* a link to your code on either gist.github.com or pastbin.com - don't try to guess at what you think is important for solving your problem - more often than not important pieces get left out

etc...

it'll make everything go faster, trust me :)



For folks who raise questions about the overhead of C++ vs. C - check this out. While doing timing testing and tweaking for the CRGBSet stuff, I added support for C++11 style ranged loops - and I discovered that they were faster! For example - this code:

for( CRGB & pixel : leds) { pixel = CRGB::Black; }

runs about 10-20% faster on AVR than this code:

for(int i = 0; i < NUM_LEDS; i++ ) { leds[i] = CRGB::Black; }

(10% faster if NUM_LEDS is less than 255, 20% faster if NUM_LEDS is over 255. Bonus points to folks that can tell me why (I already know and +Mark Kriegsman I suspect you do too :))

Some good stuff coming down the line :) (Also, I've changed how i'm referring to these things internally to PixelSets - mostly because RGB pixels aren't going to be the only types of pixels supported before long)

Post has attachment
Wouldn't it be nice to work on entire sets of leds at once? People keep asking for it, and I think I found a way to do it that I'm happy enough with. Imagine if you could write:

leds(0,4) = CRGB::Red;

to set the first 5 leds to be red. Or what if you wanted to copy the contents of the first part of your led array to the second part?

leds(10,19) = leds(0,9);

why don't we mirror it, instead?

leds(10,19) = -leds(0,9);

and let's fade everything out the way we like to:

leds.fadeToBlackBy(32);

what about some math?

leds *= 2;

or let's just do that on some of the leds

leds(5,9) *= 2;

let's put a rainbow on our leds:

leds.fill_rainbow(hue++);

or, again, just on a subset of the leds:

leds(10,14).fill_rainbow(hue++);


Welcome to CRGBSet - https://github.com/FastLED/FastLED/wiki/RGBSet-Reference!

The heart of the CRGBSet is the ability to take a subset of leds, and a subset is defined as being the first led and the last led you want in the set. So:

leds(10,14) starts at led index 10 and ends at led index 14 and has 5 leds in it - 10,11,12,13,14. Of course, you can reverse that and say leds(14,10) - which still has five leds in it, but leds(14,10)[0] will be led 14 :)

Once you have a set of leds, you can do all sorts of things to them. How do you get that first set of leds? Simple, you slightly tweak your led creation:

CRGBArray<NUM_LEDS> leds;

Now you have a CRGBSet that represents all your leds. You can then take subsets of it. leds(0,9) returns a subset of the first 10 leds in your set of leds - this subset is also a CRGBSet - which means you could, in theory, take a subset of that!

Want to duplicate the leds from the first half of your strip to the second half?

leds(NUM_LEDS/2, NUM_LEDS-1) = leds(0,NUM_LEDS/2-1);

What about mirroring? That's easy, just reverse the ordering of one of the sets:

leds(NUM_LEDS/2, NUM_LEDS-1) = leds(NUM_LEDS/2-1, 0);

Pretty much everything you can do to a CRGB you can do to a CRGBSet. CRGBSet also has fill_rainbow, fill_gradient, nblend, etc... methods on it as well.

Still adding to this - now there's support for C++11 ranged for loops (if you're building in an environment that supports C++11) - for example to set pixels 8-10 to random colors:

for(CRGB & pixel : leds(8,10)) { pixel = CHSV(random8(), 255,255); }

Of course, you can do this over all your leds:

for(CRGB & pixel : leds) { pixel = fadeToBlackBy(40); }

(which is equivalent to leds.fadeToBlackBy(40);, but just wanted to show this stuff off)

This is VERY VERY alpha code. It probably has bugs, it is probably incomplete. It might set your house on fire. Use at your own risk.

And have fun!

[ETA: And now i'm going to be out for much of the rest of the night - split even odds on me responding to comments in the next half hour, code updates are right now. It's like tossing a live grenade into the playroom just before stepping out for lunch :] 

Post has shared content
Damn, somehow comments were disabled, re-sharing/posting. 
G+ folks - you know I like to build LED things that hang on walls (things along the lines of Tree of Life ( https://vimeo.com/116292464), Flow (https://www.youtube.com/watch?v=to0x_6CDh60) or the Three Sisters (https://www.youtube.com/watch?v=FzQE8k6uSKQ). I like doing these, and I'm hoping to do more of them in 2016.

A number of folks have asked whether or not I sell these things (for a variety of reasons, I'm unlikely to sell any of the 3 mentioned here) - and I keep pushing off the question, but I think in 2016 I'd like to start doing that!

One question is - how? I could make things as I see fit, and then put them up and see if it gets any interest. Or, I could take a commission type thing ("I have an X by Y foot area of wall - hang a thing there!"). Or, I could make a thing and then make copies of it on (semi) demand for people as interested. Or something else entirely?

Another question is price. I'm not even sure what price range people would be willing to pay for things like this. (I've had people tell me what they thought someone should pay, but that's different, I think?). Which also leads to the how - do I pick a price and work backwards from there? Or do I do a thing and let the price fall out from that?

There's tons of other questions that I need to figure out answers to as well, but the above questions alone have been spinning, unresolved, in my head for well over a year now so I think it's time to add more voices.

That aren't in my own head.

Thoughts?
Wait while more posts are being loaded