I hope people aren’t defined by their national stereotypes… because if they are, I must be a horrible person. :cry:
It’s far better to be a hopeless romantic than to be an arrogant jerk.
I hope people aren’t defined by their national stereotypes… because if they are, I must be a horrible person. :cry:
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!
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.
I have a 15mm MTN driver with Crescendo on my lumintop Tool AA
congrats
does Crescendo work on Eneloop?
does it have NoVisiblePWM on sublumen level?
MascaratumB:I have a 15mm MTN driver with Crescendo on my lumintop Tool AA
congrats
does Crescendo work on Eneloop?
does it have NoVisiblePWM on sublumen level?
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.
The MTN 15mm driver is not a boost driver, so it doesn’t work with an AA cell.
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.
ToyKeeper:The MTN 15mm driver is not a boost driver, so it doesn’t work with an AA cell.
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! :weary:
BTW, the light in which I have Crescendo currently is the On The Road i3 zoomie flashlight.
like the Anduril for the Sofirn SP10S project (to be run on AA…) is still being “searched”
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
Final rendition of worded operation (confirmed):
.
Basic operation:(tap = half press)
.
From OFF:
(memory off) 1 full click = on at moon level and begins ramping
(memory on) 1 full click = on at memorized level and remains steady
1 full click then Single tap = Moon
1 full click then double tap = Turbo
1 full click then triple tap = Strobe / Batt check / Special modes.
From ON (while ramping):
Single tap = pause ramping (steady on at the level when tapped)
1 full click = OFF.
From ON (after pause ramping):
Single tap = resume ramping UP
Double tap = resume ramping DOWN
Triple tap = Turbo
Quad tap = Strobe / Batt check / Special modes
1 full click = OFF.
From Moon:
Single tap = begin ramping
Triple tap = Turbo
1 full click = OFF.
From Turbo:
Single tap = back to steady on at previous level
1 full click = OFF
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.
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.
What MCU is the version you flashed written for? And what MCU is in the driver?
#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.
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?
Might have something to do with how the FW does off-time memory. See this thread for some discussion and reference to more discussion.
I built a convoy s2+ with cresendo I used a MTN 17 DDM driver from mtn electronics The issue for me is that the double tap and triple tap does nothing for me but turns off the led, light seems to be on since a single tap gets it ramping up again. It doesnt seem to ramp to 100 % on the top of the ramp(?) No flickering and turns on fine, but im really scratching my head right now trying to figure this out, hopefully someone here knows what could be the culprit. Regards
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.
Have you tried #comment-1834332 ?
Try building with -Wl,-Map=app.map
in LDFLAGS
and verify .noinit
section in map file.
It should look like this, more or less:
.noinit 0x0000000000800071 0x6 crescendo.o
0x0000000000800071 next_mode_num
0x0000000000800072 ramp_dir
0x0000000000800073 ramp_level
0x0000000000800074 mode_idx
0x0000000000800075 long_press
0x0000000000800076 fast_presses
[!provide] PROVIDE (__noinit_end, .)
0x0000000000800077 _end = .
[!provide] PROVIDE (__heap_start, .)
if it's shorter then there's your problem cause. You can either disable optimization (-fwhole_program/-flto
) or hint the linker to keep them even if it thinks it would be better to drop them and use registers instead (or do something to prevent resetting MCU every time you press the button)