Almost there. But it’s not under ToyKeeper/ , it’s under bin/ . 
BTW, to compile the code for an arbitrary driver, you’ll probably need to edit the source a little bit to choose relevant settings. And the crescendo.c file also points to those same flashing scripts for info about the fuse values.
I hope people aren’t defined by their national stereotypes… because if they are, I must be a horrible person. 
It’s far better to be a hopeless romantic than to be an arrogant jerk. 
It’s just my national stereotype. But fortunately, people are not defined by the country they live in.
ToyKeeper, I just wanted to say a big THANK YOU! for all of your hard work creating these awesome flashlight interfaces for all of us flashlight fanatics to use—your work is very much appreciated!
It looks like you signed up at BLF just to say thanks? That’s awesome! I hope you’ll stick around, since there’s a lot more to do here.
congrats
does Crescendo work on Eneloop?
does it have NoVisiblePWM on sublumen level?
pic is a link to sw45k mod of AA Copper Tool
The MTN 15mm driver is not a boost driver, so it doesn’t work with an AA cell.
Crescendo generally uses ~16 kHz PWM, but it depends on what hardware it’s running on and how it was built.
is there a way to make an AA Tool run a Ramping UI on Eneloop?
Similar to Nitecore D10.
else, the basic modes on the AA Tool will suffice to gift to a muggle.
Hum, I am note sure it that already exists Jon!
I believe it is a little bit like the Anduril for the Sofirn SP10S project (to be run on AAs and 14500s): it is still being “searched” the ideal formula to make those more “advanced” UIs on alkalines! 
BTW, the light in which I have Crescendo currently is the On The Road i3 zoomie flashlight.
thanks for your thoughts
well… I just wont tell the AA alkleak using muggles, about the D10 ramping UI…
The CuTool AA is intended as a gift to an electrician friend. Now that it has a good beam with sw45k, they can just learn the clicky UI, with memory…
close enough for Government work, as we say on this side of the great water
enjoy your LiIon UIs
Thank you for making this chart, now I understand Crescendo.
Thank you very much.
Keep in mind that Crescendo running on an attiny13a does not have memory; not enough space on the chip for all the code. The code written for an attiny25 has memory available.
I’ve flashed Crescendo onto a Texas Avenger-Driver and it doesn’t ever ramp down. Otherwise it behaves like it should, so a single tap ramps up, a triple tap goes to turbo, and so on. A double tap simply does nothing.
I’ve tried to change the code and make it go to Turbo to make sure it’s not a problem with the ramping down code, but the phenomenon persists.
I’m a bit stumped and can’t really tell if this is a hardware problem or if there’s something odd with the software after all - I don’t really get the code in all detail. How can I best go about debugging this?
What MCU is the version you flashed written for? And what MCU is in the driver? There is a version that is written for attiny13a and a different version that is for the attiny25. But I would think if the wrong version was flashed then there should have been an error. ??? I like that firmware.
Do you have trouble with loosing the memory setting—- I’m constantly having to re-enable memory
I have mainly flashed it to the attiny13a series MCU. That version does not support memory.
The version for the attiny 25 is complete with memory. When I have flashed the 25 version to the attiny25 it has worked properly.
Depending on your skills it is possible to swap the MCU’s, they are the same size. That is best done with a hot air workstation.
#elif (ATTINY == 85)
// TODO: Use 6.4 MHz instead of 8 MHz?
#define F_CPU 8000000UL
#define EEPSIZE 512
#define V_REF REFS1
#define BOGOMIPS (F_CPU/4000)
// (1 << V_REF) | (0 << ADLAR) | (VCC_CHANNEL)
#define ADMUX_VCC 0b00001100
// (1 << V_REF) | (0 << ADLAR) | (THERM_CHANNEL)
#define ADMUX_THERM 0b10001111
#define DELAY_ZERO_TIME 1020
But to be honest I have no clue what any of that means.
Might have something to do with how the FW does off-time memory. See this thread for some discussion and reference to more discussion.
In my case double tap did not work due linker optimization dropping ".noinit" variables. Solved it by adding "used" attribute, so declarations looks like this:
uint8_t fast_presses __attribute__ ((section (".noinit"))) __attribute__((used));
uint8_t long_press __attribute__ ((section (".noinit"))) __attribute__((used));
uint8_t mode_idx __attribute__ ((section (".noinit"))) __attribute__((used));
uint8_t ramp_level __attribute__ ((section (".noinit"))) __attribute__((used));
int8_t ramp_dir __attribute__ ((section (".noinit"))) __attribute__((used));
uint8_t next_mode_num __attribute__ ((section (".noinit"))) __attribute__((used));
I finally had some time to read up on this and try out a few things. Unfortunately I had no luck, it’s as before - single tap works, double tap doesn’t, triple tap works.
I also played with CAP_SHORT to make sure I’m not just too clumsy, but that didn’t help either.
Could this be a fuse settings issue somehow? I have E:FF, H:DE, L:E2.