Offtime-no-memory is my favorite configuration. 
Basically, I set it up so that a short press goes to the next mode, a medium press goes to the previous mode, and a long press goes back to the first mode. It thus always starts in the first mode, and can navigate in two directions. If the user goes backward from the first mode, it enters some semi-hidden ānegativeā modes like turbo and battery check.
Just tried offtime-no-memory. It is exactly what I am after. The general public would probably appreciate that simplicity, I figure.
Iām using a low of ā6ā with fast pwm. Seems to work pretty good. Is there a limit to how low I can make low before there is some kind of issue?
The lower limit depends on hardware. Driver, LED, and [potentially] input voltage.
In general, for a nanjg driver with current-gen LED the lowest is about 6 (fast) or 4 (phase). For a FET driver the lowest is generally about 1 (phase) or 0 (fast, with some caveats).
It also depends greatly on the number of 7135s (the higher the number, the higher the stable PWM value), the batch of 7135s (they vary from batch to batch, and even within batches), and whether the 7135 is a 350mA or 380mA (350mA can generally run at a lower stable value).
Is reverse polarity protection something that is physically built into the circuit or something that is handled via firmware? Doing a S2 build for my wife with a 105c and STAR and wanted to make sure that it stayed in.
Thanks
Itās physically built in. Itās a diode.
Many thanks.
Is this version posted in your repository? Think I went look'n - not sure I could locate it. So... Are you saying you are using 3 level values for reading the cap to determine the short/med/long press's? If so -- is this reliable? Standard value OFF time cap used, etc.? If it's reliable, wouldn't JC incorporate it into this? Maybe he doesn't feel confident, or maybe just no time to do it yet, or maybe he doesn't care for this feature?
If it's a mod of JC's OFFTime, is it based on his latest 1.3 version?
This sort of seems like it works like the "werner" style e-switch firmware. I make the long hold do a strobe typically. I think the OFF time style med and long press's though would be a little more tricky/finicky then a simple button hold for an e-switch, maybe?
Only a couple of questions.... 
I havenāt used it, but I just canāt see the short/long press navigation being half as user friendly as an e-switch. With the e-switch you do a long press by holding the button until something happens. You do a short press by hitting it and letting go. Both pretty straightforward actions. Now when it comes to āhow do I turn this thing off?āā¦ the clicky may have an advantage. 
Iāll still give this business a try, I want to see what itās all about.
wight - yes, agree: think the e-switch would be more user friendly. In "my special" e-switch version, once you lock in a mode (like 1 sec or so), one short click turns the light OFF - best solution I could come up with . I had to have a 1 click OFF UI and this seemed to be pretty easy to implement. VOB loves it - got maybe a couple other BLF'ers using my e-switch version around... I really though it was super clever/cool/nifty, and I don't say that bout much I do lately...
A side effect function of this, is if the light is ON and locked in and you do a button hold, the previous mode switch will still work, then you can go fwd in modes with short clicks until you pause/delay again to lock it in. So, even thoug you got a simple 1 click OFF, you can still navigate through all the modes without turning the light OFF (unless you are already at the first/lowest mode already).
Edit/Update: Dang wight - forgot... Just built a S2+ shorty (18350) using a triple XP-G2 3C and your 17mm DD driver (A17DD-S08) with JC's OFFTime latest driver - came out really sweet!! Love your DD drivers for having the clean spring side - simple with the Convoy tube lights. I even scraped off around the spring pad to widen it so I could use the stock spring the S2+ host (from RMM) came with -- again, simple and sweet! Thanks Again for these great driver designs!!!
I haven't given it a shot yet. Sounds pretty cool, but for me I only ever have 3-4 modes, so it's not needed. I'm at max capacity on STAR_off_time, so features would have to be disabled in order to enable this. I think just having ToyKeeper's custom offshoot is the way to go, unless it really is that intuitive that everyone would want it.
Ohh - I used your latest STAR-Off_time verison for the 1st time and got a bit confused over "DUAL" PWM support. I finally figured it out after seeing how the conditional compile switch's were being used, but would have saved me time if I could have understood it better from the descriptions/docs. I was thinking DUAL PWM mode was phase controlled and fast, as opposed to DUAL outputs, so had me going for a while...
Also, maybe it wasn't so clear to me, but finally understood it by again, going through the code. I think in the prior versions TURBO would knock down to the previous mode in the mode table, but now, it knocks down to a set value, not in the table. I definitiely prefer the way you have it implemented now. I always thought the TURBO step-down setting should be an accessible mode and take up another mode setting. Think the BLF SE X6 driver works the old way which I can't stand - seems a waste of a mode, more clicking, etc.
Yes, itās in my repo. Itās ToyKeeper/cypreus. However, that version is a little complicated and I need to make a simpler branch which is closer to STAR. It was originally based on an older version of STAR, but I did a lot of weird stuff to it (like a PFM self-adjusting moon mode for FETs, and lots of blinkies).
The timing and behavior is actually pretty reliable, and not terribly difficult to use. I ended up with values of 190 and 100 to differentiate between short, medium, and long presses (< 0.5s, 0.5s to 2.0s, > 2.0s).
In any case, when I have hardware again in a few days, Iām hoping to make a more generic version which is easier to configure. I may even be able to add some things into STAR, but itāll require making room and that might not go smoothly.
I do very few builds myself, I do plan to try out your UI absolutely ASAP on my next momentary build. The first time I heard it described I was uninterested. The next few times got the wheels in my head turning a little.
As far as the dual-PWM functionality in STAR, part of the reason itās confusing is because both of the features were merged into mainline at once: the ability to use both fast and phase correct PWM in one firmware as well as the ability to output an āaltā PWM signal on an extra pin for the āmoonlight specialā style drivers. JonnyC has packed a bunch of great features in here at this point, but thereās limited documentation as to the what/why/how of using them. Iāve been thinking that I should do a writeup on how to use the firmware, complete with all features and whatās required to take advantage of them. So far Iām just too lazy.
Iām glad that the driver is working well for you! If you have thoughts on how large would be ideal for the default spring pad, please post over in the driver thread. I chose pretty arbitrarily. Iāve been thinking of doing a different kind of spring pad pattern in order to make it easier to center & solder different springs, but in the meantimeā¦
I made a couple 1-click-off firmwares for e-switches, under the Ferrero_Rocher dir of my repo. Iām curious what you think about them.
One does a smooth auto-reversing ramp on long press while the other does a stepped looping ramp. Both give instant access to min, max, and the last-used mode from off. One also includes a soft lockout mode and takes moon out of the main mode sequence (Baton).
Itās hard to include lots of extra blinky modes with an e-switch though, because handling the e-switch takes more room than a clicky. Space tends to fill up with just basic modes, before adding any really interesting stuff. It seems easiest to handle lots of modes on a clicky w/ off-time cap.
Ahh - ok. I looked again and did find it in the cypreus version earlier. I hear you bout space - hoping the ATtiny25 venture works out - think JohnnyC is looking into it, started a port. Doubling program space should help big time.
I'll see if I get a chance to look at your e-switch versions. Not sure if I have time because work is goin nuts - adding a vibrotactile belt (yes - a vibrating belt 
) to the Biodex Balance systems, plus major port from WinCE C++ to Win 7+ C#/.NET platforms, plus adding JSON/web interfaces, etc., etc., on and on...
Yes, please. STAR has me so lostā¦
Are you using the standard Star off time as can be found in the link in your signature? That code really isnāt optimized. There are a lot of things you can do to minimize space. For example:
Instead of having all of those defines for modes, just make a simple array without all of this ā#ifdefā and āmode_cntā stuff. I mean, when you compile the hex file you know how many modes youāre going to have anyway:
static uint8_t modes = {3,14,39,255};
For turbo mode definition you can then just use #ifdef TURBO_TIMEOUT.
For moon mode definition:
#ifdef MODE_MOON
static uint8_t modes = {3,14,39,255};
#else
static uint8_t modes = {14,39,255};
#endif
Then you can get rid of the unneeded space wasting integer āmode_cntā and itās handling, and instead use āsizeof(modes)ā to get the amount of modes later in the code.
Iāve written my firmware this way so I know it works, so I just tested making these small changes in the linked Star off time (took about 5 minutes) and went from 1000 bytes to 920 bytesā¦ With no change in functionality at all.
Star and the off time version have plenty of things that can be optimized in similar fashion without changing functionality. Star is great because itās written for easy use, but there are changes that can be done like the one I made above that can save even more space without necessarily making it harder to use.
How might I allow for slower or faster button presses when changing modes with STAR_offtime_no-memory? I would like to allow slower presses to change modes instead of reverting to low. Does the CAP_THRESHOLD value affect this?
I gave my mag-lite to my parents to see how the mode switching worked for them and they fumbled with the control of the light more than I was expecting.