Ahh, yes. The only down side to the 25's now is the cost, but I really haven't done much shopping around yet. Mouser is a killer for shipping and NYS taxes, so $30 becomes $40 easy. Dunno yet where to go next. Would like to get temp sensor working, but also would love to get what I have now into a X6R, Convoy L4, Warsun X60, Y3, etc. We know of course, temp sensor and 25/45/85's have been implemented by or for BLFers, but no one apparently has posted any helpful details - obviously could be good reason why they can't, dunno.
That is the larger size. You would need to bend the pin down slightly for most drivers, except the 22mm DD+7135 wight driver board. A direct drop in would be the SSU package on other boards/drivers. If you are willing to use the larger SU package, you can get 10 for $16.20 here:
http://www.ebay.com/itm/201060737002?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
These are what I'm using. They seem to work fine. As of last night, I have 3 of them up and working in different types of drivers. Of the 5 I have connected to a programmer, all 5 successfully connected..
Well at least it looks like it's worth looking around. These are the 25's with the same package as the 13A's:
ATtiny25V-10SSU (I ordered these from Mouser, qty 10 for $19.50, total order: $32.64, total payment: $39.63)
ATtiny25V-10SSUR
ATtiny25V-10SSH
ATtiny25V-10SSHR
In the same Mouser order, I also ordered qty 3 of these: ATTINY85V-10SU for $2.42 each.
Just doing a search on the SSU part # on AliExpress found qty 10 for like $13-$14 which is a pretty good deal, just hope these haven't been pre-programmed with the reset bit set as an I/O pin - this happened to me for a qty 10 order of 13A's on eBay.
Tom E wrote:
I tried combining my e-switch version with my NOINIT (power switch) in order to get full functionality on both switch's, but ran out of code space. I just ordered a few ATTiny45's - they have 4 * code and data space. There's been some successful porting effort goin on, so hoping I can get these up and running.
Update: Mission Accomplished! Got it working now on a ATtiny45. Some details here: https://budgetlightforum.com/t/-/34900, post #115.
At the above link, Tom E wrote:
. . . I did get brown out detection OFF time method working, and it's working in the eswitch version. So, I have firmware that is 1074 bytes running on a 45, about 26% code space used, and has a fully functioning power clicky switch support with mode memory and OFF time support, as well as full e-switch support! Best Of Both
. Dang, this is getting easy...
Using that Fuse calculator too, I am using these fuse values to enable this combo of features:
-Ulfuse:w:0xE2:m -Uhfuse:w:0xdf:m -Uefuse:w:0xfe:m
Basically, I melded the STAR_NOINIT stuff into my eswitch version. This is where I ran out of code space before, and why I got into the 25/45/85's, specially since ImA4Wheelr got it basically up initially.
For the fuses, I analyzed what was done for the full brown-out detection, and made the same settings for the 45 family. With the Fuse Calculator, it was pretty easy to do.
Really sounds complicated to combine those functionalities. Would love to try in a couple of lights if you at a point you wouldn't mind sharing it. Could it be used in a e-switch light to assist with lock out? Something like, the light can't be turned off with the momentary switch. Would force user to "lock out" to turn off. That way, the risk of forgetting to lock out is significantly reduced.
I wouldn't mind posting it as-is, just that it hasn't been tested in a light yet, so thought I'd wait, but of course, couldn't get to it as soon as I hoped.
It's here, ZIP'ed: Google Drive shared folder, file called: switch_NOINIT.zip. Let me know if you can access/dnld it ok.
Well, then it would work like a L4 (I believe), and that's what I was trying to avoid. My goal was full functionality from the side switch. If you can't turn it off from the side switch, it's not fully functional. I agree it would help from forgetting to lock out the light though - good point, but I would not want to sacrifice ON/OFF because of that.
Update:
Just installed it in my X6R. Swapped the 13A out for a 25V on the piggyback wight FET+1 driver, and it worked out pretty well - used a hot air gun, and the one I got doesn't target a part well, so other parts loosened up but didn't move around. Reflowing did the same thing. What I did was used solder wick to remove the old solder off the pad, then applied new solder paste - think it works out better this way.
Not sure what happened, but didn't find the fuse settings I used in previous testing (or messed them up??). I used these on the 25 and seems to work well:
-Ulfuse:w:0xE2:m -Uhfuse:w:0xDE:m -Uefuse:w:0xFE:m
Also, the brown-out NOINIT timing is a bit long. I would prefer it quicker - you have to have the light off for maybe 1-2 secs or so for it to keep the same mode.
Do you have an offtime capacitor on that? If so, make sure it isn’t charged, and the noinit thing might speed up. But then, if you have an OTC, it’s probably better to use that instead of noinit. 
True . I think I'm using the OTC pad to solder the e-switch wire to. It was bugging me a few mins ago - couldn't recall if there's some setting brown out detection could work off of. Thought it worked better, maybe PCB design dependent - not sure.
Ohh - I set turbo timeout to 90 seconds and timed it on the bench with a TrustFire - was somewhere between 90 to 91 secs on my stopwatch - impressive! Wonder if it works more accurate configured at 8 Mhz. Only choices for internal clock is 6.4 Mhz and 8 Mhz, at least in the fuse setting app.
So, this was a 25V SSU (same package as a 13A) on a 17mm wight FET+1 driver. Didn't realize the X6R's tailcap switch is a fwd (tactical) clicky - works well, interesting...
Thank you Tom E for sharing your latest WIP. I as hoping to install and try it out this weekend but things came up. Hopefully, I will by the end of the week.
Ok, no prob. Couply of things for you and T_K (anyone else for that matter) on eswitch_NOINIT:
- e-switch and power button share the same mode table, default is 5 modes with 1st 3 modes using the 7135
- strobe is not accessible from the power switch - it's not in the table, special only for the e-switch
- changing modes on the e-switch does not effect the stored mode, so the power switch saved mode is unaffected. I'm not sure if this is a good thing or bad thing, might be more confusing, but seems nice for some usages like tactical - you can program the power button to come up in Hi/turbo if you want, then change modes from the tail, and that will set a new default, including OFF. For now, I'm gonna leave it this way but not sure if this is the best. Might make a nice user configurable option.
I'm also thinking about more functionality, like using the long press to get strobe now, but treat is as an advanced mode set, so another long hold might be battery check, slow strobe, beacons, etc. A good thing I could do, for safety, is if the e-switch is permanently stuck, I could cycle thru the advanced modes and end it with OFF.
Exciting stuff Tom. You rock! I'll be happy to start helping work some more on the temp. sensor stuff, but it's got to wait until next week.
Tom, you keep putting things on my todo list.
Have you ever tried using git/github or bzr/launchpad? They’re pretty helpful for tracking and generally dealing with code.
We use Git @work, but we have our own server repository. Been using github, but not for my own stuff. I know, really should... I gotta get better organized, overall. I'm off in way too many directions.
Awesome, so it shouldn’t be a big stretch.
I really need to spend some serious time with git. It’s functionally almost identical to bzr, but everything has different names and options and defaults. And git officially won the DVCS wars, so I should get on board with it. Even Launchpad supports it now, though it’s not widely used there yet.
Followup and new find if interested folks
https://www.fasttech.com/products/0/10012070/2056803-sop8-to-dip8-programming-adapter-socket-module
And a 16 pin one
https://www.fasttech.com/products/0/10012067/2056800-sop16-to-dip16-150mil-programming-board
Thanks to the input of several in this thread I was able to manipulate the code for a 5 hour shutoff on a light using the STAR firmware.
I recently had the timer fail. Instead of shutting off as usual, the light kept running.
Any ideas why something like this would happen?
This was on a light that you had tested working previously? A momentary power glitch or inadvertent MCU reset would be enough to reset the timer.
That’s a good point. It might be a good idea to add a “noinit” attribute to the timer variable, and only set it to zero on boot if the offtime capacitor (or noinit-based offtime sensor) says it was a long press. This would allow the timer to keep counting after a short press or brief interruption.
RMM - yes this the timer on this light had been working. Since I posted yesterday it has failed once again. I’ll test again today to see if it continues to fail.
Toy - as always thanks for the suggestion. I may reach out for a bit of clarification on the specifics of implementing this.
I’ve flashed another circuit with the 5 hour timer for testing and have also had this one fail once in about 10 cycles.
Any additional thoughts here?
Many thanks