STAR Firmware by JonnyC - Source Code and Explanation

For what it’s worth, I’ve already created a DVCS repo with STAR in it, among other firmwares. I’ve been really busy trying to get a house sold during off-work hours so I haven’t added everything I want to it yet, but it’s supposed to go on the market tomorrow and free up a lot of time. Anyway, that project/repo is here:

https://launchpad.net/flashlight-firmware

It’s using bzr+Launchpad instead of git+GitHub, but it’s mostly the same idea. LP has more features but isn’t as popular.

In the repo itself, I have each version of STAR I could find, NLITE (some other DrJones projects coming soon), MikeC01’s STAR derivatives, my own STAR derivatives, example code from tterev3, some info on how to get started, convenience scripts, etc.

So, I have some questions:

  • Can several of us share a code repository to make things simpler for everyone else?
  • If so, is Launchpad okay or should we move it elsewhere?
  • To explicitly prevent/avoid any copyright issues, could we add some type of open-source license to as much of the code as possible?

Is there any pins that could run a separate load than the one to the emitter? Like to kick a fan on and off using the temperature sensor.

Thanks

Looking at the ATtiny13A datasheet it looks like 20 mA is about the most you can get out of the pins directly, so you would need to use some type of relay (like the 7135 acts as) to drive a fan. If you're wondering what pins can output, on the NANJG driver stars 2 through 4 can be configured as outputs.

I think the spec is 40ma max per output, 200ma max for all outputs. But the answer is yes, you have multiple outputs available on the MP. However, the code would not follow anything we’ve worked with yet.

I like the idea of mixing output pins to come up with more complex flash patterns. Seeing how the MP is “generic”, you really have to work from the ground up to integrate your specifications.

That little chip can do a lot. Just don’t overlook what has already been developed in the stock drivers. Some features are not mentioned very often in these threads, like the 2.8V/cell dropout protection where the drivers goes into a low output slow flash. A feature that is a mode onto itself.

Ah thanks. Yeah Jonny that would work as long as it has a separate out for the relay.

It will not run a relay, you'll need a small FET. Depending on the load you're driving the fet could run it directly or be used to control the coil on a traditional mechanical relay. The MCU does not have any temperature sensing ability though, so it would probably be best to use a separate fan controller with its own thermistor.

I think (wink wink nudge nudge) someone is working on the bits to plug into STAR momentary use the unused PB4/PB0 (pins 3 & 5) to power battery level indicator LEDs... they're very low current, able to be powered directly by the MCU. Once the code is worked out it can be tweaked to make those pins do other stuff.

So this is a little sneak peak of the tiny changes I made to the SRK_no_ramp firmware to utilize the 2nd star for a PWM output as well as the normal output. Also you can set the...hold on a sec, I was just testing it again and now have a blank spot in the middle of my vision. Ok, I can see what I'm typing again. You can set PWM mode/function by each individual mode as well. This will allow you to, for instance, run (with a custom board or added wiring to the 105C) moonlight mode using phase correct PWM off of a single 7135, and then have every other mode run off all 7135's using fast-PWM.

I'm SURE this has been documented before on this site, I was just surprised what little changes it took to work. I'll be polishing up the code and have RMM take a run at it before I release it.

Note: I didn't try a real moonlight mode here. Later I set the PWM value to 2 and it barely glows.

custom board…mwahahahahahaha >)

That sounds great, thanks for attacking this!

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.

Cool. Thanks JonnyC.

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.

star momentary can only be used with a forward clicky on a qlite driver correct?

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.

ok thanks jonny! i love star off-time, but was just looking for a way to quickly access strobe mode. i guess you cant have everything. :frowning:

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… :smiley:

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.

I really need to learn C :~