STAR Firmware by JonnyC - Source Code and Explanation

I’m not entirely sure what you mean, but if I saw the errors I could probably explain what caused them.

If you removed the entire chunk of code you pasted, I can see why it wouldn’t compile. The snippet included the beginning but not the end of a function, leaving the code in a malformed state.

On a different note, JonnyC never responded about the code repo. I suppose perhaps I should relocate to github so at least I’m using the same infrastructure and can more easily merge changes. Git may not be as clean about how it keeps history, but it’s important for everyone to be using the same tools.

i think what caused the errors is #ifdef MODES_ has to be under int main(void) for the code to run in the correct order.

if i would have put #ifdef MODES_ under int main(void) after this code for off-time memory it will not compile,

// Start up ADC for capacitor pin
DIDR0 |= (1 << CAP_DIDR); // disable digital input on ADC pin to reduce power consumption
ADMUX = (1 << REFS0) | (1 << ADLAR) | CAP_CHANNEL; // 1.1v reference, left-adjust, ADC3/PB3
ADCSRA = (1 << ADEN ) | (1 << ADSC ) | ADC_PRSCL; // enable, start, prescale

// Wait for completion
while (ADCSRA & (1 << ADSC));
// Start again as datasheet says first result is unreliable
ADCSRA |= (1 << ADSC);
// Wait for completion
while (ADCSRA & (1 << ADSC));
if (ADCH > CAP_THRESHOLD) {
// Indicates they did a short press, go to the next mode
next_mode(); // Will handle wrap arounds
store_mode_idx(mode_idx);
} else {
// Didn't have a short press, keep the same mode
#ifndef MEMORY
// Reset to the first mode
mode_idx = ((mode_dir == 1) ? 0 : (mode_cnt - 1));
store_mode_idx(mode_idx);
#endif
}

or at least thats when i quit getting errors.

Sorry. I ended up just creating a Github repository mostly for my own sake (so I could keep track of my different versions, start branches for the dual-PWM feature so people could try them, etc.). Feel free to do whatever you want with the STAR code. I don't plan on keeping track of all of the different variations out there (NLITE, etc.). I don't think it's that necessary to store all possible programs in one repository as long as we link to them from somewhere. Maybe we could create a new thread on here that lists them all and what they do, and keep the first post updated whenever something new comes out. I'm not up to the task though ;)

im not a coder, i am just trying to learn from trial and error, but doesnt { and } begin and end a function? i removed more than i posted.

It doesn’t overly bother me, but if I had a choice I would prefer it react how it does on low pwm mode. As I don’t understand what the buzzing is about, and if it is damaging anything, I changed back to high pwm and will be very happy with how it performs.

So you removed the function. Did you remove the call to that function then?

do you mean this “check_stars()”?

Yeah

ooh interesting…are the flashy modes hidden?

Can you make a video on the function of the light

Way cool!

yes i removed it.

The flashy modes are “hidden” in the sense that it takes a bunch of clicks to get to them. I doubt a video is really needed… and I’m sick and coughing like crazy so I don’t want to speak today. The modes are:

  • Click once (or tap once if already on): Moon mode
  • Tap twice: low
  • Tap three times: medium
  • Tap 4X: high
  • Tap 5X: maximum output
  • Tap 6X: moon-med beacon (flash med in a quick stutter, then rest at moon, repeat once per second)
  • Tap 7X: low-high beacon
  • Tap 8X: med-max beacon
  • Tap 9X: heartbeat-style beacon — blinkblink, pause, blinkblink, pause
  • Tap 10X: 10Hz true strobe (1ms on-time, freezes motion)
  • Tap 11X: 24Hz true strobe (0.3ms on-time, freezes even fast motion)
  • Tap 12X: 60Hz true strobe (0.3ms on-time)
  • Tap 13X: ~7Hz to ~18Hz self-ramping strobe (1ms on-time)
  • Tap 14X: ~16Hz to ~100Hz self-ramping strobe (0.3ms on-time)
  • Tap 15X: Start over again at moon mode.

It uses short-cycle memory, so whenever it has been on for more than a second it will reset to starting at the first mode. To go from medium to low, for example, is a couple quick taps on the button (like half-pressing a camera shutter).

I find the solid modes are useful for general purposes, the dual-level beacons are useful while biking or signalling for assistance, and the strobes are just fun to play with. For example, point one of the self-ramping strobes at a spinning fan and it’ll gently rock back and forth, spinning one way then the other.

If you really want it to come on in a non-moon mode next time, it can be tricked into doing so. Basically just replace the last ‘tap’ with a full click (to turn it off), and then leave it off. Next time it starts it’ll be in the desired mode.

I included a .hex file for easy flashing, if anyone is interested. Use the ‘download file’ link here:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/view/head:/ToyKeeper/s7/precompiled.hex

Now you got my attention.

Which driver; which pin?

NightSpy, who (or which post) are your questions addressed to?

Crum… I think I got the X6 thread mixed up with this one.

Guys quick question, does turbo timer not work if the mode order is reversed?

I’ve made my wife a new EDC (an HD2010, even I dont EDC a light that large, good for her!) but she wanted it to come on in turbo and go down but its having some issues, stepping down threw the modes when it shouldnt and just acting bad in general so I was wondering if that just wasnt possible to use the timer if turbo comes first.

Also I’m using the instant start turbo ramp down, not the timed single step.

Of course it’s possible to make it work as desired… just depends on the code used. I can’t say I’ve actually used turbo though. I haven’t even tested the low-voltage stepdown yet.

In any case, I kinda prefer to remove the star-soldering config options and simply build the code with the exact features I want. It provides more room and makes the code more straightforward for debugging.

Hmm, crap, it is definitely supposed to work. Are you using just the latest standard STAR program with the instant turbo ramp down change? PM me and I can give you my email address if you want to email the file you're using for me to debug.

Thanks!

I got the updated versions added to my repository, under a dual_pwm/ subdirectory.

Additionally, I fixed the broken wires on my SRK and tried the new STAR_momentary on it. I made a few small changes for my own use, and put them in the repo too. It’s available here:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/ToyKeeper/STAR_SRK/

The changes are:

  • Six output levels (plus “off”) instead of four.
  • Short presses will cycle from high to low.
  • Long presses will cycle from low to high.
  • If you keep holding the button, it will cycle on its own (low to high). So, from off, simply press, hold, then release when it hits the desired level.

I tried to measure the output too, and got the following. I don’t trust my light box at the highest two levels though, and I had to estimate the highest level via ceiling bounce:

  • Mode 1: 1.0 lm
  • Mode 2: 12 lm
  • Mode 3: 62 lm
  • Mode 4: 315 lm
  • Mode 5: 1148 lm
  • Mode 6: 3100 lm (turbo)

This setup allows the SRK to go a lot lower than the “SRK Special” firmware RMM is currently using (it started at 43 lm). The slower PWM seems to have helped a lot! It actually emits a useful amount of light with the PWM set to 1. Thanks for implementing the per-mode PWM timings! :slight_smile:

#define MODE_PWM 0,PHASE,PHASE,FAST,FAST,FAST,FAST // Define one per mode above, 0 for phase-correct, 1 for fast-PWM

Very slick solution :p

Adding a 0.8 or 1.2uH inductor between the B+ & LED+ pads will drop it even lower (it attenuates the PWMed levels, with greater effect the lower the value - lots of reduction in the lower modes, very little in the upper and nearly none at all on the 100% high). It also smooths out the rising/falling edges of the output sent to the LEDs, without affecting the nice square wave the FET likes.