Attiny25/45/85 FW Development Thread

Welcome Back!! You were missed! A scope on the signal lines sure would come in handy for this, I don't have the tools. Had success with the extra caps though, and definitely we've had some great help going on with texaspyro and DEL stepping in.

Not sure if you read it, but I finally got a good fix to the hi->OFF->moon flashing problem -- with that sequence, many times got a quick flash when moon mode starts. It looks like it's 100% resolved now in my latest firmware update - I solved it in code, not hardware, explained above somewhere... I've seen this flashy thing happen on power tail switch's too - wonder if it can be fixed in a similar way. Haven't looked into it yet.

On the high amp problem (caps), I believe TK has been getting the same reports coming in on her 25 based driver. Not sure if she is following this thread though.

Sort of agree - I'm leaning towards the bent pin solution being what we can do with our small runs, hobbyists, etc., but not a solution for large runs going forward.

RMM wrote:

I've been away from this game for far too long; it's time to jump back in again. I had to force myself away just when things were getting interesting around here so that I could focus on some of my "other work".

The layout on that 85 driver I did really stinks...way too much space around the MCU, but I figured that it would be easy to flash the thing a million times. It looks like it also needed a bodge capacitor to work right. I guess I should have labeled it "alpha".

I haven't read through everything here, but a capacitor underneath the MCU sounds like a really bad idea unless you like tedious leg bending and soldering on every driver. I'm sure we can make it work without resorting to stuff like that.

If space is needed, I think it's good idea. I bend all my 85 pins anyway because they clip some much easier and the clip holds much more securely. If you haven't tried it, you should.

Another benefit of the bent legs is the MCU sits more proud and you can put resistor right up to the legs without programming clip interference.

I wonder if we really need LED - pads when the FET Drain tab available to solder to. It's nice to have a spot that is labelled and a spot that will fail first from mechanical stress, but is it really necessary when space is short?

Pyro1son,

The FET Drain Pad and LED _ Pad appear close to shorting with the pill. It's probably fine, but it looks like the FET could be slid closer to the ground ring edge.

I have dealt with the issue on a lot of drivers and have scoped it when it happens. Usually from a 3.8v-3.9v supply you'll see a 6V+ peak with 2V-3V peak-to-peak ripple (BAD). They actually run with a really dirty supply but when you get them up past 5.5V-6V it's going to have some issues. We are really pushing the MCU pretty hard switching these low-RDS but high-gate-charge FETs directly from the MCU pin, especially without any gate resistor. You can end up with either too little decoupling or if you have the cap. behind the diode you can get quite a bit of boosting. You also get a lot of ground bounce from the FET switching. There are a lot of layout tweaks that can make them run without expensive or extra parts.

You do absolutely need at least a small LED- pad if you want to use anything but an LFPAK56 FET. The SiR800DP, for example, does not really work without some extra exposed pad out the back. You can sacrifice it if you only use an LFPAK56, but I know that quite a few use the SiR800DP and it has proven to be a top performer.

Think you really need some pad space for LED-, at least with the SIR800DP FET - there's nothing on the FET there to solder to. That was my issue with Richard's board.

I’ve moved the FET away from the edge and the 2nd CAP from under the MCU as I just don’t like the Idea. I would rather just put both caps on the bottom of the board.

I'm liking it Smile. Nice to have a pin #3 pad.This last one is still with a 13A footprint, I believe. It's still a lot to squeeze in.

I'm think'n we'll need it both ways - one design with the full 45/85 footprint, and one with the 13A/25 size. I'm thinking Richard will be working on a design as well.

It’s definitely a squeeze with the 85 footprint

Nice looking board.

Thanks for the info on the SiR800DP guys. I haven't been keeping up on FET's.

Should be noted - this happened to me twice already. The 380 7135's seem to want 5 as a PWM value at a minimum (moon mode) - not sure if this has to do with the faster PWM rate of PHASE correct mode on the 25/45/85's when run at 8 Mhz.

So what I'm using now is using 3 for 350 7135's and 5 for 380 7135's as a standard practice. The 5 on a 380 may even be lower output than a 3 for a 350.

Also, I made a change in the firmware that was annoying me. For going into lock-out with the 2 clicks, then click/hold, I made the hold time shorter so you don't have to see that annoying strobe. So basically instead of strobe for about one second, you get the 4 short blinks - much more pleasing, easier to enter and confirm you are in lock-out. I checked the manual and didn't see an impact there - I didn't get too specific on hold time in the manual.

Update, more changes to the firmware:

Couple more things that kind of bugged me:

  • losing your place in the configuration settings. With 5 settings, hard sometimes to track if your are on setting #3 (mode ordering) or #4 (mode memory) for example. So, I now do 2 fast blinks, then blink the setting # when entering a configuration setting. When you get to 5 of course, it takes some time to do 5 blinks, but hoping it's easier to track now.
  • No way to completely bail out of configuration mode - you can skip to the next setting by click/hold, but still takes a while. So, I added a long hold option to bail out completely. So in configuration mode, a hold of about 1/2 sec skips to next, while a hold of 1.1 secs bails out, signaled by 5 fast blinks. I increased the config mode exit blinks from 3 to 5, since they blink faster now.

Not yet posted... Will be doing more testing... Once again, the SupFire M2-Z light is working great for re-programming/testing Smile. Thanks Richard!

Hi all,

Just want to start by saying thanks to everyone putting time in on this project.

I have an idea about making some extra room for component placement on this driver. I dont know anything about running the electrical traces so if this sounds dumb please forgive.

What if the foot print for the larger micro 45/85 and the FED were put on the bottom ( the spring side) and all of the other components were put on the top. The work around for loosing the spring pad on the bottom could be mechanical.

The battery + could be a large via in the center (like in some of the above desings) that we could either just solder a rivet into or use a machined part with a larger top that a spring could be soldered to.

Like this.



I would think the top components could then be reflowed on and the bottom 2 could be hand soldered easily. Plus if only the rivet was used for the + contact the micro could be reflashed without unsoldering the driver from the pill.

Copper rivets are cheap too, a box of like 250 is ten bucks.


My 2 cents....

Interesting... You lose a little clearance in the battery tube, that's bout it. Not sure bout the rivet parts - best metal, etc. It gets away from the single sided driver, but at least we'd have room. I do a lot of piggyback'ed drivers still, and for those, the parts and spring would not be necessary anyway.

If you’re going to have components on both sides and want as much space as possible, just do this:

Those copper wires are solid and clear the MCU, at least on the drivers I’ve built with this method. It maybe a bit more work than your solution but by centering the MCU I not only have more space for components around it, I can also flash it without ripping apart the entire light.

The driver in the photo is 23mm but I’ve designed and built 17mm drivers this way, works like a charm as long as the cells are button top or have solder blobs on them. On some lights it might be a tight fit, but I haven’t had size issues with any of mine yet.

Narsil is here - click on the sword to get the manual:

Get Narsil firmware here, folder link that includes PDF of the manual: drive.google.com - ATtiny254585Support

Taking up the handle-shard of Narsil after his father's defeat, Isildur cut the One Ring from Sauron's hand, defeating him.

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