STAR Firmware by JonnyC - Source Code and Explanation

1335 posts / 0 new
Last post
zeremefico
zeremefico's picture
Offline
Last seen: 44 min 45 sec ago
Joined: 03/27/2012 - 02:44
Posts: 1380
Location: Greece

Hi, I really like a feature, rmm’s tk61 super driver has, the momentary turbo from off mode. It works until you leave the long press. Richard gave me some tips on how I can add this to star firmware but my skills dont let me to accomplise that.
Can anyone assist me on that?

₪₪₪₪ ΟΥΔΕΝ ΚΡΥΠΤΟΝ ΥΠΟ ΤΟΝ ΗΛΙΟ ₪₪₪₪

My YouTube channel

Flashlights & edc gear

K40M F16

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 weeks 3 days ago
Joined: 01/12/2013 - 14:40
Posts: 10655
Location: (469219) 2016 HO3

Adding momentary turbo from off shouldn’t be terribly difficult, but it has a cost that you lose the ability to map long-press-from-off to something else.

I added it to my todo list, but I’m not sure when it’ll happen.

For now, there are a couple of similar options:

  • Long press from off goes to turbo, release and short-press to turn it off. (in one variant, holding the initial press longer will ramp down) Short press from off goes to the lowest mode (repeat to increase brightness). Turn off by raising or lowering brightness past the maximum level. One version also has a battery check mode on short-then-long-from-off.
  • Long press from off goes to moon, short press goes to last-used level, double click from off goes to turbo. While on, short press turns the light off, long press and hold ramps brightness (smoothly or in steps). Extra-long press from off toggles soft lockout on one version of this UI.

Would either of those work? There’s basically STAR momentary, my version of STAR momentary, a smooth ramping UI, or a stepped ramping UI (like an Olight Baton).

zeremefico
zeremefico's picture
Offline
Last seen: 44 min 45 sec ago
Joined: 03/27/2012 - 02:44
Posts: 1380
Location: Greece

Thanks TK, will I find these in your repository?

₪₪₪₪ ΟΥΔΕΝ ΚΡΥΠΤΟΝ ΥΠΟ ΤΟΝ ΗΛΙΟ ₪₪₪₪

My YouTube channel

Flashlights & edc gear

K40M F16

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 weeks 3 days ago
Joined: 01/12/2013 - 14:40
Posts: 10655
Location: (469219) 2016 HO3

zeremefico wrote:
Thanks TK, will I find these in your repository?

Yes. STAR itself is in the JonnyC directory, and the others are all under ToyKeeper/Ferrero_Rocher/ .

I still need to make the red/green battery indicator bits easy to turn off at compile time; these were designed for a very specific driver. They work on other attiny13-based e-switch drivers though. The most likely thing to need changing is the PWM levels, since that’s very hardware-dependent. It’s calibrated for a FET by default.

Edit: Actually, looking at the code today, I have lots of misc cleanup to do… and need to apply upgrades from some of the files to the other files. I mostly stopped after getting things working, and didn’t finish the “polish” to make it really clean for others to use.

Edit 2: I just did some significant cleanup, mostly merging code between the three Ferrero Rocher firmwares to make them more consistent. It should be significantly easier to turn off the red/green indicators now, at least. Also freed up more space on two of the three.

seepeli
Offline
Last seen: 5 years 6 months ago
Joined: 11/20/2014 - 16:37
Posts: 19
Location: Finland

Hello all!
I really like the Star (On-Time Memory) program. It is simple and functional. However, I would like to see one additional feature: the ability to reduce the mods in the normal and reverse cycle. I mean the following:
Short press (from off) (ML), Low, Med, Off
Long press (from off) Turbo, High, (Med), Off
In this way I do not need to go through unnecessary mods.
Is this addition difficult to accomplish?

RMM
RMM's picture
Offline
Last seen: 1 year 5 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

