Don’t sweat it, but please do proofread! Write, take a break, then read/re-read.
and LOL @ wife excuse 
Check this page out for attiny differences. The attiny25/45/85 are code compatible with each other, but not exactly with the attiny13a. The 25/45/85 can do 6 PWM outputs (assuming you have the model with enough pins!)
It still seems to me that we should be doing most of our custom drivers with attiny25 chips instead of attiny13a. It costs a few cents more, but can do significantly more complex tasks. The extra ROM space alone would be a big help for making deeper user interfaces or adding end-user configuration options.
I’ve got some 85’s here which I plan to give a test run soon just as a proof-of-concept. Assuming I can get STAR running easily I’ll pickup some ATtiny25s on my next order from wherever.
I tried to make something which reacts to an e-switch like a Zebralight, but I ran out of room really fast. Perhaps I’ll try implementing the Olight Baton interface first instead.
There really is no reason not to go to the 25 for more advanced UIs. They don't cost much more and are pin compatible. Even the 85 will work on the same pads if you fold the leads underneath, if you need more space. Once we get the port to the 25, the 45 and 85 are the same thing, and if you want to scale up to more outputs, just move up to the higher pin count version and keep the same firmware.
Looked at that pin layout…
It looks like only 3 outs on the 25-85… Unless you go with more pins. OC1B, OC0B, OC0A unless your using the same pin for 2 outs maybe?
That link is a good compare. It saws 6 pwm but wondering does that mean 3 outs with 2 per pin
Yes, I think you are correct. You can’t use the same pin for 2 outs, so you’re just stuck with only 3 on the 25/45/85. Even switching to a 20pin QFN package doesn’t fix it, most of the pins are NC (not connected). If you check the pinout in the datasheet it still gives only 3 different OC registers at once. http://www.atmel.com/Images/Atmel-2586-AVR-8-bit-Microcontroller-ATtiny25-ATtiny45-ATtiny85_Datasheet.pdf
To me it appears that the ATtiny24/44/84 provide four pins with different OC registers. Again, MLF/QFN is the only way to keep physical size under control. http://www.atmel.com/Images/doc8006.pdf
Another option to shove in even “larger” MCUs would be skipping QFN and moving directly to BGA. We don’t have to use all the pads for anything. I think we could almost completely ignore the inner 12 pins and focus on the outer 20. A 32-pin MCU in BGA is apparently 4x4mm, very small. Disclaimer - I’ve never worked with BGA! Since we’re reflowing anyway, I figure what’s the difference… 
Here are the megaAVR MCUs which have PicoPower, 1.8-5.5v, and 32 or less pins. Note that I think only the 168PA, 48PA, and ATmega88PA have BGA packages available. I think all of those provide a full 6 pins of hardware PWM.
As long as we’re talking about BGA here are the two PicoPower, 1.8-5.5v ATtiny parts which have small BGA packages available (3x3mm!):
BGA...man I would actually have to start being careful with my reflows! 
I would imagine those tiny pins are a little harder to flash after soldering, too. Can they even be flashed once they’re stuck to a PCB?
You would have to have header pins or something, which would destroy any size advantage. You would have to pull it off and reflow to reflash without headers on the board.
That ATtiny24a looks like it would work… Pins 5-8
http://www.digikey.com/product-detail/en/ATTINY24A-SSUR/ATTINY24A-SSURCT-ND/2774343
$1.45ea… Not too bad but 14 pins you might as well run two 13a! The 20 pin QFN might be small enough to do what I need
You understand why running two 13a’s in order to control one light is an undesireable thing, right? I can’t tell if you’re joking or not! :~
I think he was simply referring to the size of the MCU...it was supposed to be a joke.
hehe well edited the 20 qfn might work… I still dunno the size until bust out my mm ruler though…
EDIT
What if I just set the buck to high (it has memory). Disconnect the eswitch wire from it’s mcu. Now I have voltage monitoring already setup in the bucks stock driver. Now use the bucks mcu vcc to power the tiny24a also (not sure if that’s too much of a load on that circuit, otherwise I’d zener to B). So I ’d run the LED on the buck to the emitters +.
On the LED - (4 sets of gnd on that 4 color XML) coming from the emitter, those would go to 4 fets pwm controlled by the 24a. When the voltage gets low the buck would simply flash and eventually go out on it’s own.
… and you wouldn’t want to do that, as I understand it. A BGA is a one-shot deal unless you “reball” it. It comes with balls of solder stuck to the bottom, once they’re used up the solder must be removed and replaced with new balls. It’s a pain and there’s gear available to make it easier, commonly used in refurbishing electronics like phones, computers, and game consoles.
If you just want to be able to reprogram the chip then the lack of exposed pins is not a big deal. If you want to make it a weekly practice to reprogram the chip, yes, I imagine it would be a pain. We normally break out some pins as inputs, outputs, etc. ISP flashing (what we do) only requires 4 pins in addition to VCC & GND. I’m glancing at the Atmega-88PA for reference and in that case MISO and MOSI are both on PWM pins, so no problem there - we’ll want to break those out anyway, right? SCK is on PB5, an outside row pin with no peripherals. Reset is on PC6, another outside row pin. PB5 can be used as a star or whatever, PC6 would have to have a dedicated, unused pad I think. So not that bad IMO. For development purposes you can either use a larger PCB with an actual ISP header if desired.
Another option for programming may be to use a properly setup bootloader (eg no delay at boot, it would look for a condition before going into bootloader mode). You’d need an extra PCB with some support components (caps, I think) and you’d need VCC, GND, and 2 data pins broken out. http://www.obdev.at/products/vusb/index.html Some frequency stuff would also have to get worked out for a V-USB based bootloader.
IMO the bootloader business is pretty ambitious - I’m not suggesting that anyone work on it! I’m only mentioning it so that everyone knows this stuff exists.
It’s pretty small, smaller than the ATtiny13A-SSU’s package (what we use now). Wiring it up is different though, so it would require new PCB designs.
I’d have assumed it was a joke, but this isn’t the first post where fellfromtree mentioned using multiple MCUs to get enough PWM. I didn’t feel like writing out why it’s undesirable if it’s a joke.
Gotcha. I was wondering if you had lost your sense of sarcasm. 
Thanks, that’s a good summary.
I’m definitely a software person, not so much a hardware person… I enjoy doing the firmware-of-the-week thing (though, for convenience, development happens on a dedicated dev board). I like how it’s pretty standard these days to use big enough pins to easily reflash production hardware. More / smaller pins would significantly raise the barrier to entry for this hobby.
That’s why I like the idea of the attiny25. Same convenient size and interface, but more space and features to play with. Can even be used on existing boards in place of the tiny13. Or, for something with more I/O, the attiny84a-ssu might be nice… like, for a RGBW+ driver.
On second thought, maybe discussions like the ones above should be discussed somewhere else? Maybe this thread should be a discussion about single emitter lights and what variations of UI's people have come up with using STAR as a starting point, along with what new features can be added to make it even more useful.
I know there are other threads about multiple emitter (RGB) lights using the PIC. Maybe one can be created if people want to attempt to use an AVR instead. I for one won't be delving into that area, too complex for my tastes.