robtillaart:
The answer is easy. What sense would it make to control zero leds? I agree with you that MAXLEDS is a bit oversized, could change this to 1 or leave it like so.
I would make it explicit zero because this value is used for testing in other functions. setLEd() in particular
Agreed.
robtillaart:
It is not possible to set the pins, now you are using 1 and 2 where pin 1 is allready part of the serial port....
This is the price of an early release ... I've tested the code only on one ATtiny85 right now. Last week I changed from software bit-banging to hardware output (USI). In a later (the next?) version of the library I will add support for real SPI and software mode.
OK, fair enough - however you can easily create a constructor with params and set these default to 1 and 2 (so UNO people can overrule)
Ok, is in work. I will change the default constructor to use the SPI/USI pins of the AVR (which should not be a problem afaik due to pin mapping lists and the preprocessor). A second constructor will be added to set the software mode:
DycoLed::DycoLed(byte _dataPin, byte _clockPin) {
// set data pin to _dataPin
// same to clock pin
}
robtillaart:
[bug 2x]
void DycoLed::setLed(unsigned int led, byte value[3]) {
if (led <= LEDCOUNT) {
if LEDCOUNT == 1 the only valid number is 0
Not right, 1 would be true, too. (smaller or equal to LEDCOUNT)
disagree if you fill in MAXLEDS in the constructor that would be accepted, but your internal arrays go from 0..Maxleds-1 (read the chapters about arrays in C/C++) That would be one missing.
Now I see what you mean, sorry for the late comprehension
I would change "led <= ledCount" to "led < ledCount" because LED0 would be smaller than, let's say ledCount=1, LED1 wouldn't be allowed to be set/read. In the example sketch of the library the index for the first led is 0 and it works perfect with ledCount set to 1.
robtillaart:
You have a double administration one for easy setting and one for sending.
You can win 60+bytes footprint by removing the ledMessage Array's. You could then also remove the complete update() function.
Yes and no smiley-wink
I had the just-in-time calculation in a very early stage of writing the code. But I thougt that pre-calculating all values and just sending them out at the desired time would be better. I will think about this again later.
You can also precalculate the values in setLed so that the both arrays are allways ready to be send.
Would work fine for setting a color, but would make it more difficult to read a color from the two output arrays with the 2x 8 bit values. For each reading you would have to calculate it back to the tree-byte format like I write it into the two output arrays.
On the other hand it could save some time when shifting the color information back and forth (see bottom of this post).
robtillaart:
issing the function getLed(&r &g & b);
What do you mean exactly? To get the values of a specific led ( getLed(byte led) with an array return)? Or to search for one led with the matching color values (returning index of led)?
I would like to request the color back from the LED. The array holds the value so why should I keep it.
Will be added. In my opinion this will become important when you calculate more complex color effects for the leds. Was not important for the first release where I only set a color
robtillaart:
Request for a new function
AddLed(r,g,b);
shifts all LED values in the internal array and places this RGB at index 0. Easy to create a moving light show !
I admit this request and would go one level higher What about a function like this:
void DycoLeds::shiftLeds(boolean direction, byte steps) {
// shift color information x steps in direction y, for example
// direction = 0, steps = 1 would make this with three connected leds:
// led 2 looses it's color information and get's the color from led 1,
// led 1 get's the color from led 0,
// led 0 becomes black
}
// call setLed(0, newRed, newGreen, newBlue) to give the first led a new color
//...
//same for direction = 1 in shiftLeds(), but now the last led get's a new color.
I have more ideas for effects. For example:
LED0 LED1 LED2 LED3 LED4 LED5 LED6 LED7 LED8 LED9 ...
red blue
A function like mergeLeds(byte firstLed, byte lastLed) could calculate the crossover colors for LED1 to LED6 if the first and last led are given to this function (LED0 and LED7). If you "move" LED6 to the left or right and let the function calculate the new leds in between, this could look nice, too
Or something like getting a full set of colors from another controller or a computer and fade to this in a certain amount of time. Would need a second color array, but could be useful.
Any other ideas?
PS: while writing in the forum, I added a function called end() which does nothing more than call resetAll() and set isInit to false (for a new initialization later on).