STAR Firmware by JonnyC - Source Code and Explanation

comfychair, I tested several variations and made a table, which might be of some assistance:

PhaseCorrect FastPWM
kHz CPU freq divider fuse CPU freq divider fuse
1.2 kHz 4.8 MHz :8 0x65
2.4 kHz 9.6 MHz :8 0x6a 4.8 MHz :8 0x65
4.7 kHz - - - 9.6 MHz :8 0x6a
9.4 kHz 4.8 MHz :1 0x75 - - -
19 kHz 9.6 MHz :1 0x7a 4.8 MHz :1 0x75

CPU freq is set by the fuse (Low Fuse bit 0 and 1) and “#define F_CPU” should be set accordingly.
PWM is set by “TCCR0A = 0x23”, where 0x23 is FastPWM and 0x21 is PhaseCorrectPWM
The divider is set by the fuse (Low Fuse, bit 4) and can be :1 or :8

And you can combine them all.
This way you can reach 19 kHz with Phase correct PWM and Fast PWM.

In addition you have the prescaler (“TCCR0B = 0x01”, where 0x01 gives :1; 0x02 gives :8 …) which is not the divider you set with the fuse. You can combine divider and prescaler and set them differently.

Both clicky firmwares (Star ontime and Star offtime) as of now use by default Fast PWM “TCCR0A = 0x23”. I can’t tell for the Star momentary firmware. Never used it, yet.
Both clicky firmwares are set to “#define F_CPU 4800000UL”, so I use fuse 0x75 (or change both) This fuse calculater is extremely handy to understand the fuse settings.

Star momentary also uses 0x23 by default.

Thanks HarleyQuin, You clarify my confusion of the prescaler and the divider.

Excellent info Harley!

I think Fast PWM vs Phase Correct confused the issue. For our purposes, it shouldn't matter which one we use, it's just a matter of what PWM frequency we want in the end. Fast PWM allows us to almost double the speed without any CPU of clock changes. I believe the whine we hear from switches and other components is strictly related to the PWM speed, not relative to whether there is phase shift in the signal (which doesn't happen at a constant PWM value either way).

So, both STAR clicky & momentary are using 4.8MHz CPU clock, and 19kHz fast PWM, when using a lfuse of 0x75.

Anybody else tested fast PWM on the FET drivers, specifically the momentary version? It seems to do everything properly for me. I think originally the momentary firmwares were all using phase correct PWM because they were being used on 7135 drivers (master/slave stuff in SRKs, replacing the original driver), and the 7135s don't turn off completely in the 0% mode when using fast PWM.

I have two new BLF-SRK drivers assembled (using only the bare minimum parts, so no inductor/flyback diode/capacitor), planning to test them both side by side, one using the default fast PWM and the other changed to phase correct, just to see what they do different in actual use.

Sorry, can’t say anything to the FET drivers, following with much interest, though.

Concerning the PWM-whine: I tried all these frequencies in hope for finding one I like better. I had high hopes for the 9.4 kHz one, but it also whines. The lower frequencies do whine as well, as was expected. I can confirm that the whine does occur in the driver and in the switch.

I tried an even lower freq by using divider “:8” and prescaler “:8” (I think that gave ~150 Hz) just to have tried it… doesn’t look too good.

Both 19 kHz variants, PhaseCorrectPWM or FastPWM, are silent - at least to my ear. The high frequency has the disadvantage of dropping out of regulation early (especially in mid and low modes), as HKJ has stated when testing the Qlite driver. He measured 16.5 kHz, by the way.

But when I have to choose between the devil and the deep blue sea, I prefer my driver to be silent.

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!