That's correct. Or it can always start on high, if the mode order is reversed .
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.