STAR Firmware by JonnyC - Source Code and Explanation

Flashlight Modding and DIY Parts
752

Thanks wight for taking the time to explain.

I've spent a few hours with this today, but I'm not quite there yet....

I was certain it was stepping down visually, but to be sure, I charged my test cell back up to about 3.4v & hooked up an ammeter in series;

Starts out at 0.6A, ---> 3*flash/stepdown to 0.3A, then ~6 mins later, at 0.12A, another 3*flash/stepdown to 0.05A, then a few seconds later, another 3*flashes, & back up to 0.14A, then 3*flash & down to 0.02A ......./end of test...

Yep, just like you described above.

-

I replaced PWM_LVL = modes[0]; with PWM_LVL = STEPDOWN_MINIMUM , but we still don't see the Critical routine.

It now steps down as before, but doesn't jump back up & start over, just continues with the 3 flashes, maintaining the lowest current, in a loop.

Without a Babel fish, I'm still unable to properly follow what's happening to some of the variables :(

I took a couple of wild stabs ; PWM_LVL = STEPDOWN_MINIMUM -1 which done nothing, & also tried removing the line under that mode_idx = 0; which again achieved nothing.


753

Hmm. Please go ahead and post up your full code in some unmolested way (upload a TXT file some where or use Pastbin or a similar website). Some sites like pastebin also have a highlighter, which is nice. :slight_smile:

754

Here’s the latest test code, minus the couple of “stabs” I took at it.

:beer:

755

It appears that our current problem is "wrapping" the unsigned variable 'modes_idx' from zero up to it's maximum value. With what I think we have currently I guess the problem manifests immediately after the first stepdown. Here is the problem section:

// See if we should change the current mode level if we've gone under the current mode.
if (PWM_LVL < modes[mode_idx]) {
 // Lower our recorded mode
 mode_idx--;
 }

Do you see the problem? Of course the conditional is true, PWM_LVL is now below modes[0]. So we subtract 1 from mode_idx. Since it's already zero and it's unsigned (can't be negative), the value wraps to the maximum value, I guess that's 255? After that we probably subtract one from that value every 3 seconds or so... so eventually maybe "if (mode_idx == 0 && PWM_LVL <= modes[mode_idx])" will be true, but not any time soon (13 minutes maybe?).

I think deleting that whole section is fine.

756

That's the problem on my end; I don't know enough/forgotten too much to follow what's going on.

I taught myself Basic on a CPC464 by reading through the user manual - even got to the stage where I was able to write up some games to give to friends to try out..... but that was over 30 years ago now....

...back to now, & I've re-flashed with the updated code, so far, so good - just waiting for the battery to run down....

757

Oops, I meant to include this link in my post: c - Is unsigned integer subtraction defined behavior? - Stack Overflow

758

I had to re-run the test, as I was interrupted…

It now does the stepdown sequence four times, then gives the Critical warning(10 flashes), but does not power down???

Current code.

759

Well, I can't figure out why the power-down sequence isn't working....

We're reaching the critical voltage routine, getting the 10 flashes, but no power-down?

while (!low_voltage(ADC_CRIT));

i = 0;
while (i++<10) {
PWM_LVL = 0;
_delay_ms(250);
PWM_LVL = modes[0];
_delay_ms(500);
}
// Turn off the light
PWM_LVL = 0;
// Disable WDT so it doesn't wake us up
WDT_off();
// Power down as many components as possible
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_mode();

760

Come to think of it, I saw the same behavior recently in what I think was an unmodified firmware. I actually just assumed I’d made a mistake in my observing my test. I’m not sure what the problem is.

761

Back to plan “A”…

I ended up commenting out the Next Mode routine, as suggested by Mike C. :beer:

Works fine, steps down a few times before hitting Critical voltage, then shuts down.

Thanks to everyone who gave some input, & especially wight for persevering with me.

Oh, & thanks to JonnyC for letting his baby out into the wild! :bigsmile:

762

You’re welcome, although my help never got you very far.

I’d still really like to know where we went wrong. The code looks OK to me…

763

I have finally updated the feature lists of the different firmwares and changed it so that it now resides on my GitHub page...

I'll message Richard to update the link in the OP.

Sorry that version numbering is off, and that I did a horrible job of managing my Git repository so it makes downloading previous versions more difficult. However, I believe that all of my feature changes so far have been additive, and each feature (for the most part) can be commented out. Don't want dual-PWM? Just comment it out at the top. No need to find a previous version of the code.

764

I’m pretty sure we almost had it. I might re-visit this during my holidays in a few weeks, but for now what I needed has been achieved.

765

Hey guys, need some help here. Yesterday i successfully flashed my 1st nanjg driver with the standard STAR On-time memory v1.1 for clicky switch but my mode cycle is a bit weird. it goes like L-M-T-off-L-M-T-off…how do i remove the ‘off’ from the cycle to just L-M-T-L-M-T? i have test the turbo stepdown and it works accordingly. Thanks

766

There should be no off in the cycle. My guess is that you just have a mode defined that is too low for the light to turn on. Could you please share your C file with us?

767

This is what i flashed into my driver.

Thanks

768

That appears to be a project file, not the source file.

769

sorry guys for beginning a noob here. i think this should be the .c file

Thanks for all the help

770
  • Looking at RolandF’s problem, my first assumption is what RMM mentioned: a low mode isn’t lighting up the LED. (EDIT: but that’s incorrect, based on the now-posted code.)
  • The stock firmware has DUAL_PWM_START turned on, so there is no star to disable Moon mode. MODE_MOON must be commented out in order to prevent Moon mode from being in the modes list.
  • Looking at the posted code, MODE_MOON is defined and so is DUAL_PWM_START. Since the Moon mode value is below dual PWM start, it’s outputted on Star2 rather than the normal PWM pin (a dual PWM feature). Even if ‘3’ was high enough to light up an LED with a 7135 (I don’t think it is) there still wouldn’t be any light because Star2 is probably not hooked up to anything on RolandF’s driver. To fix the problem DUAL_PWM_START needs to be commented out.
  • I’m having a lot of trouble parsing the #ifdef and #ifndef statements pertaining to moon mode in the ‘// Load up the modes based on stars’ section. Either I need someone to hold my hand or the code is broken? I re-read it very carefully and I understand it now. It’s definitely very compact and I now see that it’s written that way to avoid repetitive sections of source. That said, the code below is easier for me to understand and I assume (?) that it compiles to the same size.

/* Enable/disable moon mode based on STAR2 if dual-pwm is turned off & MODE_MOON is defined */
#ifndef DUAL_PWM_START 
#ifdef MODE_MOON
if ((PINB & (1 << STAR2_PIN)) == 0 ) {
modes[mode_cnt] = MODE_MOON;
}
#endif
#endif

/* Always enable moon mode if dual-pwm is turned on & MODE_MOON is defined */
#ifdef DUAL_PWM_START
#ifdef MODE_MOON
modes[mode_cnt] = MODE_MOON;
#endif
#endif

IMO at the current level of complexity in STAR users need a setup guide. JonnyC has stated that the point of STAR is to be able to change a few defines and then compile without understanding the code. In order for users to successfully do this they must understand what the defines achieve and how the defines interact with one another. DUAL_PWM_START automatically enabling Moon mode is a great example: previous to the dual-pwm feature Moon was “off” by default, now it’s “on” by default.

771

My bad Roland, I pushed changes to STAR, STAR_off_time, and STAR_momentary that disables these advanced features so it's easier to configure for a basic driver. Just download the latest release from the link in my signature or the OP in this thread. All of the requests for features come from advanced users, so I just made a mistake in keeping the configuration setup for the last test I did (which was testing all of the added features). And really the only feedback I get is from people looking to modify the code themselves to add their own features.

If someone else wants to write up a configuration guide, please feel free! And if someone wants to take over the development of these STAR programs and do a better job of documentation, go right ahead!