STAR Firmware by JonnyC - Source Code and Explanation

Awesome work Jonny. I still have to check out your changes Toy. But I came to a realization last night sleep lol

You don’t even need boards with the tiny13a. If you can modify the output on a buck driver you just need to glue 2 resistors (4 total) top and bottom of the tiny and wire it up to the existing FET and vcc to the existing mcu. Disconnect the eswitch from the existing mcu and cut the gate, wire your new pwm in. You would then have voltage monitoring (not sure this even works on a buck because it’s series cells- probably better to stick protected cells) from the divider and full control of the fet.

Trying to find the cheapest solution to having a ~6a buck with modes on the Y3 :slight_smile: I’ll have to try all this new stuff out when the next light gets here- takes awhile to get here…

You could even add in a smaller fet for a second out on a lower amp light but it would add another 2 resistors, and you would have to be careful in programming so one is closed while the other is on. I think can do dual outputs (only one out at a time) like that for next to nothing and still have a 2-3s light. Is there a tinyavr compatible chip that does 4 out? Not sure if fitting 2 tinys in would fit yet for something like that 4 color XML. Or do we have to invest in the PIC equipment Cereal uses.

I think this is a great place to discuss derivatives. I'm assuming there are people out there that downloaded STAR and used it in stock form by configuring the options, even though the majority of the discussion here is about custom, one-off programs. I see this thread as just a continuation of Tido's original thread with a more configurable, perhaps easier to work with codebase to start from.

And yeah, the idea behind "STAR" was just that you could solder different stars for different options (ala NLITE), but the more features are added the less purposeful that feature is since the user will need to enable/disable so many options at compile time that they don't need the solderable ability. But I'll keep the name "STAR" just for consistency.

I could be the only one who’s having trouble with your posts, but I’d really appreciate it if you put some more effort into making your posts easy to read. They seem to be very stream-of-consciousness or something.

I’ll try to reply to what you wrote, but what you wrote may not be what you meant.

IN ORDER:

  • You’re correct about not needing a PCB for the ATtiny13A - it’s just a lot easier that way. What you’re referring to is often called “dead bug” style wiring. As an example, here’s a picture of ImA4Wheelr doing it in post #176 of his HX-1175b thread.
  • Why do you say 4 resistors though? You need 2 for a voltage divider and… what? What are the other two resistors for?
  • Correct, you’ll generally use the VCC intended for the original MCU, regardless of whether you’re using dead-bug wiring or a child-PCB.
  • You will not cut the “gate” signal. That term has a specific meaning and the gate signal / trace does not need to be modified for any of this. Instead you would modify the trace for the PWM signal.
  • RE: the italicized stuff about voltage monitoring. Voltage monitoring will work fine as long as you choose appropriate resistor values.
  • For buck drivers you do not directly control the FET, the buck controller does that. The MCU simply feeds the buck controller a PWM signal. The buck controller establishes a duty cycle where it turns the FET off part of the time - the PWM signal from the MCU tells the buck controller how much additional time it should turn the FET off for.
  • Adding an additional, separately controlled [smaller] FET does not make sense with a buck controller. IMO it doesn’t make much sense for a DD driver either. Remember, the FET is not there to limit the current - it’s there to be controlled by the buck controller. A FET with more on-resistance will simply lower the efficiency of the buck circuit, not lower the output current!
  • Good news! :wink: There is plenty of AVR hardware out there which can do whatever your heart desires. The ATtiny25/45/85 all seem to have 6 PWM channels. They’ve also got other nice stuff, like additional flash space and a temp sensor IIRC. The ATtiny25 is available in the exact same package / form factor as the ATtiny13A-SSU we currently use. (The 45/85 are both very slightly larger.) We use 150mil or 8S1, the larger chips are 208mil or 8S2. Frankly I’m not entirely sure what the limit on actually using all those PWM channels simultaneously is. There are only 2 timers and our use case may [probably does] prevent them both from being used for PWM. If the Tiny25/45/85 can’t do 4x simultaneously in our application it I’m sure another AVR product can. For anything beyond the ATtiny25 you’ll be forced to switch to a QFN style package. EDIT: hmmm.

My advice is to make sure you’ve got both feet on the ground with your understanding of a buck driver. Read some stuff on the internet, look for simplified explanations. An animation of the various states used by a buck driver is probably useful. Once you understand how a buck driver operates you’ll see the mechanism for limiting current. This will make it clear why adding an additional FET in the way you described is not a good idea.

Don’t be discouraged, keep working on it!

I know I know :slight_smile: Thanks for posting, I was on my way to blowing something up tonight… I just got all my parts in from digikey and dan sent a couple of old dd boards to play with (should thank him publicly for doing that… you guys are really cool). Let me research a bit more and when the light comes in- I’ll post a build on it… Instead of filling up jonnys thread.

I do have a bad train of thought anymore… I can’t blame it on anyone, except maybe my wifes trying to poison me! naw… it is what it is unfortunately :disguised_face:

Don’t sweat it, but please do proofread! Write, take a break, then read/re-read.

and LOL @ wife excuse :slight_smile:

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… :wink: 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 :wink: 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.