STAR Firmware by JonnyC - Source Code and Explanation

Nice.

The short explanation: “if (1)” means “do this”.

The long explanation: “if” expressions check the terms you put between the (). If those terms are true, the result passed back is 1. So by replacing the terms with “1” I’ve sort of passed the result “true” to an “if” check.
The if(1) line itself is not needed, but in order to remove it you need to remove more stuff. For example, this is what it looks like now:

if (1) {
-do this code
}
else {
-code here will never be executed because if (1) never fails
}

You can make it look like this:

-do this code

If you remove the if check you have to remove the {} characters and else statement along with all the code in that else statement.

FWIW, the step-down may allow the light to run for a significantly longer time, since voltage often recovers after decreasing amperage. It also acts as a way of getting more warning before shut-off. But if you don’t like it, you don’t like it. :slight_smile:

BTW, did anyone try simply setting the LOW and CRIT values to the same number? It seems like a straightforward way to do it (but would probably not disable step-down).

Thanks all.

Toy I did try this and unfortunately the LOW always grabbed before the CRIT. Meaning it would switch to a lower level.

All of the tests I had successfully run for the low voltage shut off were done on Turbo that defaulted to Turbo Low.

I’m now running the tests again and the low voltage shut off is not working.

Should ADC_CRIT work in all modes?

I’m not sure… I haven’t tested STAR extensively. In my mods I usually cut out that part of the code because it takes too much space, and replace it with something smaller / simpler. The one I’ve tested the most is BLF-A6, since it’ll be factory-installed and I want to make damn sure it works correctly. It still needs a somewhat unfortunate amount of calibration for each different model of driver it runs on though.

If you have a bench power supply, it greatly helps testing. If not, a LiFePo4 cell or even a 3V CR123 or CR2032 cell can work for LVP tests. It can also be useful to temporarily bump up the LOW/CRIT levels to make it trigger at a higher voltage, just to make sure it works, and then put them back down where they should be.

The code I’m looking at should work, but I’m looking at standard star v1.1. I haven’t touched it for a long time though, I use my own firmware and it does everything differently.

Did you try my suggestion?
It removes all the stepping down part.

The cleanest would be to remove everything in the while(1) except shutdown code, and sleep code after if there is any:

while(1) {

if (LowVoltage(ADC_CRIT)) {
Shut down code…
}

Sleep code (if any)

}

If you can post your code somewhere easy to read I can give a go at a quick edit, but I can’t test it as I don’t have any ATtiny13A drivers anymore.

Odd - I have not yet tried your code but will today. I’ll report back.

Mike - Thanks for the suggestion. Let me see how Odd’s code works and I’ll try and find a way to post my code if it doesn’t work out.

Thanks all for the help.

How much work would it be to add dual-pwm to the dual-switch firmware?

Odd - so far so good on this. I’ll keep testing it and report back.

Odd - so far so good on the code. Thanks

Hmm… good question. I didn’t realize there was still a flavor of STAR without dual PWM support.

I’m not sure how much work it would be. I just checked for updates upstream, hoping it had already been done, and there haven’t been any since January. The methods used in other versions of STAR have varied, and the dual switch driver isn’t quite like any other. So, it would be more than just a simple merge or a cut-and-paste job. I think there’s at least room to add it though; I get 796 bytes when I compile STAR_dual_switch.

TK, would it be easier to add mode memory to the STAR momentary FW? I feel like that’s all it would take to make it work as a dual-switch FW, and it already has dual-pwm

(of course, I think we’d all love it if you were to make your own dual-switch FW :wink: Soft-toggling memory would be really nice on a dual switch light, and better control of the second channel would be welcome as well)

You know, I’m not sure what the easiest option would be.

There should be room to add a bit of eeprom save/restore code to STAR_momentary, but I doubt there would be room to add much more.

The momentary switch code is significantly more complicated than clicky switch code and uses more room, so it’s kind of hard to fit both. However, I haven’t seriously tried so I’m not sure how hard it is.

If I can do it without so many interrupt handlers, maybe I can save enough room to fit both plus extras, but I get the feeling I’ll have to basically start from scratch in order to make any significant progress.

Question: Is there a way to have STAR dual-switch recognize when the e-switch is held while power is turned on? So that moon or strobe is accessible from off by holding the mode switch while the main power switch is clicked? Perhaps by checking e-switch status once outside of the main loop so it only checks it when power is first applied?

Sure, it should be very possible to have a different response for “power connected while switch is up” versus “power connected while switch is down”. I don’t think anyone has tried it, but it should be easy.

I haven’t been doing e-switch stuff lately, but have been itching to start on a FET+1 e-switch project. I definitely won’t have time for like a month though, and would need some extra parts.

If only we all had more time, right? :slight_smile:

I need to increase my own understanding of how the code actually functions. It’s probably my weakest point.

I tried combining my e-switch version with my NOINIT (power switch) in order to get full functionality on both switch's, but ran out of code space. I just ordered a few ATTiny45's - they have 4 * code and data space. There's been some successful porting effort goin on, so hoping I can get these up and running.

Update: Mission Accomplished! Got it working now on a ATtiny45. Some details here: https://budgetlightforum.com/t/-/34900, post #115.

Awesome. :slight_smile:

I’m hoping I can fit both by reducing the use of interrupts and volatile variables in the e-switch code. I’ll probably still need 2K to fit both the A6 code and the smooth ramping code though.