As much as I like the UI of some of Darrell/georges80's boards, I don't see how they could be implemented with McGizmo's lights. Being able to reliably access features would require, IMO, either much easier to turn heads, or more sensitive tail switches. Twisting a head within specific timing constraints in order to access features is something that I find awkward and using a tail switch would only be slightly better.
The reliability/ruggedness of such UI's circuitry can certainly be debated but, IMO, it's overshadowed by the fact that having such UI's complicates usage of the light, which simply doesn't fix into McGizmo's design philisophy. I respect that philosophy because simplicity and ease of use never become outdated. If they did, many handtools like manual hammers, single-size wrenches and screwdrivers with fixed tips would no longer be sold. Fewer parts always means fewer things to break.
I understand your points... and you need to realize that UIs are not "one size fits all." A UI that was made for one light/situation, may not be a good fit for another. No way would you want to switch a multi-featured UI with a twisty! That would be a disaster as you've pointd out. But that's not the point by a long shot! A UI could be made that exactly duplicates the way a PD switches, if you wanted. If you like to both press and twist for the various modes, then that can be accomodated. But the point is, the press and twist is there because of the constraints of mechanical switching. And if that's what a given builder and user likes (and I'm one of them for some lights!) then that's great, and there's no reason for a uC in that instance. Electronic switching affords flexibility that cannot be found in mechanical swithing. If that flexibility is wanted, then a UI can be designed to give the functionality you wish - at a switch position/combination that you desire. If the mechanical solution is best for a given application, then it should be used!
As a side not here - on the lamps that I've been building with uC's, I almost always also include a mechanical switch. This gives extra control, and completely eliminates any "self discharge" of keeping the uC awake. Since the uC can be told to do any number of things at initial power application, that extra mechanical switch can provide exceptional functionality. In fact, the mechancal switch is all you really need to enjoy many the benefits of a uC. How's that for crazy talk? You COULD use a uC in a twisty light if all you wanted to on/off. And in this case you *could* also have things like auto-sleep, user-configurable current, etc... but still just on/off control via the switch. Surprise! Mechanical and uC switching is not mutually exclusive as so many seem to think! In fact, my latest UI (that has not made it into the public realm yet) is mechanically switched ONLY. NO other way to turn it on and off. Once on, you have brightness control (direct up or down). But to turn it off, you must again use the mechanical switch. The reason is simple: Best tool for the job. The lamp will rarely be fiddled with. You either want it on or off. But you can, at any time, make certain adjustments in the output. Something you cannot do easily with just a mechanical switch. The best of all worlds.
The task of a UI designer is not to add a bunch of modes and crap just because it is possible. The goal is to make something as *useful* and simple as possible - while still incorporating all the features wanted or needed. And we see way too many examples of the former!
As for "simplicity" and "reduced part count" well... compared to a light I know well - the Aleph with two-stage switch cap - a uC-switched light has WAY fewer parts and complication!
I'm not trying to dump on mechanical switching here! It most definitely has some benefits over uC switching. I'm just pointing out that there are also many benefits to electronic switching and control that mechanical switches can't even dream about! In our modern world, we'll need them both for a long time to come. One small example of a benefit of having a uC on board is that we're currently using the uC to automatically reduce the current in a tiny (low mass and low surface area) bike light we're working on. No extra components were needed, as the temp sensor is built directly into the chip. When the incorporated chip gets to a pre-configured temp, the light is automatically dimmed to save itself - and to not leave the user in the dark. When it cools off, the higher levels can again be used.
whew... starting to feel like the old days of, "hey, let's see how often we can get Darell excited enough to post!"
).
