This Saturday, you will have the opportunity to join us in a live video conference about our Kickstarter, using Google Hangouts. We’ll be showing the RGB Shades and answering your questions. We’d also love to see your projects! IMPORTANT: If you’d like to participate in the video conference, please comment on this page and ask for an invitation. Have your video camera and microphone ready! Otherwise, you can just watch the stream and leave comments, we’ll do our best read and answer them.
Sample code to make XY programming of the RGB Shades (hopefully) very easy, sample animation included.
Since I don’t actually HAVE any of these Shades in my hand yet, I haven’t tested this code on the actual hardware, but I’m cautiously optimistic. (And I am a backer!)
I basically wrote a new version of the “XY” function that returns the pixel id for any given (x,y) coordinates. This code also uses the trick from the FastLED XYMatrix example code to let you safely stop worrying about whether or not a given pixel ‘exists’ in the board layout. You can safely write this, regardless of the values of x and y:
leds[ XY(x,y) ] = CRGB::Red;
@Garrett_Mace : Please let me know if this works correctly or what adjustments it needs (e.g., are the pixels RGB or GRB or something else), etc. I’d love to put this example into the FastLED library as fast as possible as sample code to get more people writing more animations for the RGB Shades!
Update: something about the code I posted was bothering me: it wasn’t screamingly fast. So I had coffee and fixed it. I still don’t have live hardware to test on, but notwithstanding the color-order issue, I bet this works.
Also, it’s reasonably easy to understand, and it’s a drop-in replacement for the XY function that most folks use in their FastLED animations – with the one caveat that you have to define “leds” as shown in this example code – meaning that there’s one extra pixel to represent the ‘off the grid’ LEDs.
Very nice code, Mark, thanks! I still have the quick and dirty method (basically having two pixel arrays and mapping one into the other). Being able to read back from the “holes” is useful for scrolling or overlay calcs, so I may add code to store the “holes” in another small array.
That would work…even if you were controlling multiple LED strips off the same pin, the LED Shades have to be the last one since I didn’t provide a data output from the last LED
Holes all now retain their data and are now all independently readable/writable. I like it; Thanks for the collaborative design feedback!
Also in this update: totally out-of-bounds coordinates now all map to the first hidden pixel; it’s safe and invisible to write to or read from “leds[ XY( 100,100) ]”. I don’t recommend this, but it’s better to have your animation glitch a little visually than crash and reboot the microcontroller.
@Mark_Kriegsman I’m really liking this approach, I’m actually refactoring the patterns from my old code into your foundation sketch. I’d dragged in a lot of baggage from routines developed years and years ago…using the FastLED helper functions and your mapping code, I’m seeing maybe 70% fewer lines of code to do the same things. Thanks! I’ll be setting up a macetech repository to share the code very soon, along with the hardware. Definitely hope to make /kriegsman a collaborator on that repository…
There isn’t much time, but if you wanted to see a pattern of your tried out live in the Hangout, your target is a 16MHz ATmega328, pin D5, pixel layout shown at this link here: 