If you're driving LEDs with a shift register (eg 74xx595), is it bad practice to keep shifting the same data in all the time?
For example, say I make one of those binary clocks, with an Arduino or an ATTiny driving a shift register connected to some LEDs. The main loop of my sketch may end up executing 100s of times a second, but the display only needs to change once a second.
I normally do this sort of thing:
void loop() {
myData = getNewData();
if (myData != oldData) {
// This code will only execute if
// the data has changed:
shiftOut (myData, blah, blah);
// keep track of what's on the display for next time:
oldData = myData;
}
}
But is it necessary / beneficial in any way? This is perhaps an overly trivial example.
A better example: If I'm using several biggish LCDs - those 20 x 4 character 44780 ones - to display lots of live data that may or may not change, should I be writing code that checks if anything has changed before pushing what may be the same data out to the displays again? Is there any harm in redundantly refreshing displays with unchanging data?
There's a cost to doing selective display updates: takes more memory, more code / power to do the comparison.
I realise this is a bit esoteric (probably doesn't matter really) but I naturally veer towards over-coding even in situations where it doesn't matter. And I do over-think things.
Is there a general rule, a best practice? "Only refresh when you have to" vs. "Don't bother wasting time/memory on it, there's no need to cull redundant refreshes"?
CMOS logic doesn't wear out as there are no moving parts!
Well, strictly speaking semiconductor devices do age, mainly due to thermal
effects, but CMOS logic is so low power (unless clocked at full speed) that
the glib statement above isn't too far from the truth.
The advantage of testing for change in your loop() function is that it frees up
more processor cycles for other tasks.
A disadvantage is that if the shift register is remote and its cable picks up
interference you might occasionally get spurious changes at the shift register.
Regular updating will restore the correct state at the shift register - this makes
the system a bit more robust against outside influence (in particular if the
shift register is remote and remotely powered then it would matter - although
if remotely powered you'd need to protect its inputs against overcurrent in
the case the remote power fails).
Thanks, Mark - as I get onto more complex projects it gets more costly to do the testing-for-change routine (not least because you have to have two copies of the display data in memory). No point in me making things more complicated than they need to be.
Shift registers are just one of the logic functions in our computers with thousands of millions of transistors switching at thousands of megahertz. We certainly hope they do not "wear out" in our lifetime (though the functional "lifetime" of a computer seems to be somewhat limited be being superseded), especially in embedded devices we expect to be durable for the lifetime of a house, for example.
EEPROM and "flash" memory have limited write cycle endurance, though processes are being developed to extend even this.
One does wonder how LEDs can be quoted with lifetimes of 50,000 hours (5½ years) or double that - how can they test this when a device has only been to market for a few years?
Paul__B:
One does wonder how LEDs can be quoted with lifetimes of 50,000 hours (5½ years) or double that - how can they test this when a device has only been to market for a few years?
One could assume that the people who make LEDs know the materials that go into them and how those materials react to electricity, temperature, etc.
One does wonder how LEDs can be quoted with lifetimes of 50,000 hours (5½ years) or double that - how can they test this when a device has only been to market for a few years?
By carefully measuring the decline in light output over a few weeks they can extrapolate at what point the light output is half the initial output. That is what the lifetime of an LED is not when it fails.