STAR Firmware by JonnyC - Source Code and Explanation

From another thread...

Now that’s a looker, two to be precise…

I think I posted about this in another thread but I can't remember which! I haven't tried it lately but when I was first testing out the STAR momentary with an FET it worked just fine with fast PWM but the low mode was about twice as bright as what I get with phase correct. I haven't tried it with the resistor in place to see what that does, although the 200 ohm resistor I'm using now does seem like it may make the lower modes slightly lower than without it.

Both those SRK drivers are using no extra resistors anywhere, tested with only the Nanjg parts plus the FET. (I added inductors and the big diode to both before installing them... oh, and also went back and flashed the noisy one with the quiet FW)

I don't see STAR momentary posted anymore, anywhere? Thought JonnyC find an issue/bug, maybe posted here, but Richard's OP doesn't have the link anymore, and JC's website doesn't have it. Any ideas? Got to add strobe to this driver and just want to make sure I got any possible bug fixes.

???

Ohh - was wondering if this SRK driver is the STAR Momentary driver... Just a confusing name I guess, or STAR_mom was confusing... hhmmm...

Would be interesting to see what JC comes up with for dual switch support. I have ideas, but no time of course... Adding strobe to STAR_mom is a little challenge. Have to convert what was in luxdrv as a forever loop to a state machine. Shouldn't be too bad, but no way am I as efficient as the doc, but still have plenty of program space left, so can afford to be somewhat wasteful.

Update: Actually it's easier than I thought. In the while(1) loop for strobe, all you have to do is add a check if the user changed the mode via a click, and if so, exit the while (1) loop. Bottom Line: 2 lines of code to add, add a variable "mypwm", and use a special value of PWM to indicate strobe (254 for example).

Tom, I also have strobe working in the normal STAR now with the same trick. I had to pick Jon's brain a bit about why the modes didn't switch right until he pointed out that I had 254 defined twice!

if (modes[mode_idx]==254) {

while (1) {

PWM_LVL = 255;

_delay_ms(20);

PWM_LVL=0;

_delay_ms(60);

}

} else {

PWM_LVL = modes[mode_idx];

}

Is that the hidden strobe with a long button press? Or another “fixed” mode…I would LOVE hidden strobe, I really hate having to go thru strobe to get back to the start of the modes

WarHawk, Richard included that strobe in the original STAR program just as one of the modes you can cycle through.

I know it's really confusing, but Richard referred to the momentary program as STAR momentary, while I identify it on my website as SRK - No Ramp. I refer to it as "no ramp" because I was working on a ramping version initially and was failing, then Richard brought up Werner's UI, which was easier to implement, and I sent that off to him. I really should just change how I refer to it. STAR, STAR_off_time, STAR_momentary, STAR_dual_switch, STAR_dual_switch_off_time....ha.

Yup Tom, you got it with the strobe mode.

I wanted to be able to double tap and triple tap to access a hidden mode, but that was in my ramping program and I just couldn't find the room for the life of me. That program still pisses me off, especially when I see that DrJones is able to fit that and 20 other features into the same program space. Maybe it could be added to the momentary program.

I was asking about STAR V1.1 clicky, not momentary

I don’t see the strobe mode in the code…unless it’s a later revision…I will go check

Maybe we should all start refering to them like you do we don’t get confused

The one DrJones did I believe is a ATtiny85-SU (maybe the tiny25 [that holds 2k])…same as the Attiny13A-ssu (slightly larger size though)…but with 8k of flash…so that’s how he did it :wink:

The 85 comes in SU size, the 25 only one that comes in the SSU .154” size

RMM made the change himself. I'll get his change integrated into my copy.

My quick&dirty plan was to add strobe as the last mode, so a long click is strobe from OFF, so high is no longer directly accessible.

It would be real easy to do a long press gets you to a hidden strobe instead of going backwards through the modes, but having both forward/reverse modes + hidden strobe would be a bit more tricky although I think that's possible as well.

I don't know what I'm doing, I really am just looking at other people's examples of code, modifying them, and googling when I get stuck. After my various attempts and googling don't work, then I just e-mail JonnyC and he fixes it for me!

I was gonna keep long click to going backwards, just that the 1st mode would be strobe and not high. Coming up with a "hidden method" is a little challenging the way I have it implemented. Adding a double-click for example means you have to slow down single clicks - kind of defeating the fast response the UI has now. I'm not too crazy bout double-click UI's for that reason - I expect 2 single clicks to be quick, but then they get mis-interpreted as a double-click.

You could do a long-long extra long click to get to strobe from OFF - maybe that's not so bad? Hhhmmm, I'm kind of liking that. I've sped up the responsiveness of a long click any way, so, holding a little longer to get to a strobe mode may be pretty good.

I don't know how the code works to do such things, but is there a way to have it check for when the long press is released instead of just how long it's held? Like, if after 0.1 second the button is still pressed it is not a short click, and at 0.3 seconds check again and if the button is released, count it as a regular long press and step down one mode. If it's still pressed at 0.3 seconds treat it as a request for the strobe (or other 'hidden' mode, or an instant-off, or whatever function).

Yup, we could do that. Only odd thing is then is that if you want to step back a mode, you don't really know when to release the switch because it won't change the mode until you release it.

I think a quick double tap would be a better way to go.

WarHawk-AVG: "The one DrJones did I believe is a ATtiny85-SU (maybe the tiny25 [that holds 2k])…same as the Attiny13A-ssu (slightly larger size though)…but with 8k of flash…so that’s how he did it"

No, only my new RGBW driver (and the F6 driver I'm working on) uses the ATtiny85, my other firmwares are for the unmodified NANJG, i.e. ATtiny13(A).

I did a few custom static builds for drivers that don’t have stars (the 101-AK-A1 and AK47A driver [which does have stars])

I am working on a custom UltraFire 602C build pushing a XP-G2 and a 15 degree TIR (testing 2 different TIR’s) at 1400mA and like the hi>lo without memory so when you click it on, it’s going wide open but will throttle back after a little bit as to not overheat (not much meat to the pill so it gets hot FAST!)

This way they do in “stock form” without soldered stars rather than soldering to make them do what I want them to do

I also lowered the low power alert and shutdown voltages by 5 clicks (I think weaker cheaper batteries might suffer from voltage sag on higher current drivers), thus the LVE (Low Voltage Edit)

https://www.dropbox.com/sh/k5oilslyegbrdnl/Ky0Tm9cAC8

I’ve got a question for you smart guys, I have an old stripped down nitecore D11 body with no electronics, is there any way (STAR or any other FW) to operate it using any form of ATTiny13A controlled board without ditching the piston drive?