The reason STAR-momentary defaults to PHASE at both ends is because I kept bugging JonnyC to do it that way (for exactly the same reason). Most of my other changes have remained separate, but he accepted that one.
As for the Baton UI, I kind of stopped working on it because I found I just didn’t like the interface as much as some others. I’ve mostly been using Ramping_UI_table.c on my e-switch lights instead, or Ferrero_Rocher.c (depends on the light). The ramping UI is similar to Baton, but it does smooth ramping instead of stair-stepping, and it auto-reverses so a long press will go either up or down based on context. I didn’t have enough room to fit a battery check mode or soft lockout though (I’m using realtime batt indicators instead, and no lock).
I am aware of voltage limitation but in practice attiny works without problem. Most likely atmel was a bit conservative with voltage specs. Perhaps in extreme conditions (hot or cold) there might be a problem, but in those circumstances I would worry much more for the battery itself…
Reading your post it’s almost (but not quite) like you’re looking for an excuse to run out of spec. I’ve seen the tests successfully running other Atmel’s far out of spec. Sure Atmel is conservative! Sure it would take something special to make it not work while slightly out of spec!
… but that brings in the possibility of undefined behavior, and I don’t see a good reason for us to run at 9.6Mhz. A workaround is already present for getting PWM to act the way we want.
I am experiencing the whining from PWM on wight’s SO8 and DD+7135 driver. Also on the BLF17DD.
Here is a link to what I am running for the dual-pwm DD+7135 light. Buzzing dual PWM
I only have the whine in medium and high. Low is using the single 7135 and does not have an audible whine.
I am using the default fuses of 0x75 and 0xFF.
I have tried setting the FAST_PWM_START to 200 so that no set modes would use fast pwm, no change.
Only thing that has worked was setting F_CPU to 9600000 and using the fuse of 0x7a. I guess that can affect the low voltage operation of the Attiny in a negative manner.
The goal is to have long_press from ‘on’ go straight to ‘off’, not prev_mode
I put it where I thought it belonged, but I’m getting an error when I try to compile
This made me laugh out loud. I really have absolutely no clue what we were talking about, I’ve got to go back and look.
… OK, so that’s probably the wrong section to put that in. My mistake, I think. More like the “// Long press” section. And my suggested format for the conditional is probably wrong. It should probably be more like this: if mode_idx != 0 {mode_idx = 0;} else {prev_mode();}
if (press_duration == LONG_PRESS_DUR) {
// Long press
if (low_to_high) {
if mode_idx != 0 {mode_idx = 0;} else {prev_mode();}
} else {
next_mode();
}
}
Note that this only functions with the mode order in one direction. That should be pretty obvious.
I’ve come to like off-time no-memory for most applications, and I think this should operate similarly while still allowing direct access to turbo from off. Moving backwards through the modes isn’t a priority.
I meant that it only works for the normal L -> H mode order. Fine for what you are trying to achieve.
If someone attempts to use my advice verbatim after reversing the mode order to H -> L they will not be happy with the result. I don’t see that as a very sensible thing to do, but I thought I’d mention it anyway.
In C, conditionals go in parenthesis. The general syntax is:
if (something is true) {
then do this;
} else {
do this instead;
}
In any case, I agree about off-time no-memory. I prefer my lights to be stateless, mostly. It should respond in a predictable manner from off, instead of doing something different depending on what the user did last time it was on. On clickies, I often don’t even store the last mode in eeprom any more, so it’s truly stateless after it has been off for at least half a second.
For e-switch lights, I think my favorites are UIs which give direct access to min, max, and the last-used mode.
It sounds like you might want to try “Baton” or “Ramping_UI_table”, which both use a short press to turn the light on or off, a long press to ramp while on (or to access moon from off), and a double press to access turbo. One ramps between a few fixed levels, the other ramps smoothly. They’re both under ToyKeeper/Ferrero_Rocher/ at the link in my sig.
Unfortunately, I don’t have anything like STAR-momentary but modified to allow direct shut-off from a middle mode. The closest I have is one which ramps down and shuts off while the button is being held. It’s called Ferrero_Rocher, if you’re curious.
Whereas a reverse-clicky can be hard to learn for a “muggle,” this should be easier because the momentary switch is just 1-position. Clicking always advances modes, and holding turns it off no matter how long or short you hold it.
having hard time blinking out some numbers (i.e. to blink out results of ADC or voltage or some state variables).
The blink out function works fine, but for some reason, invoking it in while(1) loop in main function causes big lag and sometimes unresponsiveness. I tried to put in inside WDT_off / WDT_on, but with similar unpredictable results.
Has anybody implemented this with success?
This is how I implemented the blinking function:
void blink_single_digit(uint8_t digit)
{
if (digit==0) digit=11;
uint8_t i=0;
PWM_LVL=0;
ALT_PWM_LVL=0;
do
{
ALT_PWM_LVL=0;
_delay_ms(400);
ALT_PWM_LVL=10;
_delay_ms(400);
i;
}
while (i<digit);
}
This is where and how I invoke it:
while(1)
{
// We will never leave this loop. The WDT will interrupt to check for switch presses and
// will change the mode if needed. If this loop detects that the mode has changed, run the
// logic for that mode while continuing to check for a mode change.
This really is very similar to the Baton interface (which already has lock-out implemented), except with long and short presses sort of reversed. Baton does the following:
From off:
Short press: go to last-used mode
Double press: go to turbo
Long press: go to moon mode
Longer press: soft lock-out
While on:
Short press: turn off
Double press: not yet implemented (turns off then on)
Long press: next mode (keep holding to keep cycling, skips moon mode and “off” mode)
While locked:
Press for 3 seconds to unlock
The default long press is 1/3rd second, but it’s easily tweakable in a #define along with several other options.
I haven’t found a place to put a battery check mode yet, but it does at least support realtime voltage indicator lights. I’m thinking perhaps the lockout mode could be used for battery check if the use sets a #define, and the double-press while on should probably go to another blinky mode like beacon or strobe.
