Flashlight Firmware Repository

I have a reverse clicky wired into the negative lead coming off my power supply.

RMM sells eswitches? I’ll have to check them out. I’ve just been soldering a small wire to the esw+ pad and then tapping it in the ground ring.

Thank You TK!

Just (almost) finished a super-simple UI for the X6R I’m doing for my grandfather.

The X6R is a dual-switch light. I am using a custom driver with 2 banks of 3*7135’s (6 total)

- Rear switch ALWAYS turns the light on high, Full on both banks (2.28amps)

- 2min turbo timer steps down to a hidden mode, 1 bank switches off (1.14amps)

- Side switch changes from high to low (PWM controlled) and back to high

  • Total 2 normal modes + the one hidden medium

That’s it.
All i have left to add is code that shuts the light off when the charger is connected. I’ll start on that tomorrow.

On the off chance that anyone else could have usr for this, here is my .c file, next to the original STAR momentary file. (original is on the left)

That is some interesting and large variation. All 7135s are obviously not created equal.
If the emitter makes a difference it is simply because the 7135s are not turning on fully?
Note that it may be normal for the tiny to have less trouble turning on one 7135 than multiple 7135s. I only looked at turn-on time with 8 7135s. The MCU output has limited drive current and it has to feed the combined 7135s gate capacitances at the start of each pulse. This is like shorting the MCU pin momentarily to ground until all these (very small) parasitic ‘capacitors’ charge up. Would have been great if we actually had a datasheet to know what we are dealing with.
If it is useful I can take oscilloscope screenshots some time to show the turn-on delay of the 7135s. Maybe compare 3**, 4**, 6* and 8* 7135 drivers.

This is my deluxe wooden light for testing :). At the moment it features an ISP quick connector soldered to a 105C to save the clip and frustration. The switch is a regular reverse-clicky from an old light.
The local 1000 uF capacitor is required to run PWM properly when hooked up with 1m leads to a power supply.

Scope shots would be cool. Comfychair published some a while back, but he and his site went down since then. Here’s one of his results though:

In any case, yes, the emitter matters. With otherwise identical hardware, an XM-L2 will light up at a lower PWM level than an old XM-L. It also depends on the type of 7135 chips; the 350mA ones behave a little different than the 380mA ones. And it depends on the number of 7135 chips… it seems like 1x and 32x light up at pretty low levels, but 4x and 8x might require something a little higher (maybe). I haven’t tested the number of chips very much though.

I’ve seen a few drivers light up at fast PWM=0, a bunch at phase PWM=2 or 3, and a couple as high as fast PWM=9.

Anybody know if it would cause long-term harm to the Attiny13 for it to receive 5.5v directly to one of it’s I/O pins? I’ve tried it, so I know it doesn’t fry immediately.

Not sure but could we just add a zener in line?

If necessary I definitely could (easily).

Pyro, you probably already know I’m talking about the X6R driver.

That’s why I said “we” :wink: I remember that you put a resistor pad for pin 3 does a resistor not work to bring it to safe limits?

Oh BTW liking the firmware you’ve tweaked for it will probably use it with mine.

Ooo that would save us a pin!

EDIT: Sorry, I understand now that wouldn’t work. Would still need to use pin3

The rating of the IO pins is tied to what you feed on pin 8 (Vcc).
Except for pin 1 (the reset pin), the ‘absolute maximum’ rating on any pin is Vcc + 0.5 V.
And the maximum rating for Vcc is 6 V.

(Datasheet 18.1)

But running close to a device’s absolute maximum rating is usually a bad idea.

The datasheet says this:

Could it be made so that a standard momentary firmware that only outputs one PWM channel, with a certain sequence of button presses could change the output pin and nothing else all modes stay the same but out of a different pin instead?

Yes, it’s definitely possible to make something which toggles the output channel. I’m not totally sure why, unless maybe you had two different emitters, but it can be done.

Cool, basically I like having a secondary Red emitter in my lights, sometimes useful mostly just novelty but adds something extra to it. Would be cool to have a full range of levels and pick with emitter to output from.

This is the stock 105C on the ‘wooden light’ above. It has eight 7135s and drives a mystery bin XML2.

I set up the PWM to 9.4 kHz phase-correct. (Actual frequency is 7.2 kHz, due to the un-calibrated clock we get at 4.8 MHz).
Since we are running at 7.2 kHz, each of the 255 sub-periods of the PWM signal is around 0.55 us (1/7200/255).
This is with a PWM duty cycle of 32/255:

