Flashlight Firmware Repository

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.

I didn’t notice that bistro has made it into TK’s normal firmware repository.

Her testing repository is where I got the Nov 8 r207 version. ~toykeeper/flashlight-firmware/tiny25 : files for revision 217

~ edit ~
She dropped BOD and also increased the startup delay from 4ms to the max of 64ms. You can compare them with these direct links to each set of fuses in the Engbedded Atmel AVR Fuse Calculator.

bistro.c fuses
L: 0xd2, H: 0xde, E: 0xff in Fuse Calculator

bin/flash-25.sh (2015-11-08) fuses
L: 0xe2, H: 0xdf, E: 0xff in Fuse Calculator

Looking through my files it seems I’ve been using BOD 1.8v, startup delay 64ms (max). L: 0xe2, H: 0xde, E: 0xff. I believe I been using those since the beginning with bistro, ignoring the ones mentioned in bistro.c. Thought a longer startup delay wouldn’t hurt anything.

Ahh, ok. I'll check out that version then, and the fuses. Thanks!

Also just try reflashing a couple times. I had a odd, different bug when 1st trying out the tiny85. The bug was there for the first couple flashes, then it just disappeared on a later flash and never came back. I did nothing to fix the bug. No changes. Just vanished. :ghost:

I've done lots of 85's with my latest firmware - goes really smooth now, no hickups, but this is my first 25V using bistro. I used 25's back in the beginning though.

Got the new 11-08 version with the new fuse settings (e2, df, ff) and it's still working the same - always comes up in config mode. How is it supposed to start up? Is there a default mode set?

I'm confused, info is sketchy, TK doesn't seem to be around.

I think TK will be back next week. I cannot remember what planet(s) she was visiting but she is coming back soon.

Hi, I was temporarily tied up in Mordor, but now I’ve got a few days in The Shire to catch up a bit…

If it enters config mode, it thinks that fast_presses is greater than 15 (at least one of its four upper bits is set) and the OTC value indicates it was a short press.

So, this could mean that the OTC isn’t calibrated. Or it could mean that the mem decay trick isn’t working. I’d start by measuring the OTC values and then plugging them into a new build of bistro.

BTW, the weather in Mordor is nice this time of year.

I think I got a problem with the OTC cap - I added it later by hand soldering so maybe it got too hot, or bad solder joint. I'll try replacing it. Thanks!

If you want to you can add this firmware to the site:

I’m mighty impressed that you can get internet in the Shire. :smiley: Never looked like they had much in the way of technology, at all. I mean they don’t even know how to make or otherwise acquire shoes! They make the Amish look like the Jetsons.

It was the cap - bad solder joint. Once fixed, it came up in 4 modes, well 3 modes plus moon. Think that's the default?

On to the next problem - high mode flickers on for a moment than switch's right a way to the 1st mode. If a use a higher resistance cell, the problem goes away. I noticed this behavior when trying to get a tailcap amp reading, even on the weaker cell. Don't think I ever saw a problem like this - not sure, maybe bad ground. Something to do with high amps, not just FET usage... Dunno.

Update:

Ok, - got a Fix!! Added a 2nd 10 uF cap sitting on top of the normal one, and wholla! Problem goes away!! Details in Post #580 here.

I've used this type of fix before, on a 22 mm driver.