Attiny25/45/85 FW Development Thread

I have!

I sucked it up and replaced the resistor on the driver. It works just fine, now my off time cap measurements are all good, slow charging issues are gone. So for those interested, with the ATtiny25/45/85 the same voltage divider resistors can be used for both single and double cell drivers as long as you switch to the 2,56V for internal reference for double cell readings. I used the option without the external capacitor (page 134, table 17-3 in datasheet). You might have to do some sort of calibration because the datasheet specifies that the 2.56 vRef varies from MCU to MCU even more than the 1.1 vRef does.

I’ll test weather I can stick to 2,56V vRef for single cell drivers too, because if the readings are good enough after calibrating I will be able to clean up my code a little by removing a few #ifdef definitions.

Interesting, that’s all good to know, but not sure I understand how this helps or what problem it’s solving. A 1 cell driver and 2 cell driver have to be different anyway in hardware? You have to use a zener (tail switch) or LDO (e-switch) for 2 cells anyway, so not a big deal to use different resistor values for the 1.1v ref? Plus the complication of extra fine tuning for the 2.56v ref?

It solves my issue of slow cap charging times because of too high R1 voltage divider resistor. I was having issues, I asked a question, then tested and posted the answer. But lesson learned, I’ll just delete the question the next time.

Ahh, no problem. Sorry, didn’t understand - what was the impact/effect of the slow cap charging?

Quick short presses just after turn on where measured as long off presses, and my normal long off presses where being measured as cold starts. I had to wait a short moment before doing mode changing. It was annoying enough for me to attempt solving.

Maybe I’m being slow this morning but with both higher voltage and higher R1, shouldn’t you end up with roughly the same current and charge time?

Ohhh, ok. I’m not a fan of OTC’s use for short/long presses. Just don’t see enough consistency. e-switch’s solve all of that.

That’s what I thought when I decided to go with 2M7 R1 resistors… but it gave me issues. Maybe because 2M7 is a little more than double 1M2? Issues are solved anyway, and now I don’t have to have a stock of separate R1 resistors.

Short and long are fine for me. Perhaps more stable because I have calibrated the voltage readings and use actual voltage levels as short/long off times? I don’t know, but I have consistency with both fully charged and almost depleted cells, and heat doesn’t have much of an impact on the components I have used.

E-switches don’t solve anything if the light doesn’t have an E-switch.

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.