A legend returns! Welcome back wight. Even though I joined after the start of your “sabbatical”, it seems like I’ve read (and re-read) so many of your posts. Thanks for your contributions thus far.
Also a welcome back. Heard quite a bit about you. I keep following along.
Good to have you back wight.
Yes.
In no particular order:
Thanks for the welcome back & for the flashlight & lantern links!
To all the folks who showed up during my hiatus: welcome to BLF 
I’m thrilled to think that anything I posted was still of use while I was away.
To all the folks who were already here - it’s really nice to see that you folks are still kicking!
I think that you’re confusing my builds with yours. 
There are several obstacles besides dangling. IIRC the ATtiny25/45/85 thread contains some work trying to compensate for temp & voltage. For 1s lights the voltage divider may no longer create a problem for the OTC, but for 2s lights w/ a Zener or LDO there will still be a voltage divider messing with drain on the OTC. I generally prefer to discuss things out in the open so that everyone can benefit, but with that said sometimes it’s easier to get the ball rolling in PM. Feel free to drop me a PM where we can get our thoughts together.
The capacitor recommended by Flintrock for the OTSM solution is expensive and it would certainly be nice to avoid it!
Thank you for sharing the PoC! Hopefully the idea will get more traction now with a compact demo available. :laughing: I don’t have a 25/45 right now, only 85, so I won’t be able to try it right away. I’ll try and pick up the necessary bits on my next parts order. Did you or Mike C look into component selection? Flintrock recommended a $1/ea capacitor w/ legs which looked troublesome for hand soldering/rework. A bulletproof offtime solution is worth $1, but less expensive is always appreciated, especially if anyone mass-produce a driver using this technique.
Boaz caught me. It was I who released that scourge upon the world. When my secret finally leaked I couldn’t face the forum for years!
The truth is that this was actually the situation long before I left. 
Still, there is a lot of bang-for-the-buck (as well as satisfaction) to be had with reasonable custom builds or customized budget lights.
Thanks TA, I’m glad that you carried to torch! I hope that I’ll do some cooking, but no promises on that front. Step 1: build a couple of working flashlights out of my piles of supplies.
Right now I’ve got to get my work space up to snuff. In the intervening years since I left the forum my flashlight stuff has been packed, repacked, moved, etc. I’ve got a new hobby area now but it’s been in use for (and is currently in use for) other projects. So in other words… right this moment I should stop reading forum threads and go clean up! 
I built my last OTSM drivers in early 2017 (focused on momentary switches now) and couldn’t find any notes :person_facepalming: so had to open a S2+ triple with this driver and see what I’ve used:
Found 2 added ordinary 100uF X5R ceramic caps, connected to GND and Vcc of mcu. I measured them about 160 uf together. The driver is a BLF X6 with Attiny25. But beware the BLF X6, there was a batch with reprogramming locked by fuse. I don’t know if Banggood made a change afterwards, I haven’t bought this driver since that time.
Btw - why do you think you can’t use the Attiny85?
I think they fixed it. As soon as I heard about it I sent a pretty strongly-worded message that they shouldn’t do that, for a handful of different reasons, including legal reasons (locking it violates the code license).
Some relevant parts of the license…
Flintrock’s OTSMC Build Instructions say so, see my excerpt below. (My 85’s will be 5 years old next month.) Thanks for cracking open your build to share the info/pics with us. What gauge magnet wire (enamel wire) do you use? I keep meaning to order some but then I’m indecisive about what gauge to get. I think that 30awg is thin enough to be a pain, maybe 26awg?
As you can see in my code, I haven’t used this BODS option at all. I’ve checked all my Attiny25 that time and there wasn’t a single one supporting BDOS. Its a pity that I don’t even remember why I used such a high capacitance of 200 uF, might be because I wanted to be on the save side with lowest voltages, or because I fused BOD even without the BODS option. Can’t read the fuses now since I locked that mcus after programming :person_facepalming: .
Anyway - I’m pretty sure your Attiny85 will work with OTSM and my code, at least without fusing BOD.
Regarding the wire: I’ve bought it decades ago, I guess at my local electronics store. I used it for my commercial prototypes that time. Unfortunately there are no specifications on the roll, only the price tag: 2.90 DM. This currency doesn’t even exist any more.
My caliper measures about 0.2 mm in diameter, including insulation, nevertheless this wire is pretty tough.
I also found a fix for OTC, odd but works
2S lights with buck or boost have caps making the OTSM tricky or impossible
Solution flash 1S firmware 1uF capacitor with 680kOhms in parallel
The key is to get the drain of the OTC decoupled by thermal variable self discharge which raises a lot on higher temperatures, also using X7 or even X8 caps in bigger physical size like 0805 which are a bit less temperature sensitive
I have tested and sold about 100 OTSM drivers with a differet cheaper 50 cents capacitor, basically the good infineon FET and MCU make about 2/3 of the parts costs of FET+1 driver design
Still the OTSM firmware on some revisions caused me problems and possible some hidden bugs still present
A cap is just a cap. In this application. Really. There is no special magic, and obviously the cheaper the better, as long as they are good. And store energy reliably.
BTW, other things can also do that nowadays, maybe better, and might be worth looking at.
Whether 100 uF is the right value, I don’t know, but it is a nice round number.
Bye the way, Flashy Mike has just posted some OTSM code that looks interesting. It is beyond my abilities to venture an opinion, but it already looks much more plausible than Flintrock ever managed.
I understand wight is back.
Welcome and thanks for the help before you left. 
As for the rest I’m confused but happy because I know wight understands.
“wight is back, (A bump to BLF’s IP quotient)”
What are you talking about? Flintrock managed a full-featured Bistro firmware rework with support for OTSM and OTC that has been used successfully by multiple members of this forum.
I may be mistaken, but I don’t think Flashy Mike’s firmware has similar levels of adoption, at least not at this point.
Go back to post #38 and read on from there.
Flashy Mike has only just shown us his code, so it’s hardly surprising that it’s not been “adopted” yet.
I see no problem in easier and more reliable OTSM code
if the Off detection works well enough 47uF is more than enough, the discharge down to 2V takes way longer than you ever need for medium presses
on Buck and boost drivers the off detection is a problem as thiose got input capacitors, not sure how this can be handeld, but it srewes OTSM often enough depending on hardware
Early versions simply had bugs. 1.7.1 has been perfectly stable (without modification), although not tested on a ton of layouts, mostly TA and Q8, and some others on the bench. But there are some incorrect statements here.
The OTSM implementation itself (or really hardware either for that matter) has nothing to do with the bare interrupts. I make it very clear in the comments of that interrupt that anyone modifying the code a lot should probably make it not bare. I make it very clear that it's not safe at all unless you know exactly how those modifications will interact with said bare interrupt at the machine code level. There's like a 10 line comment about this with BIG FAT warnings saying it's DEFINITELY not safe. Not sure how much more clear I could have been. The reason for those bare interrupts had nothing to do with OTSM, and the OTSM bare interrupt probably isn't even the most unsafe one (since it never returns). It had to do with getting OTSM and as many other features as possible to fit on an Attiny25 using a modified bistro code. It saved something like 50 bytes just in the OTSM interrupt alone, which may seem like not much, but it's enough to add a couple of features. 50 here, 50 there, you've got 20% extra space on these tiny machines. That's all. Use of better chips like the 45 was actually only just starting to be a thing as I finished debugging that code. The 45 was still bigger and didn't fit everywhere the 1616 and such simply were not in use at all then. The goal was get OTSM into a TA triple down version of bistro (I actually really like bistro, even on eswitch, still better than other fancier things, most of which came after I started that. For extended outdoor use, knowing exact power use can be very important, and bistro just gives known mode selection) on hardware in use at that time, without rewriting a firmware from scratch, and I did that.
Anyway, the OTSM implementation itself works fine with the interrupts implemented normally (just removing the bare attributes). The early instabilities around version 1.4 had to do with pin states and watchdog races, not the interrupts. But bistro OTSM is definitely based around a poll-and-restart driver, which is what bistro was. It's not how you'd do it in other drivers. For all the talk though, is there another clicky switch driver existing using OTSM with near the functionality of bistro-HD, even all these years later? Flashy Mike had a couple of nice things, and if so, great! OTSM is indeed hard to get right, but clicky switch lights do still exist!
Regarding separating UI code from hardware, that's a big part of what HD was about and why it built so many firmwares, each from a choice of hardware layout configs, choice of chip configs, and other options all selected in one master config for each version. Not every single thing about the chips was abstracted, but as I supported more chips, I abstracted more. I remember thinking the 1616 would requiring abstractifying a couple of more things, where defaults could keep the old configs working fine, but I never had time for that. when I started HD, other firmwares were not doing this much. Narsil might have been, not sure exactly when it started or how much it was doing that yet. I love what I'm seeing in that regard now with the direction Anduril (2) has taken as well though.
I'm kind of remembering why I left this place, although to be honest it was just a couple of nasty people. Tom Tom was on top of the list, and wow, felt the need even to insult me unprovoked above when I wasn't even here, but that's exactly how I remembered him. Oddly he's attacked me before in conversations where we were not even interacting. I don't recall it ever being in regard to something that even involved him, or his work. It's just weird. I exaggerate the significance of that though. Mostly I just left because of my own time.
Anyway, bistro-HD still operates clickly and even e-switch lights just fine years later on attiny25/45 (and mostly like now 85 as the V versions should be available now) and it's still easy to configure on different hardware layouts, and already configured on most.
I appreciate the appreciation. Flashy Mike actually implemented a proof of principle of OTSM before I did and his implementations were indeed nice. He and I and a couple of others (Mike C I think and Texas Ace some, more regarding goals) collaborated on initial brainstorming of how to make it all work, and it probably wouldn't have without him. I knew about his methods, as I recall using the ADC and I posted some of my own tests on similar methods (I did a LOT of tests of real power usage, etc, the super long sleep times lexel mentions are a result of that and optimizing the method). There was a lot of discussion between us. In the end it mostly came down to what worked well in bistro, with best power efficiency and the smallest code, without rewriting it from the top down (I ended up rewriting it from the bottom up, but in incremental working steps). Anyway, I recall he had some things working very nicely. I had/have nothing but appreciation for Flashy Mike and his work. He's credited in bistro-HD, and for very good reason!
I also learned a lot from a lot of wight's old posts!!! Maybe some year will be around at the same time, but the information stays.
Since this somehow largely turned into a beat on HD thread, I will clear up a couple of other bits of history here. Lexel above accused it of being a pain to use but at least three of his complaints have been tracked down to his own mistakes (in fact all known non-addressed issues were), including one where he failed to count to 20 properly when defining his own new modified 20-entry ramp table. The most disappointing is that Texas_Ace also piled one on above, and yet in spite of encouraging this project from the start I never once saw where he ever flashed it, and any bugginess he's referring to was not mentioned in the HD thread, just in off-hand comments like above, without any clear reference to anything specific. That seems odd and unproductive, and frankly out of character for him. If someone else does work that you encouraged and you want to criticize it, maybe actually try it at least and leave constructive feedback. Just leaving vague derision in random places seems kind of low-ball.
First, this thread is from 2018?
Second, where did I “pile on”? I have always made it a point to not attack anyone and even if I didn’t have that policy, trust me, there are people that would of been WAY ahead of you, I always liked you. lol.
If you are referring to the statement I made about the firmware in 2018 being too buggy, keep in mind that is a statement from 2018 and far as I remember the early implementations did in fact have some bugs at the time. There were several versions of firmware floating around trying to solve the issue as I remember, I have no idea which one I was referring to at that time.
Also keep in mind that was about the time I built my last clicky light, I never did anything else with it simply because I never worked on another clicky light. To this day I swapped some LED’s in my EDC and that it the most “modding” I have done since pretty much when that post was made.
Remember, I was working on lights destined for production in factories, even small bugs were a quick way to cause massive issues in a production environment so I was forced to be picky.
I am SURE it is working by now, I just don’t mess with flashlights anymore. I always thought you did good work, there are always bugs in the early days. It was nothing personal if I was even referring to your firmware.
I am sorry if I gave you the wrong impression or slighted you in some way, that was never my intention.