I finally put together a Github repository. Here's a link to the "dual pwm" branch where so far I've added the PWM features to STAR and STAR_momentary. They have been (mostly) tested. But if someone wants to give them a shot, or maybe just pull the new logic in for their own use, obviously feel free.
Speaking of which I've finally named my programs a little better. STAR_momentary instead of SRK_no_ramp, and STAR_dual_switch instead of DualSwitch. I'll update my site sometime to change the names and point to Github for the downloads.
Oh my gosh. I just tried the STAR momentary without ramping with Tom E's modifications. Wow, love it. High, Low, Strobe, all available at start up. Can go up, down, to strobe, or off from anywhere. Very reliable and consistent behavior. Quite impressive.
The only improvement I can think of is to add an SOS mode. It can potentially be a life saver. Maybe only available from Strobe with another long click or or 2 fast clicks.
It can only be used by a light with an e-switch, or momentary switch (not a clicky), such as the SRK. STAR or STAR_off_time is what can be used with forward clicky or reverse clicky light.
It's doable to do something like "tap on and off very quickly two times and it will put you into a hidden mode". But that would require extra logic within the watchdog timer, and the program is already full due to my inefficient coding :)
Of course now I have to look at the program quick just to make sure it would be too tough to tackle...
Well it's doable, it would just require eliminating some features, because I've already racked my brain trying to come up with a better design to make the code more efficient. Some people here have come up with more efficient delay routines, maybe I'll have to look at those.
i tried to eliminate the stars in the code to make more room like mikec did, but it always comes up with errors so i am doing something wrong or not eliminating enough code. i am not a hacker so i dont no what i am doing, but i understand what some things do in the code but am lost in other parts.
if i tried to learn C programming i would probably get a brain hemorrhage or lots of headaches. it seems in code you have to tell the cpu or mcpu the same things several times in different ways to make it understand or so not to make a mistake. maybe one day their will be a high enough language for idiots like me to understandâŚ
Jonny; is the low voltage warning (low output slow flash) something built into the chip based on the two divider resistors or is this coded as well?
To me, this is a critical feature as I use these for bike lights where I cannot see them to confirm the batteries are still up.
I rarely run out of power, but I would hate for my unprotected cells to get sucked down below the 2.75V minimum.
That's in the code. I was thinking I could remove the flashing part and just have it step down with a single short blink to the next-lower mode (instead of cutting it in half). Not sure how much space that would save though.
Really, at this point, especially with the new dual-PWM output / PWM type definable per mode feature, each implementation for someone needs to be customized. I guess I could put it all in there, but at the top of the file you have to pick and choose what features you want, but you can't have them all.
Hi, Iâve managed to get srk_no_ramp_1.0.c installed on my srk. Is it normal that when i switch from mode 1 to 2 (0 to 16), it temporarily lights up at a very low level (just glowing) before moving on to mode 2 (16)? Then if I do a long hold, it drops to the just glowing again until I release the button (and then it goes to 0 )? Thanks!
Yes, that's an issue with fast-PWM and the MCU being awake (while the button is held down) but not outputting a PWM signal.
If you're not using it to control a 7135-based driver, you should really adjust those levels from the defaults in the original source file. Different driver hardware will work with different minimum levels, 7135s need a minimum of around 5-6, other stuff can go much lower. Some hardware may be too bright in the lowest mode with even a PWM of 1.
That brings up an interesting question⌠is the PWM signal a square wave with an equal on/off cycle or is it a triggered pulse where the off-time can be significantly longer?
So if Iâm understanding correctly (which isnât likely as I donât understand the program at all) setting the lowest mode (as in #define MODES line) to 1 is an approach to solve this? I did this, but the issue is still occurring.
It is not a problem, doesn't cause anything other than the behavior you described. Phase-correct is noisy and not a good solution for something that isn't wrong.
Right⌠âPULSE =WIDTH= MODULATIONâ