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.
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.
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.
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.
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.
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.
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
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.
