RMM, it does. I missed about 45 posts of development over on the STAR thread, but skimmed it afterwards. I didn’t think I missed something like that though. Are you sure there is a firmware which can handle this? It’s a pretty different proposition from what we do with other drivers. Either way, please link me to whatever you are thinking of!
You are correct ToyKeeper - the two pins with PWM available are tied to the single 7135 and the FET. Really I suspect that with this many 7135 addressable like this you only need the PWM on the single 7135 for setting the brightness of moonlight. You’re also correct about the MCU - an ATtiny25 should fix any space issues. OTOH if the software fits on the same chips we use for everything else… meh.
Like I mentioned somewhere, I figure a 2D array representing each output from the ATtiny would work well. You could extend the array to cover PWM types as well. I could be wrong, I have no idea what impact on available resources an array like that would have… doesn’t seem like it would be that bad. That way you could say
(single7135, dual7135, triple7135, FET)
(1/255,0,0,0/255) - terrible moonlight
(100/255,0,0,0/255) - brighter moonlight, heh
(255/255,0,0,0/255) - 1*7135
(0/255,1,0,0/255) - 2*7135
(0/255,0,1,0/255) - 3*7135
(255/255,0,1,0/255) - 4*7135
(0/255,1,1,0/255) - 5*7135
(255/255,1,1,0/255) - 6*7135
(0/255,0,0,255/255) - FET Turbo
or anything along those lines you wanted. (I’m sure you understand this, but for the benefit of others reading… Nobody wants that many brightness levels in their regular mode group of course! You’d define the array accordingly with whatever modes you want, those are all examples.)