STAR Firmware by JonnyC - Source Code and Explanation

Flashlight Modding and DIY Parts
716

I’m not sure if the ADC is as noisy as you think. It’s definitely noisy, but my small experience with MCUs and ADC’s tells me that ADC noise is not the core of any of the actual problems. The driver should behave with no smoothing, it should just be a little rough. I think, heh. I definitely plan to come back and do something about the noise.

Thanks for the poitners on declaring as volatile. I’ve had that explained to me before, but lost track of it. I’ll go through and clean it up.

That final point of yours about the structure of the loop is right on the money. That is clearly a bad setup, I see it now that you have pointed it out. Either blocking for it or moving it inside the if conditional seem equally good to me for this setup. For now I’ve moved it inside the if conditional.

Most recent results:

# With VOLTAGE_MON undefined in v009 the pulsing goes away AND I’m able to turn the output all the way up with my pot. And all the way down.

# No change after moving:

ADCSRA |= (1 << ADSC);

It was still a good point though.

  1. v011 has batt_adc_ticks declared as volatile. It’s the only variable which should be able to change unbeknownst do the main loop. No change.
  2. I went ahead and commented out the entire mechanism that does anything to the output based on voltage monitoring, but left VOLTAGE_MON defined so that the ADC would toggle back and forth. Sure enough, the pulsing is gone - time will tell whether that was ADC noise or a screwup(s) in the LVP section I commented out. In the meantime I noticed that with this setup I still have upper and lower limits on what I can do with the pot. It won’t turn the output all the way down OR all the way up. I’m thinking that I need to do two readings each time I change Vref and discard the first reading.

We’ll come back to that thought though, it’s time to hang up the hat for the day. Thanks for your help ToyKeeper.

717

To mostly eliminate the noise, it works well to do something like…

  if (ADCH > PWM_LVL) { PWM_LVL ++; }
  else if (ADCH < PWM_LVL) { PWM_LVL --; }

It works pretty well as a lowpass filter, and adds a nice ramp effect when the value changes really quickly.

Or you could, you know, resolve the cause of the noise. But sheesh, who wants to do things properly? :slight_smile:

718

Yup, thanks! I'll change that comment.

719

I never added strobe to any of mine. I believe RMM has a strobe option in his versions which I never included back in mine, and of course the other guys here have added their own strobes.

This is what RMM did in the "int main" routine, changed this...

[quote] set_output(modes[mode_idx]); [/quote]

to...

[quote] if (modes[mode_idx] == 254) {

// Strobe. The program will stop here, you will lose the voltage monitoring feature

while (1) {

set_output(255);

_delay_ms(20);

set_output(0);

_delay_ms(60);

}

} else {

set_output(modes[mode_idx]);

} [/quote]

A mode of "254" will become a strobe then. I can add this to STAR and STAR_off_time if it works well enough.

As for strobe, what is the most effective one? Does the 20 ms on and 60 ms off work effectively? Does anyone know if this can be done via PWM by dividing the clock (really slowing down the PWM)?

720

It’s not necessary to lose voltage monitoring just because the light is in a blinky mode. In mine, I just light up, wait, turn off, wait, then proceed with the main loop (which allows voltage monitoring to happen), then it happens again next time the loop comes around. Instead of using modes[mode_idx] as a code to enter strobe mode, I use mode_idx itself (with #defines to decide how to map indexes to behaviors). The modes[mode_idx] value represents the strobe speed. This way, you can have strobes of different speeds without using mode space in the ROM.

Here is what I’m using, an off-time firmware with strobe modes:

http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/ToyKeeper/cypreus/

That’s the one which has deviated the furthest from STAR though. Its predecessor, ToyKeeper/s7/s7.c, is closer (but is on-time based). Also, they both use party strobes (freezes motion) instead of tactical strobes (for stunning people), so you’d need to change the duty cycle.

From what I’ve heard/read, the most effective tactical strobe is 10Hz with a 50% duty cycle. So, something like this should work:

#define OWN_DELAY
#define SOLID_MODES 4
#define TACTICAL_STROBE_MODES 2+SOLID_MODES
...
const uint8_t modes[] = {
    MODE_LOW, MODE_MED, MODE_HIGH, MODE_TURBO,  // solid modes
    50, 25,  // 10Hz strobe, 20Hz strobe  (1000 / 2 / X == strobe speed)
};
...
int main(void)
{
    ...
    while(1) {
        if(mode_idx < SOLID_MODES) { // Just stay on at a given brightness
            PWM_LVL = modes[mode_idx];
            sleep_mode();  // the WDT will wake us up for voltage checks
        } else if (mode_idx < TACTICAL_STROBE_MODES) { // strobe mode, fixed-speed
            PWM_LVL = 255;
            _delay_ms(modes[mode_idx]);  // requires OWN_DELAY
            PWM_LVL = 0;
            _delay_ms(modes[mode_idx]);
        }
        #ifdef VOLTAGE_MON
        if (ADCSRA & (1 << ADIF)) {  // if a voltage reading is ready
            ...
        }
        #endif
    }
}

As for using PWM to do strobes… it should be possible down to 2Hz (I wrote a script to do the math a while back), but it would require setting the CPU to its absolute slowest clock speed. I haven’t looked up if that can be done from inside the program or if it needs fuses set. So, it might interfere with the PWM on regular modes, and the only real benefit is that it would use slightly less power.

721

Oops, I just realized/remembered that STAR doesn’t know at compile time how many modes there will be. That certainly makes it harder to use the mode index to decide what kind of behavior to use.

722

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?

723

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

724

Thanks TK, will I find these in your repository?

725

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.

726

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?

727

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.

728

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

729

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

730

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.

731

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.

732

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?

733

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

734

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 :slight_smile:

735

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