seepeli wrote:
Hello all! I really like the Star (On-Time Memory) program. It is simple and functional. However, I would like to see one additional feature: the ability to reduce the mods in the normal and reverse cycle. I mean the following: Short press (from off) (ML), Low, Med, Off Long press (from off) Turbo, High, (Med), Off In this way I do not need to go through unnecessary mods. Is this addition difficult to accomplish?

I think this is impossible.  Long/short press functionality while on has been implemented by a member here in STAR off-time, but I believe it is impossible from an off state.  

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

seepeli
Offline
Last seen: 5 years 6 months ago
Joined: 11/20/2014 - 16:37
Posts: 19
Location: Finland

I meant, of course “Star momentary driver” program.
I apologize for the error

RMM
RMM's picture
Offline
Last seen: 1 year 5 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

seepeli wrote:
I meant, of course "Star momentary driver" program. I apologize for the error

No worries!  Unless I am misunderstanding what you want to do, the momentary program already does have that functionality. 

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

seepeli
Offline
Last seen: 5 years 6 months ago
Joined: 11/20/2014 - 16:37
Posts: 19
Location: Finland

RMM wrote:

No worries!  Unless I am misunderstanding what you want to do, the momentary program already does have that functionality. 


Function may be already in the program, but I do not find it there. So, I just may have to study more about the program.
RMM
RMM's picture
Offline
Last seen: 1 year 5 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

seepeli wrote:
RMM wrote:

No worries!  Unless I am misunderstanding what you want to do, the momentary program already does have that functionality. 

Function may be already in the program, but I do not find it there. So, I just may have to study more about the program.

It is already there by default.  You can change the amount of time that constitutes a long press by changing the LONG_PRESS_DUR value.  32 ticks (0.016 seconds each tick) is the default, but I prefer 22 to 24 ticks.

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 weeks 3 days ago
Joined: 01/12/2013 - 14:40
Posts: 10655
Location: (469219) 2016 HO3

seepeli wrote:
Hello all!
I really like the Star (On-Time Memory) program. It is simple and functional. However, I would like to see one additional feature: the ability to reduce the mods in the normal and reverse cycle. I mean the following:
Short press (from off) (ML), Low, Med, Off
Long press (from off) Turbo, High, (Med), Off
In this way I do not need to go through unnecessary mods.
Is this addition difficult to accomplish?

I meant, of course “Star momentary driver” program.
I apologize for the error

That should be do-able with only small changes.

First, you’d want to put a 0 in the middle of the mode sequence. Second, you’d need to add a line in the main loop which sets the mode index to zero when the PWM level is zero. This way, it would reset to the default “off” state whenever you reach that level.

Using the stock STAR_momentary, you may also need to redefine the number and value of output levels, disable alt PWM, and possibly disable the hidden momentary mode.

Does this make sense?

seepeli
Offline
Last seen: 5 years 6 months ago
Joined: 11/20/2014 - 16:37
Posts: 19
Location: Finland

Yes, it does make sense!
Now I just need to focus on programming.
Thank you for your help.

FmC
FmC's picture
Offline
Last seen: 5 months 1 week ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU

A couple of members have recently sought a “1 mode” driver/firmware for various reasons.

Using STAR as a base, it’s easy enough for people with limited code skills such as myself to comment out all modes bar 255, but I found that this method doesn’t play nice with the low voltage warning/step down, as there is no lower mode to step down to.

If I keep a 2nd lower mode in there, the code works as it should, but there will be instances where the lower mode can be inadvertently changed to, even when set to come on in High mode every time.

I want to keep the low voltage step down routine, so “Mr. Muggles” sees the light has dimmed noticeably, & figures that it’s time to change the battery.

I’m thinking that the best solution would be to disable the part of the code that looks for the ‘quick-click’ for the mode change, or just shorten that time so as it’s not possible to click into the lower mode.

Could one of the code Guru’s help me out with what needs to be changed – I’ve tried to follow it through, but can’t put my finger on it.

