wight catchup

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. :slight_smile: :beer:

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.

Not into programming but I believe that the Wildtrail D80 (with the help of TheOnlyDocc who went MIA after that) uses Flintrock firmware and I think it works great and flawless :slight_smile:

Fair enough TA. It was a long a time, but, I quit working on it even longer ago. 1.7.1 was posted at Christmas of 2017, so 10 months earlier than your comment, and it still works. I developed in the open before that exactly to get this idea available for anyone interested and show proof of principle within a popular driver series, and ended up pressing on to make it actually I think a pretty robust build in that driver. Anyway, I didn't have anything against you in those days either, to say the least, and it's good to see you still around. The comment was a little sloppy, but it happens, so no hard feelings there.

Yeah, ok, that's not helping, the fact remains you haven't reported any bugs in the HD thread (at all actually), particularly that I didn't know about and already fix. ;) But you clarified that, so we're good.

I took it farther than I ever meant to really, and wouldn't be ashamed if there were bugs (probably is SOMETHING), just didn't like the appearance of vague claims without specific reports.

In fact this all started in the "attiny development thread," and I did post simple proof of concept codes or snippets there I believe, I could dig one up, but I'm sure Flashy Mike's above serves quite well for that. He was in the middle of it all. It might or might not encompass everything I learned (tested) about pin states, fuses, watchdog details, brown out corruption, keeping voltage sense levels above pin stated threshold, shutting down quickly enough, etc which is relevant to the next point, but I'm sure it does work properly. The fact is the principle is simple, but there are a lot of details that do really matter.

And on that note, to close the loop on a technical point that Tom Tom raised above. The cap is certainly not just a cap with a value. That's completely wrong. Many caps perform MUCH MUCH worse than their nominal specs at the temps we run lights at, which was the whole OTC problem to start with. I don't recall now if that's reduced capacitance, increased leakage, or I think a lot of both. A 100uF ceramic cap will do much worse than a 47uF tantalum cap as I recall, once heated. I tried a stack of ceramic caps I had as my first experiment. I ran real test on sleep power consumption, estimating current draw and times for pin state reads, ADC reads, etc, and checked capaciticance specs for real temps involved. In the end it's slightly overkilled indeed. I got over 10s (I think 12 even) of sleep at room temp, after optimizing a lot, figuring out the V-chip issue, pin state details, etc, but that's with only 1/4 second timing resolution and room temp. It will drop almost in half at 1/8s timing resolutions (twice as many wakes), and heat still impacts this cap too, just less. That said it's still certainly plenty safe, and I know lexel used some cheaper caps with some luck. I specced it for modders. If you're spending 10 hours ordering parts for building a light, no point saving $1 on a cap. I think the right way to go cheaper is just with a lower capacticance, tantalum cap, but even then, possibly not just any random one.

I also noticed you echoed the point about "universal drivers:

https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/Flintrock/bistro-hd/configs

It took me literally about 3 minutes to modify a configuration for the Q8 version (the last one I added), and it flashed and worked. It's what HD was all about. Of course it was still one UI, but mostly only because that's all I included.

I will be honest, I remember you working on the OTSM and I remember trying an early version that had some bugs. After that I remember you kept working on it but I could not keep up with the development and figured I would try it again after you had the bugs worked out and I worked on another clicky light.

Sadly that day never came since I only worked on e-switch lights after the GT and then stuff happened that caused me to basically quit flashlights entirely.

I had always planned on updating my EDC with a OTSM firmware but still have not felt like doing it since it works good enough for my needs as it is.

Rest assured, it was nothing personal and I did appreciate your work on the firmware. Life simply happened and I never had a chance to actually try the updated firmware.

Glad to hear it! This is what I saw. And again, it's not like my personal worth hinges on this in the slightest. I just felt a lot of things were getting said forming an image without an actual truth behind it.

Very nice, I was sent one of those awhile back when I was working on the WT90 and it does indeed work great! I always wondered what firmware/driver it used but never pulled it apart.

Actually, writing this all now, I do have to say, I wonder how well a tantalum cap would do for OTC... It would be a little funny if in the end the thing that made OTSM work would actually just make OTC work anyway. Still OTSM is far less finicky, not bleeder dependent, no calibration, etc, once you do setup the software details, so personally I'd still prefer it. But actually a tantalum OTC might do pretty ok.