I’ve never used a tactical setup. So basically just 100% and Strobe, no memory?
I’m right at the max size of the code as it is, but I’ll see if I can trim something down for some new options like that.
Yeah for tactical no memory and starting at 100% is ok group can stay as it is just reversed with hidden modes
For defence just turn light on and get max output is important
perfect firmware,thanks gchart for helping me out perfecting git even more! Quite helpull BLF fella
I tried your FW the first time today and it works fine for me. Thank you very much gchart!
It is the only one I found for Attiny13 with LVP, Batt Check, Turbo timer and without hardware modification (is there another one…?). And it can be further customized for my needs :+1:
Hello Gchart,
I hate to keep bothering you. Your version of babka based off biscotti is perfect for me. I finally got biscotti to work however, when I try to compile your babka I get several errors in reference to delay in ms:
Do you have any suggestions?
Thank you,
Frank
Hi Frank, no bother at all! It looks like the compiler isn’t finding the “_delay_ms” function. It should be in the “tk-delay.h” include file. Do you have that file in the same directory as your C file? (or nearby with the C file pointing to appropriate directory)
Also, there’s a new version that I just thought to upload, you can find it here. Highlights:
- Simplified Turbo Timer options to just Off / On (instead of Off / 3 min / 5 min)
- Lots of optimizations (smarter about INLINE functions, register variables, global vars, etc)
- Flexible-length mode groups
- Increase from 4 mode group options to 14 (can have up to 16)
- Fast Presses redundancy
- Option for turbo ramp-down instead of abrupt stepdown (set at compile time)
- Room for even more, currently compiles to ~956 bytes
Thank you gchart! I will double check when I get home from work today, and will be trying the new version!
Frank
Got the tk-delay.h issue resolved however now when I run it as copied from your page it states it is 1132 bytes and 110.5% full. Do I need to disable features or am I doing something wrong in atmelstudio? I have optimization set for –0s.
Thank you,
Frank
Wow, that’s a considerable size difference. You shouldn’t need to disable anything. I’m guessing it’s a compile option in Atmel. You say you have “–0s” selected… how about language standard C99? Make sure to use both of those.
Worked like a charm gchart. This is my favorite firmware so far thank you again for the help.
Great! You’re welcome :+1:
-Gabe
Hi, I just noticed you updated this. I copied the changes into my repository.
Thanks for doing that TK! Shoulda mentioned it to ya.
gchart, where could I add something like
if (ticks > (TICKS_PER_MINUTE/40)) {mode_idx = 0};
to make the light go to the first mode on next tap if it has been on for 3 seconds?
Hmm, there’s nothing really in the code for something like that right now. I assume this is for short-tap only, not a full click off-and-on, right?
The first method I could think of for this could use the same ‘ticks’ counting, but you’d need to create a new flag in eeprom to track the fact that the light has been on for more than 3 seconds. Then upon booting, see if that flag is set and if we_did_a_fast_press() is true… then reset mode_idx to 0. It would take some work, but definitely possible.
If the driver drains the MCU fairly quickly during power-off, it can also reset to the first mode with a slightly longer button tap. On some of mine, the threshold is only about a quarter of a second… so a very quick tap goes to the next mode and a slightly longer tap goes back to the first mode. For that, no special on-time counter is needed.
If the driver doesn’t drain very quickly, it can be modded by putting a resistor somewhere to help it discharge faster. Usually this happens through the voltage divider resistors, but I think any spare pin could probably work.
TK, are you talking about it being a medium-press option? Interesting alternative.
But to count 3 seconds…? Almost sounds like the opposite of on-time memory (“if I’ve been on long enough, forget where I’m at”).
Depends on whether only a short tap after 3 second would trigger the reset, or if a full off-on cycle (long press) would reset it as well. If it’s ok that long-press should reset it, then that’s easy and no need for eeprom tracking.
This works perfectly when momory is off, and goes back to the first mode the way I want…
#ifdef HYBRID_MEMORY
if (( ticks > 3 ) && ( !memory_is_enabled() ) && ( mode_idx > 0 )) {
mode_idx =(LAST_BLINKY); save_mode();
}
#endif
This trick is not compatible with mode memory as far as I can tell. I’m working on it but am at a dead end.
(( ticks > 3 ) && ( mode_idx > 0 )) lets it work with memory, but the light just come on in my last blinky mode if it is off for more than a second or so.
No, just talking about regular offtime no-memory. With that configuration, it doesn’t matter how long the light has been on. The next mode is determined by whether the button press is long or short. So, if the user wants to go forward, tap for a very short time. If the user wants to reset to the first mode, tap for a longer time. The analog properties of the circuit determine how long the threshold is between long and short, and like it at ~0.4s or so.
At least, that’s how I usually configure these things.
The ontime-based method is something I have seen occasionally but I don’t really understand the appeal.
dluckey, I must say, I find that to be an unusual feature for a UI. Wouldn’t it be faster to just tap your way to the first mode instead of waiting 3 seconds? Or if you just want an easy way of skipping to a specific mode, just work that into the triple-tap hidden modes?