STAR Firmware by JonnyC - Source Code and Explanation

Ohh - I used your latest STAR-Off_time verison for the 1st time and got a bit confused over "DUAL" PWM support. I finally figured it out after seeing how the conditional compile switch's were being used, but would have saved me time if I could have understood it better from the descriptions/docs. I was thinking DUAL PWM mode was phase controlled and fast, as opposed to DUAL outputs, so had me going for a while...

Also, maybe it wasn't so clear to me, but finally understood it by again, going through the code. I think in the prior versions TURBO would knock down to the previous mode in the mode table, but now, it knocks down to a set value, not in the table. I definitiely prefer the way you have it implemented now. I always thought the TURBO step-down setting should be an accessible mode and take up another mode setting. Think the BLF SE X6 driver works the old way which I can't stand - seems a waste of a mode, more clicking, etc.

Yes, it’s in my repo. It’s ToyKeeper/cypreus. However, that version is a little complicated and I need to make a simpler branch which is closer to STAR. It was originally based on an older version of STAR, but I did a lot of weird stuff to it (like a PFM self-adjusting moon mode for FETs, and lots of blinkies).

The timing and behavior is actually pretty reliable, and not terribly difficult to use. I ended up with values of 190 and 100 to differentiate between short, medium, and long presses (< 0.5s, 0.5s to 2.0s, > 2.0s).

In any case, when I have hardware again in a few days, I’m hoping to make a more generic version which is easier to configure. I may even be able to add some things into STAR, but it’ll require making room and that might not go smoothly.

I do very few builds myself, I do plan to try out your UI absolutely ASAP on my next momentary build. The first time I heard it described I was uninterested. The next few times got the wheels in my head turning a little. :wink:

As far as the dual-PWM functionality in STAR, part of the reason it’s confusing is because both of the features were merged into mainline at once: the ability to use both fast and phase correct PWM in one firmware as well as the ability to output an “alt” PWM signal on an extra pin for the “moonlight special” style drivers. JonnyC has packed a bunch of great features in here at this point, but there’s limited documentation as to the what/why/how of using them. I’ve been thinking that I should do a writeup on how to use the firmware, complete with all features and what’s required to take advantage of them. So far I’m just too lazy.

I’m glad that the driver is working well for you! If you have thoughts on how large would be ideal for the default spring pad, please post over in the driver thread. I chose pretty arbitrarily. I’ve been thinking of doing a different kind of spring pad pattern in order to make it easier to center & solder different springs, but in the meantime…

I made a couple 1-click-off firmwares for e-switches, under the Ferrero_Rocher dir of my repo. I’m curious what you think about them.

One does a smooth auto-reversing ramp on long press while the other does a stepped looping ramp. Both give instant access to min, max, and the last-used mode from off. One also includes a soft lockout mode and takes moon out of the main mode sequence (Baton).

It’s hard to include lots of extra blinky modes with an e-switch though, because handling the e-switch takes more room than a clicky. Space tends to fill up with just basic modes, before adding any really interesting stuff. It seems easiest to handle lots of modes on a clicky w/ off-time cap.

Ahh - ok. I looked again and did find it in the cypreus version earlier. I hear you bout space - hoping the ATtiny25 venture works out - think JohnnyC is looking into it, started a port. Doubling program space should help big time.

I'll see if I get a chance to look at your e-switch versions. Not sure if I have time because work is goin nuts - adding a vibrotactile belt (yes - a vibrating belt Undecided) to the Biodex Balance systems, plus major port from WinCE C++ to Win 7+ C#/.NET platforms, plus adding JSON/web interfaces, etc., etc., on and on...

Yes, please. STAR has me so lost…

Are you using the standard Star off time as can be found in the link in your signature? That code really isn’t optimized. There are a lot of things you can do to minimize space. For example:

Instead of having all of those defines for modes, just make a simple array without all of this “#ifdef” and “mode_cnt” stuff. I mean, when you compile the hex file you know how many modes you’re going to have anyway:

static uint8_t modes = {3,14,39,255};

For turbo mode definition you can then just use #ifdef TURBO_TIMEOUT.
For moon mode definition:

#ifdef MODE_MOON
static uint8_t modes = {3,14,39,255};
#else
static uint8_t modes = {14,39,255};
#endif

Then you can get rid of the unneeded space wasting integer “mode_cnt” and it’s handling, and instead use “sizeof(modes)” to get the amount of modes later in the code.

I’ve written my firmware this way so I know it works, so I just tested making these small changes in the linked Star off time (took about 5 minutes) and went from 1000 bytes to 920 bytes… With no change in functionality at all.

Star and the off time version have plenty of things that can be optimized in similar fashion without changing functionality. Star is great because it’s written for easy use, but there are changes that can be done like the one I made above that can save even more space without necessarily making it harder to use.

