STAR Firmware by JonnyC - Source Code and Explanation

Indeed. That’s why the comment at the top of the file says “FAST has side effects when PWM=0, can’t shut off light without putting the MCU to sleep”. :slight_smile:

Unfortunately, PHASE has some downsides too — it’s often audible (high-pitched whine), and it flashes slow enough that it kind of bothers my eyes. So I usually go with FAST instead, if I use only one.

That can be solved with running attiny at 9.6 MHz (-Ulfuse:w:0x76:m)

I had a feeling there was a good reason not to do this… and then wight explained it in another thread. He says:

Also, I think the attiny uses more power at faster clock speeds.

I think I’ll stick with 4.8 MHz for now.

Another potential option to eliminate both the “ghost moon” and audible whine would be to run in phase-correct mode with a PWM ceiling of 128 instead of 255. Or maybe even a ceiling of like 192. Might be high-pitched enough to not be heard. This increases the pulse frequency without increasing the clock speed. The downsides are slightly reduced output resolution and incompatibility with dual PWM.

But if you use PHASE with level of 0, you get true off. You can use FAST for all other levels. For level 255, use PHASE to get true on. This is what is done in STAR_momentary.

I cleaned up the UI and adopted the blink-on-power option from your Baton.c code.

Here is the modified UI:

From OFF:

  • Short press turns ON to last mode.
  • Long press turns ON to moon.
  • Double press turn ON to turbo.

From ON:

  • Short press turns OFF.
  • Long press cycles to next mode. Keep pressing to continue cycling.
  • Double press cycles to previous mode. Keep pressing to continue cycling.

Notes:

  • There is no previous mode from moon. This is to prevent jarring transition from moon to turbo.

I don’t normally use only one. :slight_smile:

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…

That’s just not my take on it.

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.

Thoughts or suggestions?

From Post #620

So where in this section do I add that?

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.

Thanks, I’ll give it another shot in the morning

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.

Dear dthoang,

I like your UI which can very quickly select the mode you want. Thank for your sharing.

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.

Oops. Sorry for posting code in that sloppy way. If I’d actually tried to compile I’d have caught on eventually…

thanks guys, it’s working like a dream!
I also shortened the long_press duration and changed the wrap to mode 2 so moon is only available from off.

What’s your UI structure now?

From Off
Click = Next mode (moon, L->H)
Long press = High/turbo

From On
Click = Next mode (L->H, ‘off’ and ‘moon’ are not in the cycle)
Long press = Off

*Long press is only about 1/4 second.
……………
I’m still pondering a lockout function of some sort, but haven’t decided how I want to implement it.