Flashlight Firmware Repository

Don’t use “FAST” PWM mode for moon. Try using PHASE instead, and it should be a lot more stable.

The reason is because the LED takes like 2 to 5 “frames” to visibly light up, depending on voltage. With FAST mode, it’s only powered for 3 out of every 256 frames, and the first 2 to 5 of those frames are dark. After voltage drops low enough to need 4 frames, it won’t light up at all.

With PHASE mode it instead lights for 6 out of every 512 “frames”. So, it still gets dimmer with voltage but even with a nearly-empty cell it should still light up at least a little bit.

I’d suggest using PHASE for moon and turbo, and FAST for every other mode.

Thanks. I’ll try that.

Hi TK,

I am using your Firmware for Ferrero Rocher driver and I was wandering what is the maximum number of ticks I can use for the turbo timer? I need to be out about 10 min.


EDIT: Also I dont see where to set the turbo low at. What is the default?

The turbo timer is a 16-bit integer, so the maximum value is 65535 (one less than 2 16). Each “tick” should be about 0.016 seconds. 10 minutes * 60 seconds / 0.016 seconds per tick = 37500 ticks per 10 minutes.

The turbo function in Ferrero_Rocher.c simply steps down one level as if the user had told it to drop one step. So, it should go to the second-highest level.

Awesome, thats just what I need. Is there any option on this firmware for a linear ramp down from turbo to high vs the drop ( like in star firmware)?

Nope. But if you want a ramping interface you could use Ramping_UI_table.c instead.


I think a ramp UI would be a bit much for this project. Are you aware of any e-switch UIs that do have the smooth drop from turbo to high?

Offhand, I can’t think of any… but I might be forgetting something.

It's certainly do-able to ramp down smoothly - haven't thought of implementing mine that way though. You could just do the math - how fast you want the transition done, and how many levels it takes. I usually setup a med mode (next mode down from turbo) to be in the 35-40% range. 255 down to 35-40%, is 255 down to 102 (40%) is 153 steps, so if you want it done in ~2 secs, it's 1 step down every 13 msecs. Well, our timer interrupts are 16 msecs, so, 1 step per interrupt is: 2.45 secs.

That ramping would be pretty easy to implement. For 35%, it would take 2.66 secs.




Easy for smarty pants like Tom E and TK maybe :) For VOB, well.....?


I use both your UI and TKs in my personal lights. For hand held I like yours for the one click off, and I use TKs Ferro in my headlamp. The light I am building now is a head lamp, but its for someone else and it gets hot fast on turbo. I set the timer, but when it kicks down to the next lower mode it just feels like a crash. I am afraid that if I give it to him like this he is going to feel let down or as if something is wrong.

Ideally I would like the drop to take more like 15 seconds. If implementing this is something you think you can explain to a noob I am all ears.

If not I'm sure I could scare up some candy in my shop for a little trade action.

Ahhh - I'm using the Ferrero Rocher in my F6, and contemplating using it in a couple of swm C20C's I bought as well, since the driver fits in perfect and has the window built-in already. The C20C is just a little better, more compact version of the F6. Like it for not having that darn SS tail plug that is a PIA for modding the tail spring, and the tail spring is uncoated steel - ugh. The C20C was a great deal at $30 but Illumn sold them out - I was able to get 3, very moddable just like the F6's. I probably contributed to them selling out with my blabbing bout them .

Hhmm - hate to commit to anything at this point, but if you have some time, I'd probably get to it. Stretching it out would be pretty easy as well, and would be a nice feature. Dunno if it can fit in 1K for a 13A though - might need a Tiny25. I'd have to see...

Whenever is fine. I does not have to be quite that long, but I would need it to be in the 13A so I will take whatever fits in that. just let me know. PS: Not kidding about something in trade if you like :)

K, I'll look into it.

If the realtime battery status LEDs are turned off, there should definitely be room to add a slow turbo ramp-down.

It has been quite a while since I touched any of that code, so I don’t recall how much room is left but IIRC it wasn’t much when all the features are enabled.

I would certainly not need those. I am only using the very basic driver functions.

Yes - current size is tight - my build for the Roche F6 is 986 bytes, leaving 38 bytes spare - not enough. But if you don't want the LED support (?) confused, why are you using this firmware then? That's the main feature.

With REDGREEN_INDICATORS commented out, it reduces to 970 bytes - not much savings. Adding comment out of LOWPASS_VOLTAGE results in 916 bytes used, 108 bytes free. Maybe with this space it would be do-able.

Oops, re-compiled with flags back on and it's 1012 bytes -- ???

I use this firmware because its the only e-switch Firmware I know of that I can click for mode up and press for mode down. Works very well for a headlamp. If there is a similar option I could be talked into that.

Other than the trubo timer and ramp down function we spoke of I cant think of anything else in it I would need. My headlamps dont have any red/green leds on them :)

TK or anyone that's used bistro. First time trying it, on a wight FET+1 driver, a Tiny25V. It seems to always come up in config mode. There's a pause for couple secs, then it starts from config setting #1 - if I just let it go, sometimes it stops in config #2, one time I let it go thru all settings, and the LED was on in the end, but as soon as I cycles power, it still doesn't work - runs config mode again.

I'm using the fuse settings as specified in the header of the source code. Anyone get it working? Anyone see this happening?

Hmmm, I haven’t seen that. I’ve flashed bistro many times, you know, making tweaks, adjusting defaults, LVP, upgrading to new bistro revisions, etc. Though I’ve only used it on attiny85 (normal, not “v”).

You’re trying the newest revision 207 (2015-11-08)?

I see bistro.c mentions these fuses
* Low: 0xd2
* High: 0xde
* Ext: 0xff
But, TK has different fuses in the latest revision (2015-11-08) of her bin/flash-25.sh flashing script.
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/tiny25/changes

avrdude -c usbasp -p t25 -u -Uflash:w:$FIRMWARE -U lfuse:w:0xe2:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m
http://www.engbedded.com/cgi-bin/fcx.cgi?P_PREV=ATtiny25&P=ATtiny25&M_LOW_0x3F=0x12&M_HIGH_0x07=0x07&M_HIGH_0x20=0x00&B_SUT1=P&B_SPIEN=P&B_CKSEL3=P&B_CKSEL2=P&B_CKSEL0=P&V_LOW=e2&V_HIGH=DF&V_EXTENDED=FF&O_HEX=Apply+values

You could try those to see if it kills your bug.

Where is the Nov 8 version? Latest source code posted is from Oct 18th, rev 153.1.2 here: http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/ToyKeeper/bistro/ ??

Hhmm. Looks like she dropped brown-out detection, but didn't update the comments maybe... I'll look into this more.