We are zoomed in on only one ‘on’ pulse of the PWM train.
The yellow trace is the control pin on the MCU.
The cyan trace is the ‘output’ pin of the 7135s going to the LED.
Both are referenced to ground (normally cell negative terminal, although I was using a bench power supply).

The horizontal scale is 2 us per division.
The vertical scale is as indicated on the screen capture, but is not very important. Basically the 7135s are fully on when the blue trace bottoms out and fully off when at the other end. (I did trace the current as well, but the signal is much more noisy, using a 4” piece of AWG 22 as shunt does not help.)

So we see on the yellow trend that the MCU output turns on at the 2nd division from the left, struggles for 2 us, then settles as a straight line at 4 V.

The 7135s output oscillates for another 4 us (there is a control loop in each chip, and this wave is probably created by the feedback loop trying to catch up with 350 mA set-point). So our theoretical 32/255 x 2.8 A becomes more like 22/255 x 2.8 A.

This what we get at 2/255 PWM:

and 4/255:

8/255:

No surprises, we are just cutting the trend we see on the first screen capture.

Finally around 10/255 we start to get to the stable output level, just before the end of the pulse:

So basically we have a 6 us unstable transition period before the 7135s get to do what they are supposed to.

Typical circuit design strategy would limit this unstable operation to less than 10% of total operation to get acceptable stability, linearity, efficiency, repeatability, etc. That means not using pulses shorter than 60 us.
That is around 43% PWM at 7.2 kHz. And 86% PWM when using fast PWM at 13.5 kHz!
So we see we are not really playing inside the ballpark.
It also unfortunately translates to an ideal PWM frequency of 1/(60 us x 255) = 65 Hz.
Not going to happen.
So we have to live with the inconsistent PWM results or find a better way of doing it.

My compromise for the moment is to lower the PWM to 2.2 kHz.
Also lowering the self-imposed 10x criteria above to 2x limits me to using pulses longer than 12 us.
At 2.2 kHz, each 1/255 sub-period is 1.8 us. So PWM duty cycles greater than 7/255 is ‘stable’.

2.2 kHz PWM, 8/255 duty-cycle, more than half the ‘on pulse’ gives stable current:

I am working on my X6R, trying to get it to recognize when the charger is connected. I have connected a wire directly from the USB 5v+ to Pin 7 on the Attiny (normally used for LVP). Then I ran TK’s battcheck.hex. As expected, it reads out the full 255 adc value.

So now all we need is a bit of code that tells the light to turn off when it senses max voltage on Pin 3, right?
Something like:

If
adc_ticks = 255;
mode_idx = 0
else
mode_idx = last_mode_idx

Except in the proper language and for Pin3 instead of pin7.

Or even if it detects ANY voltage on Pin3, it doesn’t have to be specific.

I’m trying to get this working in the STAR momentary version I posted above.

Would this work?

I’ve put it into the firmware here
Don’t know it it will actually work and can’t try to compile it as I’m currently at work.

I don’t really follow what you did, but I’ll compile it and try it on my test rig…. just a minute….

edit: it compiled and flashed fine, but no dice. The driver didn’t react at all to input on Pin3 (or pin7)

Dam. I’ll keep looking at it hopefully ToyKeeper might be able to see any issues with what I’ve done. I’ll start from scratch tomorrow and see what I can fine. Just bare in mine that I have no coding background and have never learnt any coding, I just hack and stitch stuff together.

At a glance, it doesn’t appear that code is checking pin 3 at all. The ADC hardware can only measure one thing at a time. With VCC on one pin and the charge sensor on another, it’s necessary to reconfigure the ADC between readings and then set it up for a fresh measurement. This will mean flip-flopping the ADC between two pins, toggling the pin every time it goes through the main loop.

Also, it looks like you told the code to step down incrementally before shutting off, like what the LVP does, instead of just shutting off. And it’s sharing the same “lowbatt_cnt” counter as LVP, so I’d expect it to act more than a little bit weird. Like, if it detected the charger being connected, it’d bump up the counter. But then LVP detection would see that the battery is fine, and reset the counter to zero. And it would keep repeating that while the light stays on forever.

I’ll be doing something similar soon, but instead of LVP + charger, it’ll be measuring LVP + temperature. So maybe I’ll have an example of how it can work soon. Also, I think JonnyC already did something like this in his thermal step-down branch, but I’m not sure how close it is to finished.

I thought it would take much less code. As you said, it doesn’t need to ramp down or delay and check a few times before acting, just set pwm=0 or mode_idx=0 as soon as any positive input is sensed on Pin3.

I thought it would just be as simple as changing mode order on Star3 was/is.