RGB-pimping

Erlend · 2013-12-17 03:11

I've never been particularily sold to the fashion of multicoloured LEDs for decoration, but when I found a rotary encoder with built-in RGB LED illumination of the transparent shaft&knob, I got the idea to let the colour of the light be a kind of user feedback. Next, I thought a TLC59711 (from Adafruit) would be a suitable driver. It has a SPI interface, and provides fine resolution PWM driver for each colour output. Should let me control the full rainbow of colours.

I have the feeling that I am re-inventing the wheel. Surely someone have already done this - or something similar?

Erlend

Leon · 2013-12-17 05:37

Which rotary encoder?

Erlend · 2013-12-17 07:20

This is the ''brilliant'' encoder.

JonnyMac · 2013-12-17 07:32

That chip uses a two-wire interface so you may be able to adjust my WS2801 RGB LED driver (which also uses a clock and data line) to suit.

I've used this driver in several "Hollywood" projects; for the most recent, see this thread:
-- http://forums.parallax.com/showthread.php/150675-For-League-of-Legend-and-Wes-Borland-(Limp-Bizkit)-Fans?highlight=wes+borland

Edit: You might just consider the WS2801; it's chainable, the code is done (attached), and it's a very small, easy-to-use chip. I think you can get the chip at Sparkfun (though their web site seems to be down at the moment).

Erlend · 2013-12-17 07:54

@JonnyMac
That's an incredibly impressive project! WS2801 looks to be a better choice and saves me driver coding time. Thanks!

Erlend

xanadu · 2013-12-17 08:44

I did this with just solid colors and it was really cool.

[video=youtube_share;xCZbo9CWn8Y]

Looks like it's time for an update.

Erlend · 2013-12-17 11:12

Very nice. In my case I am planning to let the colour gradually shift from dark red as the 'maximum' and to light blue as the 'minimum' user selection, and to use 'beating' to indicate processing, and flashing to indicate alerts. Time will show.
Erlend

kwinn · 2013-12-17 20:28

Erlend wrote: »

................................................

I have the feeling that I am re-inventing the wheel. Surely someone have already done this - or something similar?

Erlend

I'm not sure if it qualifies as doing something similar but I have been using signal probes that have a bi-color red/green led to indicate the state of a signal for many years. Red is low, green is high, and amber is toggling. Can't take credit for the original idea, that came from some magazine, but I now have one for 5V logic, one for 3.3V logic, one for 6VAC to 240VAC, and one for encoders.

The idea and circuits have been around for so long I just assumed everybody would know about them since they are so compact and handy to have.

JonnyMac · 2013-12-19 09:54

As you only have one LED there's no need to consume a whole cog with the driver -- you can update the LED in Spin (I did this when I first started just to verify things). In your program you'll need to pin constants (for data and clock) and you'll want to preset them to output and low. After that, it's this easy:

pub set_led(r, g, b) | bits

'' Updates single WS2801
'' -- uses WS_DTA and WS_CLK pin constants

  bits := r << 24                                               ' msb alignment
  bits |= g << 16
  bits |= b <<  8

  repeat 24
    outa[WS_DTA] := (bits <-= 1)
    outa[WS_CLK] := 1
    outa[WS_CLK] := 0

You could even call this from a Spin cog that is animating the LED based on the value you're tracking with the encoder -- just make the pins outputs in the animation cog so this will work. Better to use the cog for animation that for driving a single LED.

Erlend · 2013-12-20 00:21

Nice & easy! I think I'll put this code in the part of Main where the encoder value is evaluated, or alternatively in the encoder object itself (but that makes it non-standard, which I don't like). But first I have to get the hardware. The encoder is now shipping, but regards the driver I haven't decided to buy the bare WS2801 chip or the Sparcfun breakout. For the latter the on-board LED has to be removed so I can connect the encoder LED instead. Either way, I will have to do some 'micro-soldering'. A DIL version would have been easier, I think.

Erlend

JonnyMac · 2013-12-20 08:40

If you're not already going that direction, you'll want to use a separate cog to keep track of the encoder. If it's not high speed you could probably get away with a Spin cog. Most of us, though, have written our encoder drivers in PASM. I wrote the attached object some time ago but it does work well.

Erlend · 2013-12-21 00:58

I probably worded myself a bit unclear; I do intend to use an object in a separate cog for the encoder reading, but I am not sure if I should do the RGB control in that same cog, or if it is better to do it in the Main code, where the encoder value is used.

Erlend

JonnyMac · 2013-12-21 12:59

The cool thing is that you *could* run an animation cog in Spin that would have access to global variables. And... since the interface is Spin, your background Spin cog as direct access to the encoder methods as well. Fun stuff!

RGB-pimping

Comments