Oh, it occurred to me that that detail depends on the driver layout, so I moved it to tk-attiny.h to become a per-layout option. That way, you pick nanjg or FET+1 or TripleDown or whatever, and it chooses the right values for FAST and PHASE automatically.
I haven’t merged this (or the _delay_4ms() thing) into trunk yet, because I’ll need to update everything else which uses it. It’s a bit of an inconvenient merge so I’m waiting until Crescendo is more mature first.
I need some help here.
I have flashed the Crescendo to A6 driver paired with 219C triple. With everything but the battcheck disabled, and 128 step ramp table, it fits to ATTiny13 at 1002 bytes.
Ramping itself works, I can get to the steady mode and change the direction. Problem is when it gets to the top of the ramp, weird stuff happens. It either gets to level (as far as I can tell) significantly lower than turbo and shuts down, or gets to turbo, and changes level to something much less bright and stays there. Third behaviour I have observed is something like a strobe instead of turbo. It never does the zig-zag pattern. I think driver is fine, I flashed A6 firmware, and it works as intended.
vulpes, you might want to try swapping the values of RAMP_CH1 and RAMP_CH2.
It might also be worth trying this, which is a very similar build:
http://toykeeper.net/torches/dbcstm/crescendo/crescendo-13.hex
I tried that build on an old RMM FET+1 driver and a wight A6 driver, and it behaved as expected (except for voltage readings being different between the two).
Swapping channels gives me strobe almost every time. I guess they were reversed since like this it’s much less bright at the begginig of the ramp, but still broken.
Hex you attached just stop ramping at some high level, or occasionaly at turbo. Once it started reversing, then droped at moon and stayed there. If it worked for you, this looks like a hardware problem, but I don’t understand why would it work perfectly with A6 fw.
EDIT: GOT IT! Bad driver ground. I thought I got this covered by adding thick layer of solder on ground ring, but it’s obviously not enough. Putting thick ring made of copper braid instead of retaining ring fixed it. Now I have to think of something more permanent.
Maybe because BLF-A6 isn’t that hard with the FET, PWM-wise -> inductance -> voltage spikes…
EDIT: Well, kinda stupid comment, I guess. BLF-A6 does PWM on the FET as well.
Great to see you back in action, TK. Congrats on your new firmware and thanks for sharing.
I used Gchart ramping FW in my S2+. With its 5second ramp with my driver I got 2.5 second and need to tap very short for short tap. So then I changed the 1uF capacitor on the driver to a 2.2uF as in my BD06 and now I have more time for short taps. 
In Crescendo, with memory on, I want to change the time the light stays in moonlight when first turned on. I thought it would be simple, just change the time in this section:
// moon mode for half a second
set_mode(1);
// if the user taps quickly, go to the real moon mode
next_mode_num = 1;
_delay_500ms();
// if they didn’t tap quickly, go to the memorized mode/level
But this didn’t work so I guess I don’t understand the delay function. Any pointers? Thanks.
Hopefully this is what you’re asking about. If this is what you already tried, carry on… nothing to see here 
_delay_500ms() is just a predefined function that calls _delay_ms(500)
If you want to kick it up to a full second, try _delay_s()
Or if you want to go more granular, just pass a number to the _delay_ms() function. For 750 ms (3/4 second), just call _delay_ms(750) or for 1500 ms (1 1/2 seconds), call _delay_ms(1500)
That should be exactly the right place to change it. Replace “_delay_500ms()” with “_delay_ms(700)” or “_delay_4ms(700/4)” if you want it to be longer, for example.
Or, if you want to change all similar pauses, edit the definition of HALF_SECOND near the top of the file.
Normally I’d just use _delay_ms(N) for all pauses, which is a built-in library function, but the ROM is smaller with other variants. So the code ends up less straightforward… but it lets me fit more features.
TBH, it’s kind of ridiculous that simply saving a few bytes is worthwhile… but with only 1024 bytes total, I’ll take what I can get.
Thanks for the help. Hmm, not quite sure I understand how all the times are defined, but I got it to work. When I tried replacing the 500 with 350, to shorten the time a bit, there was an error about not having defined “_delay_ms(350)”. I ended up, in addition to changing the 500 to 350 in the above section, adding:
void _delay_350ms() {
_delay_4ms(HALF_SECOND/4);
}
right after:
void _delay_500ms() {
_delay_4ms(HALF_SECOND/4);
}
Then it compiled and the delay is shortened to about where I want it.
FWIW, you may also have been able to achieve the same effect just by grabbing the most recent version, since I changed the default timing to 333ms instead of 500ms. I changed it because I finally got a chance to use it in the real world and found that I wanted the UI to work faster.
For that, all I had to do was “#define HALF_SECOND 333”.
However, this changed the delay at the beginning of every mode, not just memory. So, for example, it also allows exiting from turbo sooner, and makes it so the double-tap to ramp down must be a little quicker than it was before.
I’m getting some strange behavior. I reflashed an attiny13 with the latest crescendo in order to get the nice momentary turbo feature, and it was working fine. I was playing with it for a couple minutes, then suddenly this behavior starts: whenever the light is turned on it starts at moonlight and ramps, but I can’t stop it. If I tap the switch it starts again at moonlight and ramps. No combination of taps makes it do anything different. It does the same thing when I power it with my bench power supply. I’ll try flashing again, but it seems like something in the MCU just broke. Do MCUs break?
Edit: I went back to it after a bit and it worked again. Then I was able to break it again by going into battcheck mode. Now I remember going into the modes after turbo broke it the first time also. I reflashed it and it is working so far.
That’s very strange. Did you change anything in the code? Could you paste it somewhere?
I left out most of the blinky modes, and added the 350ms delay I talked about above. Like I said, I reflashed it and it hasn’t had an error yet. I think I left out the 350ms delay thing in the latest version, though; I need to take better notes. :person_facepalming: I sent you a PM.
Okay, it doesn’t look like any of those changes should break anything. The _delay_350ms() function is exactly the same as the _delay_500ms() one though; you could probably undo that and set HALF_SECOND to a lower value if you still want it to go faster.
Maybe it got warm enough that short taps were interpreted as long taps? Not sure. I didn’t think that happened as much with this offtime method.
Ok, I must have added that duplicate function at the same time I used your new shortened HALF_SECOND and mis-attributed the changes.
So, not a functional update… but I finally made a UI diagram for Crescendo since people seem to like those. I hope it makes sense.
Edit: Made the icons more exciting, for great justice.
Edit 2: I take these things very seriously.
Edit 3: Moon? That’s no moon!