Attiny25/45/85 FW Development Thread

Very nice, Tom :)

I haven't used the latest version yet, but will be putting it on the next '85 build I do.

Thanks again for making this available to everyone. :beer: :beer:

It's the same firmware renamed - little catchier and simpler Smile. Current size is about 3600 bytes. Latest updates:

Three changes, minor updates to the manual:

  • make lock-out easier by shortening the hold time which eliminates activation of strobe. It makes it easier to confirm if lock-out is set, because if strobe does activate, you know lock-out is not set

  • change the blinks for entering a setting configuration mode: it now blinks quickly twice, followed by slow blinks of 1 to 5 (1 for first setting, 5 for the 5th setting). It makes config mode slower but easier to track what setting you are in

  • add a long hold to exit configuration mode. A short hold will skip to the next setting, but if you continue to hold a little longer, it will exit altogether, indicated by 5 quick blinks

I don't know if any of you watch NCIS, but if you do I think you'll get the reference:

NCIS - McGee the Elf Lord - YouTube

I nominate Tom E. as BLF's Elf Lord.

Very cool and very generous of you to share your FW Tom E. Looking forward to trying it out. I've been struggling to get in mod time for some time now. I hope to try it soon.

Thanks . For Richard: go kiss an orc... "The time of the Elves... is over"

Might just be me but how to change modes when on?
Lets say, its in med for over 1.2 sec (its locked-in), how to go to the next mode?
Do you have to click and hold to cancel the lock-in and then click to switch modes?

Think yes, you are correct. Since the 1-click turns it OFF, you can click/hold to go to previous mode, then click to go the next, click->next, etc.

It's all a matter of priority - I chose to make 1-click OFF the priority, but I believe Werner originally had it working where changing modes was priority. You can change this behavior, if you like, and have it work without the mode lock-in feature - change the following from 1 to 0, at line #296 in Narsil.c (I think this should work - might not have tried it though...):

volatile byte byLockOutEnable = 1; // button lock-out feature is enabled 

+1

There has been a lot of work on this thread experimenting with bypass capacitors, but I did not see anything done with FET selection. Perhaps a FET with better dynamic switching parameters would alleviate most of these issues.

It looks like Mitko has gotten outstanding results on a FET he found. To me, the packaging looks like a SIR800DP, but I can't find it anywhere around.

Post #615 here: https://budgetlightforum.com/t/-/30080, data sheet: https://store.comet.bg/download-file.php?id=7648

Talked about here as well: https://budgetlightforum.com/t/-/35815

If anyone can find it, please post. Mitko was seeing 5-8% bumps on amps, and he mentioned they were even pretty cheap. Dunno about any side effects though.

For those who can shed some light on it, please check out the data sheet. I'm thinking there may be an equivalent sold under another name/part # somewhere.

The big deal for us is the amount of gate charge at a given gate voltage. Usually, the lower RDS on FETs have a higher gate charge. We are switching relatively slow (<20 KHz) but we are are also asking a lot more from the MCU than it was designed to do. We get away with it most of the time in the name of compactness and simplicity, but it would be best if there was a gate driver, even a makeshift one, that drove the FET gate. I have experimented a bit with this, and while it does work great I don't think that it is necessary to add the extra cost, however small, and complexity to these drivers.

Since we aren't really pushing the thermal dissipation limits on these FETs in the partial duty cycle modes, I think that adding a gate resistor back into the mix may be the easiest solution. This will ease the load on the MCU and we don't really care if the FET spends a few more microseconds in the linear region with the loads we are switching with them.

The way I see it is that we want highest amps at low cost and stability. It is not surprising that all three cannot be met without design changes. I’d say that only two out of three goals are possible.

  1. high amps and low cost but low stability (current design)
  2. moderate amps and low cost and stability can be achieved by inserting current limit resistor or FET with higher RDSon or gate resistor
  3. high amps and stability can be achieved by redesigning the board for better power distribution and filtering (power plane and bypass caps)

An analogy I’d like to make is building your own PC. Pairing a budget motherboard with a maximally overclocked CPU will result in an unstable system that reboots under load. Upgrading the motherboard can give you higher speed and stability but cost more money.

Ahhh - I really don't know what a gate driver is, but there is a real problem here -- both on a SupFire M6 (triple) and a single 219C light running a Tiny85 at 8 Mhz, the MCU was having all sorts of problems. The small cap seemed to have solved it for me. For the M6, I was using a 22 mm wight FET+1 driver, so plenty of room extra pad for the cap. For the 219C EDC light, wiring the cap over the MCU isn't a good solution, but it worked.

So you think the gate resistor would work? I can't recall now, but though I had a gate resistor on one that was failing -- I could be wrong. I've been pulling off the 10K-22K gate resistors I had on there, because I was using them previously thinking they would/could solve the flicker problem when going from hi to moon, but they made the flicker less bright, but it still occurred. The firmware change is what really fixed that problem, so, I thought they are no longer necessary.

Richard - I've used two of your 85 FET+1 drivers btw (MTN-17DDm 85 v0.01), both in 18650 EDC tube lights, but the LED- pad is a problem for sure.

How about trying 4mhz?



CLKPR divides the clock.

6.5.2 of the datasheet, page 32-33.

This should do 4mhz if I’m not mistaken.



// special procedure required to change clock prescaler

cli(); // Interrupts must be disabled

CLKPR=(1<<CLKPCE); // Enable clock change for next 4 cycles

CLKPR=1; // Clock/2, 4mhz

sei(); // Re-enable interrupts



I have not tested this. My lights aren’t having any problems and my tiny85 is in use.

Reducing the clock also reduces power consumption. :slight_smile:

Hhmm, I should try it. So I assume you still set the fuse(s) for 8 Mhz? The PWM's would be 1/2 the speed they are now at 8 Mhz? Think the clock is shared?

Yep, leave the fuses set to 8Mhz. It divides whatever the clock is set to in the fuses. Except the “Divide clock by 8 internally; [CKDIV8=0]” fuse. That fuse actually already uses the CLKPR.

The CLKPR should affect everything. It changes the clock entirely.

Didn't try the clock yet, but ran into yet another 85 FET+1 driver that had the same flaky problems, but with a single XM-L2. This time, it seemed to only behave bad with a LG MJ1 cell (3500 10A). Other cells, like a 30Q worked fine. The cap between the 85 grnd and Vc pin did the trick once again. This was in a swm C20C using RMM's 85 FET+1 driver.

I tried 8 MHz, 6.4 MHz, 4 MHz, and 128 kHz. They all had the same power spike issue. However, at least slowed down to 128 kHz I discovered that it seems to reset on the trailing edge of the strobe pulse instead of a leading edge. So it seems to reboot when the FET power is turned off.

I also tried each brownout setting but it didn’t seem to make any difference.

Oh, and after flashing at 128 kHz, it doesn’t seem to want to be flashed any more. Anyone have any idea how to recover that?

You have to slow down the ISP clock rate (to < 1/4 the CPU clock rate?)

I use a STK-500 for programming… don’t know the magic word for avrdude to change the clock rate.

With USBasp, try bridging JP1 that enables slow SCLK.

I tried -B and -i for avrdude, but it can’t set SCK on this usbasp. I think it’s a newer one which does it “automagically”. I tried bridging JP3 and it didn’t seem to change anything. I think JP2 is its self-programming jumper. JP1 is used for 5V/3.3V select, and doesn’t help either. I could try to update the usbasp firmware, but it requires extra hardware I don’t have.

So, no luck yet.