It would require a complete rewrite. Clicky switch code is structured very differently than e-switch code, and has very different requirements and techniques to make things work.
However, I’m hoping to get some bigger MCUs soon and start on a combined clicky-switch / e-switch firmware based on blf-a6.c and Ferrero_Rocher/Ramping_UI_table.c .
Ooo now that sounds interesting.
this BLF A6 driver is it possible to copy or flash it to any attiny13 IC or to any nangj 105 driver like 8*7135 or the likes ???
Yes, but you’ll need an off-time capacitor, and it won’t work properly without the second PWM channel. You’ll need to move the modes to all be on the same channel if you want to put it on a Qlite or Nanjg (it is very simple to do)
What pilotdog68 said.
Yes, sort of. BLF-A6 expects to have an offtime capacitor (which nanjg drivers don’t have), and it also would need all its modes adjusted in order to work with only one power channel. You would also have to calibrate a bunch of hardcoded values for things like voltage and button timing and PWM levels, but I include calibration tools in the firmware repository.
If you can’t modify the driver hardware, you might want to look at other firmwares tagged with “ontime” or “mem decay”. Check the INDEX file to find these tags.
This discussion originally started in the X6R thread if you want to read or respond there: KronoReview: Eagle Eye X6R
TomE was helping a ton but maybe some other people can chime in so I don’t feel like I’m pestering him too much. 
The the X6R is a rechargeable clicky+eswitch light with the charging circuit separate but stacked on the driver, so a driver swap is possible. The tail clicky has to be ‘on’ to complete the circuit while charging.
I am going to use STAR dual-switch, but I would like the driver to know when the charger is connected and set PWM to 0 while charging, then turn the light back on when the charger is disconnected. I figured I could use the unused pin (#3?) for this. What can the I/O pins on a 13a measure? Can I just airwire that pin to the 5v power input? I assume the actual code for this would be very simple, but I dont know how to do it.
Interesting question. I don’t have a verified answer yet, but I expect it should be easy if you find the right part to connect a wire to.
I hope it can be detected as a simple “open” or “closed” circuit like the e-switch, but I’m not sure if the charging circuit will have a part which behaves that way. And it’ll be a while before I have the hardware to poke at.
At the very least, I’ll have to make sure the light can be turned off via e-switch in order to allow charging to work correctly. Or ignore the charger entirely. I had otherwise been counting on the tail switch as a power on/off control.
So i’m trying to “add memory” to STAR momentary for my X6R. I looked at STAR dual-switch and STAR momentary side-by-side in diffchecker, and I found this at the end of the DS FW that was not in the momentary FW
I tried putting that in the same place in momentary and now the firmware literally just does nothing.
Any ideas as to what I should try next?
Are you trying to make it remember after power has been disconnected, or remember after the e-switch has turned the light to “off” mode?
In the former case, adding memory will involve making it read/write the mode in eeprom. Check the “store_mode_idx” and “read_mode_idx” functions in the base STAR code. Calling store_mode_idx is the only thing which will allow it to remember the mode across power disconnects.
In the latter case, it may be a little more complicated. There’s a lot happening in parallel through interrupts, and the UI logic there is a bit fragile. The main loop isn’t likely the right place to add e-switch memory.
I was speaking of the former. Thanks, very helpful
TK, is BLF A6 LVP configured around 19.1k and 4.7k resistors?
It is calibrated for the last driver sample from Manker. The resistor values alone don’t seem to be a reliable way to get the right LVP values. You’ll probably need to actually calibrate to your individual driver with battcheck.hex (and an adjustable power supply or some math).
If you use battcheck to get a reading at a low voltage (near 3.0V) and a high voltage (near 4.2V), I can send you the hardcoded voltage values to plug in to other firmwares. I made a script to calculate those, called battcheck.py, here. To use it, edit voltage-example.txt with your measurements (only two are needed, one high and one low), then run “battcheck.py voltage-example.txt”.
This is driving me crazy. All I did was edit the LVP, OTC, and TT values in blf-a6. I’ve set AVRStudio to optimize for size, but now when I go to flash it still says it is too big. My hex file is 2,922 bytes.
Maybe someone else can try to compile it to see if it comes out smaller? What size am I shooting for?
k, take small steps. First try it with no edit changes whatsoever. Your target size for code is 1024, data is ?? - I forget, maybe 64 or 128?? You should see that final code size somewhere. The file size of the .HEX file isn't directly meaningful. You could edit the .HEX and see where the last records end - little trickier though.
@work - don't have latest 6.2 version installed here, or time to dnld projects, etc.
Ok, it compiles to 1032 bytes both before and after my changes. Does version of AVR matter? I am using version 5.1
Ohhh - I started with 6.0 and am on 6.2 now. It could the issue. Might have made optimizing improvements in newer versions. Just 8 bytes over - close
Just in case you haven’t already done so, set your build type to “Release” rather than “Debug”. That produces smaller file sizes for me.
Got version 6.2 installed - no other changes - it now compiles to 1000 bytes
Good News! I think in the beginning, someone posted having probs with 6.0, so most people stuck with the older 5.x tools, but I quickly found the problem and fixed it - some compiler directive, or mnemonic that luxdrv had in it, I think.
Thinking of implementing a lock-out like this in my e-switch firmware for the 25/45/85. This is from a review on the Sunwayman C15A:
Lock out:
The flashlight should be more than seven seconds off, press 1 click and maintain a second click (short flashing) the flashlight will be locked. To unlock, do the same.
Not sure if it's the best way, but I got a couple of side switch lights that don't have lock-out threaded connections, so something like this might just work. Richard's SupFire M2-Z is one example. Dunno bout that 7 second delay though - seems odd.
FWIW, the way I did locking on Ferrero_Rocher/Baton.c is:
I haven’t used it much on a real light though… simply copied the UI from the popular Baton series.