Cheers Smile

Mike C
Mike C's picture
Offline
Last seen: 6 hours 20 min ago
Joined: 01/22/2014 - 08:03
Posts: 2568
Location: Sweden

I guess easiest would be to simply comment out the “next_mode()” call from the mode_idx&0×10 check (or comment out the entire mode_idx&0×10 check routine), disable mode memory and have mode direction high to low.

wight
Offline
Last seen: 1 year 4 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

I assume we are talking about the clicky firmwares.

For the clicky firmwares I think the most straightforward way to handle it is to set the minimum stepdown brightness manually. This line determines the lowest PWM level the driver will stepdown to:

if ((PWM_LVL >> 1) < modes0) {
Note that it’s based on modes [0], the first mode, but in a single mode driver that’s the only mode we have! Instead we just set it like this:
if ((PWM_LVL >> 1) < 30) {
where “30” is the lowest level we want it to step down to in this case. Assuming the single-mode was set to 255, stepdown pattern would look like this:
255, 128, 64, 32, 30, 30, 30, etc, …, critical shutdown

If you’re building a lot of single mode drivers and plan to change the minimum stepdown level a lot you may use a define for that value, just add one at the top like:

#define STEPDOWN_MINIMUM 30
if ((PWM_LVL >> 1) < STEPDOWN_MINIMUM) {

EDIT: My kingdom for a [code] tag. The forum software is messing up the first code quote, the mistake is fairly visible though (modes with a superscript zero).

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

RMM
RMM's picture
Offline
Last seen: 1 year 5 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

That's what I usually do: define a lower mode, but don't put it in the normal mode orders, then tell the program to step down to that level as the minimum.  I also do the same thing when I want the turbo timer to step down to a "hidden" level.

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

vestureofblood
vestureofblood's picture
Offline
Last seen: 20 hours 29 min ago
Joined: 08/17/2012 - 15:21
Posts: 1984
Location: Missouri

Hi all,

I have a somewhat related question.    Is there any way to use a pot to control a 7135 based driver?

In Him (Jesus Christ) was life; and the life was the light of men. And the light shineth in darkness; and the darkness comprehended it not.
http://asflashlights.com/ Everyday Carry Flashlights, plus Upgrades for Maglite.

wight
Offline
Last seen: 1 year 4 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

vestureofblood wrote:

Hi all,

I have a somewhat related question.    Is there any way to use a pot to control a 7135 based driver?

See my posts a few pages ago where I started working on the code to do that with LVP integrated.

Alternatively you can use a VaraPower driver and hook up the PWM input on the 7135’s to the gate pin on the FET of the VaraPower (but do not route LED power through the VaraPower of course!).

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

FmC
FmC's picture
Offline
Last seen: 5 months 1 week ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU

Thanks for the help everyone, I’ll try defining the step-down level & adding it in there.

I’ll be flashing a couple this weekend if all goes well.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 weeks 3 days ago
Joined: 01/12/2013 - 14:40
Posts: 10655
Location: (469219) 2016 HO3

It should work to simply make the step-down reduce the PWM level without changing the mode index. Like, if the PWM_LVL is less than some minimum (10, maybe?) blink and shut off. Otherwise, tell it to cut the PWM level in half — “PWM_LVL = PWM_LVL >> 1;”.

If there’s only one level defined, any quick tap should return the light to its maximum level… and then it’ll step down when the voltage has been low for a while.

I’m assuming this is a clicky switch.

wight
Offline
Last seen: 1 year 4 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

ToyKeeper wrote:
It should work to simply make the step-down reduce the PWM level without changing the mode index. Like, if the PWM_LVL is less than some minimum (10, maybe?) blink and shut off. Otherwise, tell it to cut the PWM level in half — “PWM_LVL = PWM_LVL >> 1;”.

If there’s only one level defined, any quick tap should return the light to its maximum level… and then it’ll step down when the voltage has been low for a while.

I’m assuming this is a clicky switch.

I think the clicky firmwares already behave in exactly this way (only the momentary firmware actually steps down through the modes IIRC). The issue is that with normal operation the “some minimum” is the lowest defined mode rather than an arbitrary value. After swapping in an arbitrary minimum (10, whatever) the behavior is almost exactly as you described, except that after we reach the (10) or whatever the firmware will maintain a constant output level until it hits the ADC_CRIT value, then it shuts down.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

FmC
FmC's picture
Offline
Last seen: 5 months 1 week ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU

wight wrote:
If you're building a lot of single mode drivers and plan to change the minimum stepdown level a lot you may use a define for that value, just add one at the top like:
#define STEPDOWN_MINIMUM 30
if ((PWM_LVL >> 1) < STEPDOWN_MINIMUM) {



OK, I've defined the stepdown value in this section of the code;

 =========================================================================
 * Settings to modify per driver
 */

#define VOLTAGE_MON            // Comment out to disable
#define STEPDOWN_MINIMUM        50 // Hidden mode level for low voltage step down
// #define MODE_MOON            6    // Can comment out to remove mode, but should be set through soldering stars
// #define MODE_LOW            12  // Can comment out to remove mode
// #define MODE_MED            39    // Can comment out to remove mode
// #define MODE_HIGH_W_TURBO        110    // MODE_HIGH value when turbo is enabled
#define MODE_HIGH            255    // Can comment out to remove mode
// #define MODE_TURBO            255    // Can comment out to remove mode
// #define TURBO_TIMEOUT        240 // How many WTD ticks before before dropping down (.5 sec each)

#define WDT_TIMEOUT            2    // Number of WTD ticks before mode is saved (.5 sec each)

#define ADC_LOW                130    // When do we start ramping
#define ADC_CRIT            120 // When do we shut the light off

/*
 * =========================================================================

 

 And altered the code at the end where the stepdown routine is;

 

// Flash 3 times before lowering
                hold_pwm = PWM_LVL;
                i = 0;
                while (i++<3) {
                    PWM_LVL = 0;
                    _delay_ms(250);
                    PWM_LVL = hold_pwm;
                    _delay_ms(500);
                }
                // Lower the mode by half, but don't go below lowest level
                if ((PWM_LVL >> 1) < STEPDOWN_MINIMUM) {
                    PWM_LVL = modes[0];
                    mode_idx = 0;
                } else {                   
                    PWM_LVL = (PWM_LVL >> 1);
                }                   
                // 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--;

 

 I'm bench testing this with a partially charged cell, starting around 3.2v, & letting it run down.

I don't get the three flashes + stepdown to the defined value (50.)

Instead, it goes straight to the 10 flashes for critical voltage, but does not power off.

At no point does it step down to the predefined value (50).

 

What have I done wrong?

 

 

 

 

 

 

vex_zg
Offline
Last seen: 3 years 1 month ago
Joined: 08/10/2014 - 11:08
Posts: 420
Location: Sweden
vestureofblood wrote:

Hi all,

I have a somewhat related question.    Is there any way to use a pot to control a 7135 based driver?

I was thinking about that also a few weeks ago, It should be fairly easy to make a voltage divider with the pot, and put it to ADC.

wight
Offline
Last seen: 1 year 4 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA
vex_zg wrote:
vestureofblood wrote:

Hi all,

I have a somewhat related question.    Is there any way to use a pot to control a 7135 based driver?

I was thinking about that also a few weeks ago, It should be fairly easy to make a voltage divider with the pot, and put it to ADC.

In order to maintain use of the full physical throw of the pot and have the full desired range of PWM levels stay available a voltage divider is no good by itself – it’s not regulated so the maximum input will go down as battery voltage declines. Instead you need a regulated voltage source, probably either an LDO or on a Zener mod driver just add a divider off of the Zener. That way you have fixed target for both high and low voltages when looking at the ADC values.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

wight
Offline
Last seen: 1 year 4 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

FmC wrote:

wight wrote:
If you’re building a lot of single mode drivers and plan to change the minimum stepdown level a lot you may use a define for that value, just add one at the top like:
#define STEPDOWN_MINIMUM 30
if ((PWM_LVL >> 1) < STEPDOWN_MINIMUM) {



OK, I’ve defined the stepdown value in this section of the code; [snip]

 

 And altered the code at the end where the stepdown routine is; [snip]

 

I don’t get the three flashes + stepdown to the defined value (50.)

Instead, it goes straight to the 10 flashes for critical voltage, but does not power off.

At no point does it step down to the predefined value (50).

Oops, my mistake. Oops

Also look here:

if (mode_idx  0 && PWM_LVL 
Looks like it should be:
if (mode_idx  0 && PWM_LVL <= STEPDOWN_MINIMUM) {

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

vex_zg
Offline
Last seen: 3 years 1 month ago
Joined: 08/10/2014 - 11:08
Posts: 420
Location: Sweden
wight wrote:
vex_zg wrote:
vestureofblood wrote:

Hi all,

I have a somewhat related question.    Is there any way to use a pot to control a 7135 based driver?

I was thinking about that also a few weeks ago, It should be fairly easy to make a voltage divider with the pot, and put it to ADC.

In order to maintain use of the full physical throw of the pot and have the full desired range of PWM levels stay available a voltage divider is no good by itself – it’s not regulated so the maximum input will go down as battery voltage declines. Instead you need a regulated voltage source, probably either an LDO or on a Zener mod driver just add a divider off of the Zener. That way you have fixed target for both high and low voltages when looking at the ADC values.

i see 3 options

1. use regulated voltage reference
2. design the circuit so that you are comparing voltage of the battery with the voltage drop of the divider. Did not think this one through thoroughly though.
3. not use the full physical range of the pot, so you have some headroom to make up for the voltage drop (i.e with full battery you need to turn the pot only to 60% of it’s range to get 100% light, and with low battery you need to turn it to 100% to get 100% of the output

also the pot solution might be used with constant DC power supply, so perhaps battery is not the power source in this one at all.

wight
Offline
Last seen: 1 year 4 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

vex_zg wrote:
i see 3 options

1. use regulated voltage reference
2. design the circuit so that you are comparing voltage of the battery with the voltage drop of the divider. Did not think this one through thoroughly though.
3. not use the full physical range of the pot, so you have some headroom to make up for the voltage drop (i.e with full battery you need to turn the pot only to 60% of it’s range to get 100% light, and with low battery you need to turn it to 100% to get 100% of the output

also the pot solution might be used with constant DC power supply, so perhaps battery is not the power source in this one at all.

Yes, all correct. (Based on who’s asking, I assume it’s a flashlight. VoB is probably looking for something like a new Lambda VaraPower.)

The ATtiny can be set to use Vcc as the reference voltage, so your #2 option is a good one assuming that don’t need to do battery monitoring. If we do need to do battery monitoring then we have to switch the Vref back and forth. I’ve already written (and posted in this thread) simple/hacky code to do that – it didn’t work correctly. I think we probably need to take two readings every time we switch the Vref, but I haven’t tried that yet.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

FmC
FmC's picture
Offline
Last seen: 5 months 1 week ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU
wight wrote:
Also look here:
if (mode_idx  0 && PWM_LVL 
Looks like it should be:
if (mode_idx  0 && PWM_LVL <= STEPDOWN_MINIMUM) {

Thanks wight, I’ll try that out tonight. Beer

FmC
FmC's picture
Offline
Last seen: 5 months 1 week ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU

wight wrote:
Also look here:
if (mode_idx == 0 && PWM_LVL <= modes[mode_idx]) {

Looks like it should be:

if (mode_idx == 0 && PWM_LVL <= STEPDOWN_MINIMUM) {

Thanks - that worked, in so far as stepping down to the STEPDOWN_MINIMUM value.

However, it continues to give the 3 periodic warning flashes, until the voltage gets down to around the 2.6 mark, where it seems to eventually peter-out.

It does not appear to be getting to the Critical routine (10 flashes & power down).

As it is now, I'm happy with the operation. I ended up increasing the time between warning flashes, as they were annoyingly frequent.

For educational purposes, I'm still interested as to why it's not getting to the Critical/Shutdown routine.

#ifdef VOLTAGE_MON
        if (low_voltage(ADC_LOW)) {
            // We need to go to a lower level
            if (mode_idx == 0 && PWM_LVL <= STEPDOWN_MINIMUM) {
                // Can't go any lower than the lowest mode
                // Wait until we hit the critical level before flashing 10 times and turning off
                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();
            } else {
                // Flash 3 times before lowering
                hold_pwm = PWM_LVL;
                i = 0;
                while (i++<3) {
                    PWM_LVL = 0;
                    _delay_ms(250);
                    PWM_LVL = hold_pwm;
                    _delay_ms(500);
                }
                // Lower the mode by half, but don't go below lowest level
                if ((PWM_LVL >> 1) < STEPDOWN_MINIMUM) {
                    PWM_LVL = modes[0];
                    mode_idx = 0;
                } else {                   
                    PWM_LVL = (PWM_LVL >> 1);
                }                   
                // 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--;
                }
            }
            // Wait 10 seconds before lowering the level again
            _delay_ms(10000);
        }
    #endif

wight
Offline
Last seen: 1 year 4 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

FmC wrote:
<p>
wight wrote:
Also look here:</p><pre>if (mode_idx == 0 &amp;&amp; PWM_LVL &lt;= modes[mode_idx]) {</pre><p>Looks like it should be:</p><pre>if (mode_idx == 0 &amp;&amp; PWM_LVL &lt;= STEPDOWN_MINIMUM) {</pre><p>
</p><p>Thanks - that worked, in so far as stepping down to the STEPDOWN_MINIMUM value.</p><p>However, it continues to give the 3 periodic warning flashes, until the voltage gets down to around the 2.6 mark, where it seems to eventually peter-out.</p><p>It does not appear to be getting to the Critical routine (10 flashes &amp; power down).</p><p>As it is now, I'm happy with the operation. I ended up increasing the time between warning flashes, as they were annoyingly frequent.</p><p>For educational purposes, I'm still interested as to why it's not getting to the Critical/Shutdown routine.</p>
Probably due to an additional oversight on my part.  Let's see where I went wrong.  

Hmm.  Are you _certain_ that it's stepping down?  To me it [now] looks pretty clear that the stepdown process is broken by the changes I suggested.  It seems that I missed was this line that will continue to reset the driver to modes[0] (100% duty cycle, 255/255):

              // Lower the mode by half, but don't go below lowest level
                if ((PWM_LVL >> 1) < STEPDOWN_MINIMUM) {
                    PWM_LVL = modes[0];
                    mode_idx = 0;
                } else {                    
                    PWM_LVL = (PWM_LVL >> 1);
                }        

As you can see, the line highlighted in red above should continue to reset the mode to mode zero every time we get PWM_LVL down to the point where halving it will take it below STEPDOWN_MINIMUM.  Instead we should set it to STEPDOWN_MINIMUM there!  Otherwise this conditional never becomes true: "if (mode_idx == 0 && PWM_LVL <= STEPDOWN_MINIMUM)" because we keep stepping down from modes[0] towards STEPDOWN_MINIMUM over and over without ever actually reaching <= STEPDOWN_MINIMUM.

Depending on what you set STEPDOWN_MINIMUM to we should be stepping down several times and then going back up, then doing it again - over and over.  At least that's what I see at the moment...

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

Pages