How might I allow for slower or faster button presses when changing modes with STAR_offtime_no-memory? I would like to allow slower presses to change modes instead of reverting to low. Does the CAP_THRESHOLD value affect this?

I gave my mag-lite to my parents to see how the mode switching worked for them and they fumbled with the control of the light more than I was expecting.

Yep, the CAP_THRESHOLD is what affects it. In easy terms the off time press check is just checking the voltage level of the capacitor, a lot like the voltage monitoring routine. When the light is turned on the off time pin is configured as input and compares the measured level with the threshold value. Once all of that is done the off time pin is set to output and turned on (high) which charges the capacitor and keeps it charged until the light is switched off.

Yeah, getting some to understand momentary pressing rather than full clicks is not always easy.

Yeah, not all that user friendly :( It will be rare that someone would use dual PWM outputs, but I don't want to have a whole bunch of separate programs with different features.

I have a light that has the old turbo step down, and I find it really annoying too, especially because "turbo" is not that much brighter than "high", yet I have to step through high to get to turbo. The ramp down works awesome too, most users won't even notice a change in output yet they get max brightness right from the start without any overheating.

Modes (well, just moon) can be altered by the stars that are soldered though, so they aren't just determined at compile time, even though most people that are customizing the code really have no use for the star soldering features.

I said it before, but seriously, if someone wants to take this codebase and make it an "official" BLF firmware and continue adding features, please feel free. Many of you have come up with great features already, and are better programmers than I. Now that STAR has options there to fit almost anyone's basic needs for a light (my UI needs were met a long time ago), I have lost interest in adding features, creating documentation, etc., as everyone has little variances in how they would like the UI to work (and you are implementing those UI's just fine on your own, which was really the point of releasing this firmware as it's a good starting point for modification). As you guys have pointed out, the more features that were added, the more confusing it is to newer entrants to firmware flashing. This can only get worse.

I will go through each program when I get some time to add some more comments about what #define options do what to make it easier for a newer user to understand everything.

I'm working with RMM on a port for the ATtiny25 (already ported, just need to implement temp sensing in STAR_off_time like we have in STAR_momentary), where we have much more room to improve the logic to adjust the output based on temperature. Once that is completed I will probably bow out, as it was a fun hobby from the start, but is now more of a chore. Working for a new software startup is keeping me busy (which I honestly should be devoting every waking minute to), and I have a whole bunch of projects that I haven't had the mental energy to commit any time to, including learning to machine parts on my 9x20 lathe, rebuilding a motorcycle has been down to the frame for more than two years, and remodeling my house. I guess finding a girlfriend/wife should be in there somewhere as well ;)

Yeah, I get what your saying. Gotta thank you for your work, it got me going with writing my own firmware. I spent a lot of time optimizing because I needed the space.

Except, of course, breaking the core design concept of STAR. It’s designed to be configurable at run-time (via soldered stars) instead of compile-time. This costs a lot of space, but makes drivers end-user configurable.

However, I’ve found two things which definitely can be reduced in STAR off-time. It doesn’t actually need to set up or use the WDT interrupt. That part of the code can be removed and replaced with a small bit of logic in the main loop. It also can be made smaller by replacing the stock _delay_ms() with a custom one. These are the first two things I figured I’d try before attempting to add medium-press and battery check to it.

It will be interesting to see if 105c supplies dry up, or if they will be kept in production.

Several people, including myself, have been sent the 105d’s, which don’t have the stars.

Because I can flash drivers now, the stars don’t matter as much to me, but for the average person buying a 105C with standard or custom firmware on it they are kind of nice to have. Of course, programmable drivers, programmed via the input switch would eliminate the need for stars and allow for even more changes on the fly.

Yeah, your right about that. I’m just the kind of guy that programs in a moon mode if I want it, and leave it out if I don’t. I don’t use stars for any kind of mode configurations, only use them for off time caps, inputs and outputs.

Also true, but you’d have to re-program the turbo timeout because it’s currently counting WDT ticks.

Yep, I suggested that quite a lot of pages ago in this thread. I’ve found that the stock _delay_ms() is not so bad, but gets bad if you pass values above 255 into it, forcing it to deal with doubles. My delay routine has a lower resolution so all my delaying needs are under 255 and therefor only needs integers. That keeps memory usage down a bit.

It doesn’t really matter right now, but a “double” in C is a float with twice the default resolution. Integers above 255 are still integers, they’re just 16 bits instead of 8. Technically, it would be called a dword, or double-word, since the word size on the attiny13a is 8 bits.

For portability, people usually avoid using “words” because the size varies per architecture, choosing explicit bit sizes instead. But words are handy for speed optimization, since they typically are the fastest for most operations.

Interesting… from that last post all you comment with is an in depth explanation of my incorrect terminology. Oh well, I guess it’s good that everyone is different, the world would be a boring place otherwise :beer:

Did they stumble with the offtime timeout, or the fact that it’s a forward clicky with an offtime firmware?

Both! It was mildly depressing.