Woohoo, I've got an driving my LED strip, having never used an ATTiny before,

Woohoo, I’ve got an #ATTiny85 driving my LED strip, having never used an ATTiny before, in about an hour!
However I have a few questions/notes for anyone that’s used this:

  1. Is there a wiki/blog post about this? I learned about it just by scanning this community, couldn’t find anything more about it.
  2. I can’t seem to use more than about 80 LEDs, or nothing happens, is this a memory limitation? It’s well below the program limit, but I guess it’s RAM.
  3. Using the FirstLight demo, some of the non-lit LEDs show faint random colours, hardly noticable at first but getting worse as time goes on. Is this something to do with the constrained hardware, or the internal clock being less accurate, or are my connections bad? This effect does not seem to be noticeable with the fill_rainbow demo, so maybe it’s only black pixels.

Thanks!

#2 & #3 are probably related.

You don’t say what LED strip you are using, but power is often a problem.

A) Make sure the 0v (Gnd) on the power supply is also a good connection to your Tiny. 0v is everything as far as signal references go.
B) Voltage drop down the strip/string is a major headache. Feed power into both ends of your strip, especially if it is over about 600mm long. You will probably need to inject power at the start and the end and about every 1m (3ft for those who work in old money).
C) Each LED colour (RGB) uses about 20mA when fully on. With 80 LEDs that is nearly 5A of power needed by the LED strip alone. Make sure your power supply is up to the job. And this is why you inject power at intervals down the strip. To prevent voltage drop and melting of the wires.
D) Make sure your Tiny is using a crystal for timing. Not an internal oscillator, resonator or some other time source that that can wander around all over the place.
E) The number of LEDs is limited by the amount of RAM free, both the Arduino IDE and Atmel Studio should tell you if RAM is a problem at compile time. But running of of RAM during runtime is much harder to identify. If at compile time you have less than 10% RAM free, consider you will probably have problems at runtime. Normally if you run out of RAM at runtime, it will corrupt and just appear to hang the program.

Power and clock/timing issues highlight themselves as any or multiple:
Wrong colours, flickering colours, not black when off, not white when fully on, etc.
And this can get worse the further you are from a power injection point (for power issues). It is advisable to use a single power supply to power all the LEDs in a strip, so this needs to be big enough to power the whole strip as 100% white. If you have multiple strips, then these can have their own power supply, but make sure all the 0v (Gnd) are well joined together or you will get similar results as the power supply being too small.

Hope this helps.

Damn, I’m sure I responded to this already, but it’s lost…

Thanks for your detailed response Adam! It’s a WS2811/2812.

A) I did some more testing and found that even with all LEDs set to 1, they were stable. It was only at 0. At white, or changing colours, it was fine. So I suspect ground issues, since after all it’s only on a breadboard. As I was trying to add extra wires or find loose ones, the effect got worse - seemed to multiply the errors which continued to propagate. I fiddled with the IC itself and things improved a bit. Maybe I should create a breadboardable socket for it. Any more than that and I’d have to look into how the protocol transmits 0.

B,C) I have a 5V 7A power supply which is able to power 4m quite well, and it’s 3m now (180 leds). I never noticed problems before but then I rarely used black.

D) I’m just using a bare Tiny and don’t have a spare crystal, but as above I think it’s more likely ground.

E) The IDE didn’t tell me anything about RAM, only that it was a 3k program in 8k memory. The Tiny85 only has 512b RAM, and I suspect the LED array is the largest thing in memory at 80*3 = 240b. The rest of the simple program must be taking up the rest.

Cheers
Joel

E) You’re right, the Arduino IDE only shows program memory, even in verbose. Not very helpful! The Atmel Studio, which I now use mostly, gives you program and RAM memory usage. Strings eat up RAM because they are copied over from program memory, but on a Tiny I don’t expect you are using many, if any. But I don’t consider this a problem from your response.

A,D) I’m convinced it is timing issue. The timing of these LED strings is unbelievably critical. Without a crystal, just fluctuations in the supply to the Tiny is going to alter its timing and as this gets further down a transmission sequence, the more likely the LED is going to see the wrong value. I’m guessing the same power feeds the LEDs and the tiny and if this fluctuates the Tiny internal oscillator changes very slightly. I have not cheked the data sheet, but I’m guessing the data is transmitted MSB through to LSB. Hence if the timing is out (bit by bit), then the lesser bits will get mis-read and thus not quite producing black. Stray capacitances in the prototype can also slow the edges and cause mis-readings. Money on not using a crystal or oscillator module as the timing fault. You could recalibrate the internal oscillator using AVRDude and see if that improves things - or bend it manually. Read out the current calibration setting first, so you can restore it if needed.

B,C) Glad you have got the power up to scratch.

Adam.

Given the RAM limitations (including number of leds) I don’t think I’m going to continue this particular experiment unless/until I want to drive a smaller number or need the chip to be very cheap. I’ll use cheap arduino pro minis instead.

This info should still be useful to others in the community, so thanks Adam :slight_smile: