Attiny25/45/85 FW Development Thread

Another question, can I reflow this one
Attiny85

onto and replace the original mcu on
BLF X6 driver
Or
BLF A6 driver

And then flash Narsil onto it?

Is there any difference on the two drivers after the mcu reflow, besides lighted tailcap options on the X6?

No. That version of the tiny85 is physically too large, won’t fit.

That eBay one is a thru-hole, you need a surface mount, and specific size like this one: http://www.mtnelectronics.com/index.php?route=product/product&path=25_104&product_id=601, and note Richard's instructions about bending the pins.

Page 206 here: http://www.atmel.com/images/atmel-2586-avr-8-bit-microcontroller-attiny25-attiny45-attiny85_datasheet.pdf, you want the 8S2 package, and then have to bend the pins to fit.

I've used those from Richard, and these: ATTINY85V-10SU

Unfortunately you may have problems upgrading the BLF A6 with it's inferior components - might have to piggyback another 10 uF cap onto C1, or add a 0.1 uF cap across the grnd and Vcc pins of the MCU. The BLF X6/X5 driver is better, but not great. The BLF X6/X5 driver uses a 12 uF C1 cap, not 10 uF, so in theory should work with a 85 without adding anything else.

Thanks for the quick replies!
If I cut the trough-hole paws on the 85 and bend them over, maybe it can work?
Yes, I already ordered them before I posted :person_facepalming:

So X6 would be best for upgrade compared to the A6.
Do you guys build these drivers from scratch, using Oshpark boards? Even mtnelectronics or 3tronics doesn’t sell anything close


Yes - I usually build from scratch with OSHPark. Sometimes though I've used Richard's boards that he sells bare. However I've also upgraded boards, such as Richard's fully populated SRK 7135 based drive. I swapped the two voltage divider resistors out to 220K and 47K (to lower parasitic drain), and swapped out the MCU. I didn't need to touch caps or add one - it just worked fine as-is. Here's some pics:

Those double stacked chips look like a work of art. For that matter the whole driver does. :beer:

I know, right? 
I bet Ouchyfoot cried when he saw that :weary: :slight_smile:

I thought of Of at the time and thought to myself dont go there. :slight_smile:

Almost worth it - I got bout 15A out of it now, but not the 17-18A I was expecting. Still, I got 5300 lumens in mostly a 3D tint. Adding a UCLp gave it a nice bump .

Is this the right thread for comments regarding Bistro firmware?
If yes: please forgive if I am asking dumb questions which have been answered before, the thread is far to long to read completly in reasonable time.
I am currently testing a bistro driver with cpu clock lowered to 4 Mhz, built into a S2+ triple, and so I also checked temperature control. It didn’t work as suspected, first I assumed a dependency to the clock change, but there was another reason in code: when over temperature is detected, the output level is ramped down 1 step each 8 seconds!
This means, coming from highest level it lasts 80 seconds to reach a FET output of 50% and even 160 seconds for 25%. My triple will be melted then.
Is this solution really expected to work with any smaller light pulling more than 3 amps?

Mike - this might be the correct thread. As far as I know, Bistro has no dedicated thread, so it's either this thread or the firmware thread: https://budgetlightforum.com/t/-/32545.

The bottom line would be asking the author - ToyKeeper, and her firmware thread would be the better of the two since she created the other one.

I just looked the code over and it seems you are right - 1/2 second delay in the main loop, then the "overheat_count", incremented by 1, has to be greater than 15 to do an adjustment, and when it does an adjustment, "overheat_count" is reset to zero.

So it doesn't adjust for 8 secs, then only will adjust every 8 secs or so thereafter.

Also be aware it adjusts one "level" per drop-down adjustment, and there are 64 levels defined for the full range of brightness/output.

All I can offer for my explanation is that Bistro was written for single LED DD lights in mind, for the BLF SS/Cu X6 or Cu X5 class running at 4-5A. Also I can say others have seen this problem and tweaked the algorithm. You can bump up the decrement factor or bump up the frequency of checks, and/or add intelligence to do it smarter. Dr Jones got his own PID algorithm implemented for temp monitoring, but has not released it to the public. I heard Atmel has a sample PID in source code as well, but will probably not fit in to a 25's 2K.

Yes - you are right about the 80 seconds. Here's the top 11 levels for FET PWM values:

129,137,146,155,164,174,184,194,205,216,255

I agree, a triple in a thin tube light is a crazy design when it's fully max'ed out. I would never put one in the hands of someone who is in-experienced with these sort of things. Bistro is just the firmware, and not designed for this intended use, accept for the fact it's given out open and freely in source code, so the designer of a flashlight can mod it as they like.

You also might want to consider a turbo timeout - set the timeout to 30 secs, and it drops one full mode, which could be down to 35-40%, depending on you mode definitions, but of course temp monitoring has advantages for more circumstances.

In my lights I’m using my own driver software anyway but this driver is used in mass production lights meanwhile, and perhaps it might be safer to implement a configurable turbotimer than a temperature regulation which won’t work with many lights.

Oops, was still editing, repeatedly.... Again I put responsibility squarely on the manufacturers. TK has not made a penny on the use of Bistro by the Chinese manufacturers. The BLF group buys are one thing - buyers know or should know, but when the manufacturers turn that into a commercial light, it's all on them.

I agree regarding the responsibility of the manufacturers but often I doubt they know what they are doing 


Made some progress over the weekend on implementing/adding a ramping mode to Narsil. Testing it in a SupFire M6. The ramping is pretty much fully implemented, but it breaks all the other UI stuff for now, til I work it all out, like the lock-out, entering configuration modes, displaying battery voltage, toggling the locator LED, etc.

I used posts on BLF by ToyKeeper and blueb8llz as a guide for implementing how it works. I'll be providing more details.

One note is I'm currently using 64 levels spread over 3 seconds to fully ramp the range. I tried 2 seconds at first, but could not stop at moon mode. With 3 secs, it's fairly easy now, but just not sure if 3 secs is too slow. Maybe 2.5 or so is bout ideal -- not sure. Certainly it's all touchy/feely issues, probably a lot of personal preferences thrown in.

Nice work with the black magic Tom. You be careful now. :slight_smile:

More progress this eve on ramping support in Narsil:

  • got lock-out working with same sequence as in non-ramping mode: 2 quick clicks followed by hold
  • got battery voltage check working same way also: 1 quick click followed by hold
  • got both modes of configuration UI working, again same or similar way as non-ramping, but for the main configuration setting, simply hold the button for 5.5 seconds, which is a full 3.5 seconds longer than a ramping sequence
  • changed ramp down - it stops now on moon mode instead of stopping by turning the light OFF

Still to do:

  • would like to get the locator LED toggling ON/OFF supported in ramping. Right now I lost that capability
  • need to add selection of ramping vs. mode sets to the configuration UI settings
  • might be on small bug to fix: after exiting lock-out, looks like 1st click is ignored, then all works fine
  • might see if I can clean up the LED output when in these special sequences (lock-out, batt voltage, config UI, etc.)
  • would like to get the ramping a little smoother look'n - right now a flicker is noticeable because it's changing PWM levels at 20 times/sec, whcih is somewhat noticeable. Would be better to adjust it closer to 100 times/sec which is possible.
  • might want to add in ramping a direct method to Hi/Turbo - possibly a dbl-click or triple-click

Overall liking the smooth ramping. Operation:

From OFF:

  • click to last level it was on
  • hold ramps up from moon to hi/turbo in 3 seconds, smoothly (currently 64 levels)

From ON:

  • click turns it OFF (this level is restored on the click from OFF)
  • hold ramps up, accept if it is on hi. If on hi, hold ramps down all the way to moon in 3 seconds, and stops there

It's simple and predictable, least that's my think'n... All the other special stuff is accessible by special sequences.

Thanks to blueb8llz and ToyKeeper for guidance, inspiration and support:

Ramping UI, Defined by blueb8llz (Ray)

Posted here: https://budgetlightforum.com/t/-/72707/10

In this thread on the Meteor M43: https://budgetlightforum.com/t/-/72707

It would need to be single click to turn the light on and off.
Hold switch while light is on, and ramps levels.
Hold switch while light is off, turns on moonlight mode.
Single click turns on light in last used mode including turbo.

Give me this ui, I promise to purchase at least two more units.

I’d really like to test your firmware with my current XHP50 SRK (I blew the driver past weekend so I’ll rebuild it with an attiny25)
I have an indicator LED around the switch so I can test this too.
Is it available for download somewhere?

Wauw Tom!!
Looks great and logical thus intuitive!

Very nice Tom E!
I might want to go with the “old” Narsil for my DQG due to the thermal issues. Maybe a cut down High would be better for my u.i., but this is definately nice for lights with normal cooling abilities.

I’ve ran into a problem flashing the X6 driver:

“C:\AVRusb>avrdude -p t25 -c usbasp -n

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1effff
avrdude: Expected signature for ATtiny25 is 1E 91 08
Double check chip, or use -F to override this check.

avrdude done. Thank you.”

Also with the -F function it doesn’t write firmware properly. I get the same signature error.

I don’t know how to use a .bat file yet, but I guess if a direct command doesn’t work, that won’t work either.

Am I missing something or could it be a faulty Attiny25? I’ve got another driver lying aroud, but before I brick both, I thought lets ask the BLF oracle in advance :smiley: