Open jrmedd opened 7 years ago
jrmedd
commented
7 years ago Started branch 'wired_controller' to deal with this.
Usage:
set NUMBLOCKS to the number of blocks (code in my example uses 8)
set NUMPIXELS to the number of pixels in each block (code in my example uses 8)
the Serial message should be 'blockNo,r,g,b'
danhett
commented
7 years ago OK this definitely works for a single strip from Processing, and there's no visible latency on colours/brightness. However I do get weird results when I try to ping many at the same time - for example:
for(i = 0; i < 3; i++) { if(controls.staticToggles.get(i).getValue() == 1.0) { strip.write(str(i) + "," + red + "," + green + "," + blue); strip.write(10); } }
This lights up the first three rows as expected, but they have odd colours and don't react. I wonder if the serial comms are flaky from Processing maybe...
jrmedd
commented
7 years ago Putting what I said in a text to Dan earlier, that sending too many messages at once is likely slowing things down. Before now, we've been limiting serial comms to every 5 frames in the Processing sketch.
To remedy this, best approach is probably to assemble a longer string for each block on the length of Neopixels, then send that every 5 frames, rather than a load of separate messages e.g.
'255,255,255 255,255,255 255,255,255...'
It sounds counter-intuitive, but sending 8 shorter serial messages in quick succession every 5 frames will be much slower than one longer one!
danhett
commented
7 years ago OK, so sending a strip of values does with the neopixel square, but not with the full rig. The only change on the arduino side is:
void loop() {
if (Serial.available() > 0) {
BLOCK = Serial.parseInt();
RED = Serial.parseInt();
GREEN = Serial.parseInt();
BLUE = Serial.parseInt();
colourBlock(BLOCK, RED, GREEN, BLUE);
}
}
Presumably this should loop until it's got all of the blocks of four numbers, but doesn't seem to work when using either a mega or an uno?
12 'rocks' of 16 pixels, each 'rock' to be addressable