I’m also using NO_CORRECTION 1, not sure if that affects the timing or not
No, it doesn’t, all that means is that your clock is going to drift since the systick interrupt handler won’t fire while writing out led data
So - at this point i’m back to my original suggestions - split the line in two, or don’t use the attiny167 
Thanks, I really appreciate the effort. I wonder if I can unroll that for loop…? or will the asm labels not be happy?
Ha! Unrolling that loop worked Thanks!!!
This is why I love this library/community. Is there any chance you could post some photos of that controller. I’ve been playing around with wearable projects, and the controller is always the least organised part. Yours sounds very tidy
Sure! I can’t seem to post photos in g+ comments but the PCB and code are at https://github.com/BlinkyBee/TinyBee, or you can order the PCB from OSHPark at https://oshpark.com/shared_projects/CENaCvmW
I posted some pictures in a separate post
@Daniel_Garcia Thanks again for helping out with this. The only way I could get it to work was to manually unwind the asm and comment out the DNOP in the second iteration. If I don’t comment it out I get a weird flicker on the second render.
A weird thing that is happening is that the green led of the first pixel in the second iteration is always on (with and without the DNOP). Anything off the top of your head I should try resetting to avoid that? Is it leftover dithering from the last pixel of the first iteration?
Thanks!
(first off - fixed a minor bug around setting of saveb0 in the gist - you should update your code - https://gist.github.com/focalintent/f2225596fd6e1c58e027 )
The green is because the compiler is tossing a bunch of extra stuff in between the first handful of asm statements that is throwing off the timing, resulting in the first bit being written out being interpreted as a 1 instead of a 0, since the led’s byte ordering is GRB, that’ll turn it green.
Why isn’t this happening for every led in the second half? I think what is happening is that when you unrolled the loop, you didn’t change the label definitions for the second round of writing out data. So, when it gets to the end of the second label and jumps back to “loop” it’s jumping back into the first round of code, which isn’t as fubar’d, and so the rest of the leds write out “normally”.
Hmm… wouldn’t that result in an infinite loop?
I’ll try the new gist! Thanks
yeah, though i’m not sure why the bit would get stuck. The other possibility is that gcc is juggling stuff around in a way that bsave0 is getting trashed (or the write into b0 is getting ignored in the second loop). Honestly, I’d have to start digging through disassemblies to find out for sure what’s going on.
Yeah, no worries. A stuck green pixel is a small price to pay. The jacket will be awesome Maybe I’ll always reset b0 to 0, better have the green off than on