STAR Firmware by JonnyC - Source Code and Explanation

Thanks all! I ordered those caps off of the eBay link. I missed mentioning of the cap value in the OP. My links to posts don't see to work - very frustrating... The comfychair link I could not find

I put the cap between star 4 and the ground ring on the 105c. For the AK-47A I want to keep the bottom free of components so I put the cap on two pads marked R4. It connects pin 2 and ground just like using the 4th star.

The 101-AK-A1 is a little more difficult, there is no straight forward location for the cap. I haven’t done one yet, I just stack 7135s on an AK-47 if I want more than 1 amp with a flat bottom driver.

You are not the only one - it seems different people are using a different number of posts per page, so a link to a specific post that works for one person is broken for somebody else. Site really shouldn't require the page number in links to specific posts, or something. Links in notification emails don't work either for the same reason I think.

I can only get to the post in that link by changing the '?page=7' to '?page=4' - https://budgetlightforum.com/t/-/25032?page=4#comment-573278

Oh -- found out more... I had my setting at 150/page while locusto03 must be using 30/page (experimented til I found one that worked). I set mine to 50/page, thinking that's the default?? Not sure...

Mine is set to 50/page. Don’t know if that is default or if I made the change.

150 here.

I’ve been wondering about the specific post links too. I don’t have a solution, but I try to reduce the issue by using links compatible with the default page size. The default is 30, which I checked by viewing BLF in a browser with no login and no cookies.

I add the post number so people can find it despite a broken link.
Post #352

Post #122 has the link to Digi-Key for the capacitors I use.

Is it possible that driver intended for P60 module (so simple on/off as UI) has hidden modes?

I built one that has a pseudo-hidden strobe... modes are 255, 255, 255, 255, STROBE, with no memory. Turning on/off or accidentally bumping the switch it pretends to not change modes, but you can get to the strobe if you need it.

Thanks comfychair. Yes, it is logical to make approach that way, I will probably end up with something like that. But here is a new idea:

If the modes in one setup are called a group of modes, how hard is to implement two groups? So group 1 would be low-medium-high but if we click (not click but tap or momentarily activate light without click) certain number of times it would change the whole group. Maybe fast clicks and it’s not low-medium-high any more but group 2 which is strobe-high, for example. Fast clicking 10 times goes back to low-medium-high.

Check out some of the other programs out there, including BLF-VLD and luxdrv. I can't remember but I think one of those has mode groups.

I’ve been playing around a lot lately with optimizing for size and have managed to do a slimed down version of STAR 1.1. Mine basically does everything that STAR 1.1 does except check for soldered stars. I removed all those checks and did those selections by using a bunch of #IFDEF and #ELSE sequences. I saved quite a few bytes doing this. Personally I have no use for soldering stars, if I want to change the things the stars changed I’ll just flash a driver with the changes.

I also made a new delay loop by stealing a small section of code from delay_basic.h. My time resolution is not good (77ms) but for my purposes I can get the delays I want, I don’t need pin point accuracy.

Then I edited the voltage monitoring sequence quite a lot, removed a bunch of while loops and delay loops, and saved a total 278 bytes on the original STAR 1.1… That leaves me with plenty of room for playing around :slight_smile:

I’m no programmer though. I’ve tested the functionality with the help of a variable DC power supply, seems to be running fine but I guess I’ll see once it’s been built into a light.

Sounds like good work so far. Will you post your current code? If you don’t have hosting you can use http://pastebin.com (or any similar service) to share it with us.

Care to share your code?

Beautiful thing is…if you can trim in down with code tweaks, more functionality can be added on the back end
Maybe even put in hidden flashies or whatever

I made it easy on myself and uploaded it to my website, download it here: http://www.mikec.se/Stuff/MikeC01.zip

This current version is not as optimized as before as I have re-written a lot of it to make it easier for me to understand exactly what’s going on.

A few differences from STAR 1.1:
No stars, all is defined with #DEFINE and #IFDEF statements
Low voltage warning switches to next lower mode for about half sec, goes back up to current mode for half sec, then changes mode back to the next lower mode and stores it.
If already in lowest mode when low voltage (but not critical) is reached, nothing happens. I might do a one time blink just to let the user know if I have room for it later.
Critical voltage blinks between lowest mode and off 5 times before shutting down.
Re-wrote a bunch of stuff just to make it easier for me to understand what was going on and stripped out some stuff. For example my voltage monitoring routine doesn’t use any while loops.
The only delay-loops I use are for low and critical voltage routines. I got rid of STAR 1.1 _delay_ms at end of main loop. It looks like it actually prevents sleep mode between WDT interrupts as interrupts are about 0.5 seconds, but I never tested that. My low voltage routine skims through and goes into sleep mode between WDT interrupts expect during warning routines.
Re-organized a lot of comments and wrote plenty of my own.
My delayms() function uses assembler code from delay_basic.h. I have no idea what the assembler code does! I can loop it for desired delay times, that’s enough for me. I wrote a version of my delayms() that could take a millisecond value and accurately delay accordingly, but it cost more bytes. As I only use it for warning blinks I don’t need millisecond accuracy, free bytes are more valuable.
This version is 140 bytes smaller than STAR. Besides the way my warnings alert, the user should not notice any difference.

I use AVR Studio 5.1.208 it if matters.

I haven’t put it in a light yet, only run it in connected to a variable DC and LED, and switching modes with this DC has been a little bit of a pain. I’m no programmer, and know even less about programming chips. Anyone find any particular flaws, I am all ears! I’ve probably done a few things really stupid in there somewhere…

I would like to collect the various flashlight firmwares and publish them in one place. This has no copyright or license assigned though, so it falls under the default terms: “Copyright © 2014 Mike C, All Rights Reserved.”

If the original STAR firmware didn’t specify any terms, it would have the same defaults, only with a different owner, which would make this derivative technically illegal. Not that anyone around here cares, but I try to make sure I avoid legal issues when possible.

Would it be okay to add an explicit copyright and license? I was thinking probably the GPL, the most popular free software license. It basically says anyone can do anything they want with the code, so long as they release code for any derivatives they make (also under the GPL), and don’t add external restrictions through patents. Basically, “I made this free-as-in-speech, and if you change it you must also make your version free-as-in-speech.” It does not prohibit selling the code or any products based on it.

Then I’ll be able to publish it along with other firmware, and anyone will be explicitly free to modify or use it.

GPLv3?

I’m not terribly picky about the license used, but I was figuring the current version of the GPL by default, unless there was reason to use something else. Depending on details, it might be more appropriate to go with an older GPL or LGPL or AGPL, or a BSD license, or Apache license, or … etc.

I’m open to suggestions, if the default isn’t agreeable.

Otherwise, I figured I’d probably host sources and binaries on Launchpad.net, with release files available to deliver builds to people who don’t want to use a DVCS to access the files. Github would work too, though I’m not as familiar with it and it isn’t quite as full-featured. However, git is quite a bit more popular so it might be a good choice even though I don’t like it as much. I could go for either one.

This explains some differences between the two DVCS tools involved:
http://toykeeper.net/tutorials/bzr-vs-git/

Their associated project management sites are far more different though, and it would take a much more in-depth article to compare them.