STAR Firmware by JonnyC - Source Code and Explanation

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.

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....

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

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.

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();

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.

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:

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…

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.

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.

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

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?

This is what i flashed into my driver.

Thanks

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

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

Thanks for all the help

  • 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.

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!

I think you’re taking my comments the wrong way JonnyC. [EDIT: or I’m taking yours the wrong way :wink: ] I actually thought you’d left that define in place on purpose, so a lot of what I said goes away by just commenting that out.

I still think that the current STAR is much, much harder for neophytes to understand than earlier versions were. That’s an unavoidable problem, not something to complain about: you did a great job adding the features and the firmware is now harder to understand because it is able to do more. Setup is also harder to understand because there’s more to control. Unfortunately we need a several FAQs/guides around here and nobody’s volunteering to write them, myself included. <shrug>

Just a side note… I’m thinking of changing the thresholds for battery check modes to more accurately reflect capacity instead of voltage. Currently it does one blink for every 0.3V above 3.0V. Most of the capacity is toward the top of the voltage range though, so this doesn’t map well to capacity.

Instead, I’m thinking of setting the thresholds to 3.0V, 3.5V (maybe 3.6), 3.8V, 4.0V, and 4.2V. Do you think these would get somewhere near 25% capacity for each blink?

Edit: I’m basically talking about fitting it better to curves like hkj measured, but different batteries have rather different discharge curves so I’m looking for a happy medium:

ToyKeeper: that chart gets a little busy, maybe the signal to noise ratio is high. Let’s see, if we eliminate the lowest 3 lines (Yellow/Blue/Red - I think that’s an old IMR cell (AW IMR1600), an old Redilast 2200, and either an old Redilast 2600 or old Solarforce 2400???) that cleans it up a lot. Next if we eliminate the highest line, the uncommon-and-impossible-to-account-for-with-this-system (IMO) 4.35v cell, we clean it up further.

Now most lines stay together until around 3.70 or 3.75 volts. Around 3.7v seems to me to be the lowest voltage where we can assume that none of the graphed cells (other than the excluded 4) are on the wrong side of their discharge “knee”.

That said, discharge current may not be 0.2A, so there’s a lot to think about in that area. Basically we know that voltage depresses a lot under load, but here are two links to SilverFox and HKJ threads which are at least mildly related:

HKJ demonstrates approximately a 10minute recovery from (for example) 3.6v under 1A load to 3.7v under no-load. Recovery time seems to be similar for 3A, just with more voltage depression: about double I think. So in my example we’d be at 3.5v under load and it would take us 10min or so to rebound to 3.7v no-load.

Please also scroll down to the “Tables” section at the bottom of HKJ’s OP in that thread.

I guess what I’m getting at is that the user is going to have to have a ‘fair’ amount of knowledge to interpret the battery measurement output blinks. Also I’m probably saying that fairly high output resolution is necessary.

OTOH looking at HKJ’s data… if the output was just a binary >3.8v vs <3.8v indicator… that might be both useful and easy to understand? HKJ also makes some great observations in that post: “In the above curves, notice the difference in volts between the 10s and 1 hour trace, this is always below 0.1 volt, i.e. if measuring 10 seconds after load is removed, the error is not more than one 0.1 volt step wrong. Waiting two minutes makes the voltage close to the one hour value, especially at 3A load this wait will improve the precision.”