PD68 post #739 - Narsil won't do exactly that, but kind of sort of close. Narsil will have a turn OFF from the side switch (small parasitic drain), and it does sort of use hold for back -- well a short hold goes back one mode, keep holding and you get strobed.
It does have mode memory on the tail power switch, though it uses the brown out feature for doing this, and allows full mode switching on the tail, not just power. Mode changes made on the e-switch are not "remembered".
Thanks Tom. I’ve been meaning to install Narsil in my 7G3CS, but other projects keep taking priority. One day it will happen.
Does anyone else remember a firmware with active battery monitoring on little SMD led’s? I really thought it was written for the Roche F6.
Edit: i didn’t see anything about it in the .txt file, but now that I look at the .c file I’m convinced ferrero rocher is the one I was thinking of. Can anyone explain how the voltage monitoring works with the red and green leds? I see it has dual-pwm support, but how does that mesh? There aren’t enough mcu pins for all of it to work, are there?
PD, there is also the ATtiny13A diagram in that .c-file, right at the beginning. So there are enough pins. I think you’re confusing dual PWM with dual-channel or something?
For indication purposes maybe we could control 2 LEDs with one MCU-pin by charlieplexing. Has anyone done that before here at BLF, or thought of it at least?
Yes, Ferrero Rocher and its siblings display realtime voltage on the SMD LEDs.
No, it doesn’t actually support dual PWM. I think that was dead code inherited from an earlier project, and was never fully removed.
No, there aren’t enough pins for dual PWM and two indicator LEDs and an e-switch. After RESET, GND, VCC, and voltage sense, there are only four pins left. You could use RESET for something, but then you would need a high-voltage flashing tool to re-flash it.
No, Baton (and Ferrero Rocher) doesn’t remember the mode after the power is cut. This is really the only thing keeping it from being usable for a dual-switch light. Well, that, and it doesn’t immediately turn on when power is connected.
No, I don’t think anyone on BLF has multi-plexed multiple color LEDs onto fewer pins. However, the Noctigon Meteor does it that way.
I seem to recall that Mike C did some interesting things with using a single pin for multiple purposes. The results were somewhat vague though, and no code has been posted.
The Ferrero Rocher code only displays three levels — green, green+red, and red. The voltage boundaries for each can be configured. I’ve noticed that it tends to display more fine-grained status though, by flickering from green to green+red at a rate proportional to the voltage. Probably due to measurement noise, but it’s kind of nice so I haven’t really tried to fix it. It gives kind of a continuous blend during part of its range.
Ok, than it was me who didn’t understand what dual pwm is, sorry for that.
It seems like controlling two indicator-LEDs with one pin isn’t that hard to do, but it would require additional diodes if we wanted to controll a red and a green LED for example.
Sounds nice. It doesn’t like like RMM makes any 22mm FET+1 drivers though.
The FET+1 I’ve been using for clicky-switch development has a place to add an e-switch wire, and I’ve got a switch to hook up… the pad is awfully tiny though. I’ll have to see if I can possibly find a tiny wire and get it connected without blocking SOIC8 clip access… It’s the little copper dot next to the “3” here:
It would be easier to use the OTC pads, but then I wouldn’t have an OTC… and that might be important for a dual-switch light.
I thought I posted the details somewhere… Oh well, can post some here.
I use the E-switch, off time cap and voltage divider on the same pin.
The voltage divider resistors must be a lot higher that normally used because R2 becomes a bleed resistor for the off-time cap. I use 1300K for R1 and 300K for R2.
When the light gets turned on, the first thing to do is read the ADC for off time cap result. When that is done, start the WDT interrupt. In the WDT interrupt a voltage check is done. If the result is 0, or very close to it, the E-switch is pressed. If not, it’s a cell voltage reading.
The firmware has to work a little differently than for example Star. I haven’t looked at any other firmware so I wouldn’t know what’s been going lately. I run the WDT interupt at the highest speed so E-switch presses can be detected instantly. Consideration must be taken so the ADC readings from pressed E-switch are not interpreted as low voltage readings by the voltage monitor.
I’ve been working with this setup for a while now on a few different drivers and it’s fairly reliable. The off-time cap values can vary depending on cell voltage and heat, but so far I’ve had no issues detecting short and long off presses. However, I have had consistency issues when attempting to detect short, medium and long off presses. I can post code snips of certain parts of interest but the concept itself is very simple.
Yea, that pad is really tiny. More intended as a “star” connection for soldering to ground. I doubt there was any e-switch use in mind.
Personally, rather than force you to solder up that tiny pad, I think we should send you different driver designed for an e-switch on that pin. One with a nice tiny85 for max code room. To help support firmware development. Considering that some people are more hardware people, others just more software. What do you think? Iirc Comfy sent you the Roche F6 “Ferrero Rocher” driver. If I may ask, are you in the US? I once had the feeling you were in the UK instead, but I don’t recall anymore where it came from! 
Or if you would rather not give your address to some random forum user (which I would certainly understand!), perhaps RMM would be willing to assemble and send a driver based on a board he doesn’t normally carry.
I would also be interested in such a firmware.
I am using STAR_dual_switch atm in a Yezl Y3 with a FET driver but I would like to upgrade to a FET+1 driver so I also need to control two pwm channels.
Most of the current momentary firmwares use pin 2 for the switch… As such most of the boards have pin 3 hidden, or a few boards use it for something else
That’s very interesting. I would like to see this implemented on more boards and firmware. Would free up some pins for extra outputs 
ToyKeeper is looking to do a dual switch firmware though. Tail clicky + momentary side button. You need to keep the OTC (normally pin2) to distinguish between tail clicks.
Also ToyKeeper’s newer firmwares use a separate tk-attiny.h header file to define the pin arrangement. Feels easier to define a different arrangement if needed for a particular board.
I'm keeping the e-switch on pin #2 for now. I'm working on indicator LED support on pin #3 (locator and low voltage indicator).
Why not just use 1 pin to control 2 colors? A high on the pin will trigger 1 side of an LED and a low can trigger the other side of the same dual color led. I have not looked into the amount of current this chip can source and sink, but 30 ma should be enough. I have not tried this with the tiny13 but have done it on the Pi and Arduino several times.
Matt
Well, that’s one kind of dual-switch arrangement. I thought people would just use brown out for click sensing. My main worry is that she will make this great firmware that won’t work with most of the driver pcb’s we have. Then if we make pcb’s for that firmware, we won’t be able to use Pin3 for other things, like indicator led’s or extra outputs (TripleDown)
I have a couple of dual-switch lights sitting around that are just empty shells because I don’t have a firmware I like for them. Like was posted a little earlier today, I would be very excited if we could add dual-pwm support to star-dual-switch or added memory support to Star-momentary. I’d literally freak out and jump up and down if that happened and if it could work with the extra output for my TripleDown board like DEL helped with on blf-a6 a couple weeks ago.
I’ve mentioned it before, but there doesn’t seem to be a lot of interest, so I silently keep working on my boards and firmware 
That’s what I had in mind, sort of, I guess.
I found a nice explanation of how it could work that even a dumb dumb like me could understand. I thought maybe someone could make something useful out of it, that’s why I asked…
@Mike C, the things you do are both very impressing and over my head at the same time. Looks genius from my point of view! I’m sure it looks genius not only from my dumb-dumb point of view…
Well, that… and I’m hoping to be able to use one dev board for both clicky firmwares and e-switch firmwares, and for both single-channel and dual-channel firmwares. It’s nice having a few bits of versatile hardware instead of a lot of single-purpose pieces. I’ve got a growing pile of decapitated light heads with drivers hanging out on long wires.
It doesn’t have to require OTC for a dual-switch project.
RMM’s FET+1 SRK board looks really nice, but I don’t know if he still sells it. My SRK might make a decent all-in-one dev host, and it’s not really getting used for anything else now that there’s a Meteor…
I’m interested!
Even without the hardware, the code would be a great source of ideas and reference material. Like the 3-way-overloaded pin. That’s brilliant!
I’m a big fan of release early, release often.
I assume it would be pretty difficult to add the battery monitoring code from Ferrero Rocher into a clicky firmware like star-offtime?