STAR Firmware by JonnyC - Source Code and Explanation

What you’re trying to do is basically threading or other parallel programming. This is not going to be easy to do on such a minimal processor.

If it’s in the main loop, that entire loop will be blocked until the blinking readout is done. If you do it in an interrupt handler, you either have to disable interrupts until you’re done (and ignore events) or risk re-entering the handler while it’s already running.

You could do it with threads, but I doubt there’s a preemptive threading library for attiny (and if there is, it probably wouldn’t fit). So, your best option is probably to implement your own cooperative threading or to work both threads into a single logic stream in the main loop. Perhaps build a task queue which gets processed in the main loop but can be interrupted by other events, and the blink digit function would simply add tasks to the queue?

In any case, what I’m saying is it’s probably going to be a bit of a pain since the MCU is designed for only specific types of parallelism and I don’t thank that’s one of them.

I actually tried baton on my test rig, and it was close to what I wanted, but i thought it would be easier to use plain STAR as my stepping point.
The main things I didn’t like:

- I don’t like to use a double click as a commonly used function (just preference)

  • I wanted the cycle to always start at moon, not the last mode.

I do like how you’ve implemented the lockout, but I’d rather have the unlock function to be a double click (just because that’s less likely to happen in a pocket than a long press is)
Is it possible to have a long press from off to lockout, and a double click to unlock to moon?

The reason it works that way is simply because I was copying an existing interface. It doesn’t have to stay that way. :slight_smile:

I think a double click could be used to unlock; I just haven’t ever tried it.

The memory could also be removed, which would simplify the interface. Or you could, you know, start with STAR-momentary as a base instead… which already works that way. :slight_smile:

I probably won’t have time to mess with it for a while, but I wanted to make sure you were aware of it in case it might be useful.

I have the UI in post #913 working now, I’ll just have to play with the lockout function (probably start by copying from Baton) to get it to my liking.

thanks for the explanation. Perhaps I give it a shot with attiny85, I am currently on 998bytes with Attiny13a, with nothing left to cut out.

For the record in this thread:

I made a small add-on to star_momentary which dynamically changes the pwm level of the lowest moon mode depending on voltage.

Why?

Because I wanted a lowest moon mode (which is Phase corrected PWM level 2 when using 2 channel / a single 7135), and it doesn’t emit any light below cca 3.1V.

So I implemented a routine to up it to level 3 if the voltage goes below that level, so your light can always be able to work in the lowest available moon mode.

So should anybody be interested, I can share it.

I did something similar in my cypreus firmware, where “moon” means “fast PWM=0”. It changes the PWM speed according to voltage, so that the moon mode will be less voltage-sensitive. At 4.2V it’ll run at the usual 19 kHz, but at 3.5V it pulses at 2.4 MHz. In-between it adjusts smoothly.

Below 3.5V it mostly just gets too dim to see, but that’s okay because the high-amperage cells I’m using are basically empty at that level anyway so I would need to change the battery.

If you find that changing the PWM level is too big of a jump, you could use PFM to adjust it more smoothly. However, this is incompatible with dual PWM so it won’t work on a driver such as the “moonlight special” with two independent PWM channels.

I don’t know (yet) how to adjust PWM frequency, any tips/code snippets?

Yes, it’s quite a big jump, when I increase it from PWM=2 to 3.

I am only using “secondary” PWM output at those low PWM levels, why would that be a incompatible with adjusting PWM frequency?

What would it take to add a fast strobe mode? Or is there already an off-time FW that includes a strobe?

EDIT: I see there are a few discussed earlier in the thread, but the links seem to be broken…? (Or maybe it’s my company’s firewall causing that)

Give post numbers please.

post #248 and on from there. That one sounds like on-time, I assume adapting it for off-time would just be copy/paste?

Yes, must be your company firewall. The code RMM posted was based on STAR_on_time v1.1 (pre dual-PWM). Yes, I expect that it should be simple to move the code over.

It’s a very simple mod. I think that LVP does not function when in strobe mode, but practically speaking I consider this more of a benefit than a risk. If you leave the light in strobe mode for an extended period you likely need the light to flicker more than you need to protect the battery…

Here is a link to the diff vs the original STAR_on_time v1.1 code (pre dual-PWM): Untitled diff - Diffchecker

thanks for that! now I can get it all set up while i’m still at work.

The attiny13a can do two PWM channels or one PWM channel with a variable ceiling value. Not both. Since you’re already using two channels, you can’t change the ceiling. It uses the same register for both functions, but can only do one function at a time.

It would technically be possible to change modes when necessary, but it still can only change the ceiling on the primary PWM channel. The secondary channel is hardcoded to the highest ceiling value. So, it still doesn’t help, if your low modes are on the second channel.

Otherwise, if you’re curious I have a code example in both Ferrero_Rocher/Ramping_UI_table.c and in cypreus/cypreus.c .

I have an example of off-time FW with strobe in cypreus/cypreus.c in my code repo. Or an example with the new “noinit” off-time and fast strobe in s7/s7.c. But those both include a lot more than just a strobe; they’ve got all sorts of extra modes, and have diverged pretty far from their STAR origins.

Regardless, it demonstrates a way to add blinky modes.

hmm I looked at cypreus, but for some reason I thought it was a momentary FW. I might have to take another look. This is for someone else, it just needs L> M > H > Strobe

Yeah, it’s massive overkill for just four modes. It has, um, 15 modes. Or 18 depending on how they’re counted. Mostly, it just demonstrates one method of adding more stuff (like strobes) with an off-time clicky.

Hello guys,
I am working on the a17pzl driver and I would like to make a change in STAR off-time firmware that would enable me to set 255 pwm on secondary output for single 7135 and 0 pwm on primary output. I know that this change might create complications with stepdown battery monitoring and other functions but I am willing to comment them out for the ability to have the driver run 350mA on a single 7135 in one of the modes.
I am not sure what is the right and easiest way to do it. Any help would be appreciated.
Thanks.

you can take a look at star momentary firmware, there you can see how the second PWM output is used, it’s just a few more lines to be able to use the second PWM output.

In that FW, there is another array with PWM levels for the alternate PWM Channel, and for each flashlight mode you can set separately what the PWM levels are outputted at both channels.

Thank you vex_zg for a prompt reply. It seems more complicated than I thought. The momentary FW deals with modes a little differently and I am not sure how to adjust the off-time FW that I will be using.