STAR Firmware by JonnyC - Source Code and Explanation

Without the capacitor, you could still do tricks with the total amount of time passed… but the UI will rapidly get harder to use with more than just “short” and “long”.

Like, you could say that if it has been on 0.0 to 0.5 seconds, step forward. 0.5 to 1.0 seconds, step backward. 1.0+ seconds, and it would stay at the same level. Easy enough to implement in firmware on stock hardware, but kind of hard to actually use the thing in practice.

Yes, that’s what I had in mind. But as you said, makes the ui complicated.

So… this has been bugging me for a while. Every time I edit the STAR sources, I have to fight the urge to fix this so as to avoid cluttering up the diff and the revision history, and also thus making cross-tree patches break… but it’d be really nice to agree on one and then make it consistent:

I flashed in jonnys dual switch firmware and put in a few more modes like your driver toykeeper. That moon is really really low :slight_smile: I can see why this is so addicting- but I need to move the laptop over and use that so I can flash/mod and test without running across the house like an idiot

I couldn’t get comfys beta to come on, still working on that. :stuck_out_tongue: Now if I can get the e-switch working.


edit Ugh it looks bad… PB4 is acting like it’s grounded all the time. I found it’s fine with the ohmeter and the switch is working. I might have to switch over to PB3 and hope that one isn’t fubar

Oh the joy

That’s probably why I couldn’t get comfys to work too… The eswitch was acting down the whole time.

The op shows STAR Off-time memory v1.4 but in JCap page it is 1.3?

Maybe the latest versions are on JonnyC’s GIT repo?

EDIT: took me a minute to find the link… GitHub - JCapSolutions/blf-firmware: Firmware for ATtiny13A based flashlight drivers

Anyone every have issues with STAR Momentary locking up?

I'm trying to determine if its a hardware or FW issue. I think it may be where I'm connected the PWM output, but am wondering if others are having this issue before I do surgery on the light.

I'm using the version that Tom E modified to include strobe. It generally locks up in the 3rd mode (going up or going down). I have 7 modes (1,3,9,27,81,130,255), Turbo, and voltage monitoring. Cell voltage does not seem to matter. Lock does not happen often and I have seen no pattern to when it happens yet.

Driver is HX-1175b, two R33 resistors added for 9 amps current, 4 cells driving a MT-G2. Original MCU has been removed. No heat issues appear to exist. Using 81000 and 4700 ohm resistors for voltage monitoring.

I have had no issues of that type, but I haven’t used the modified version. Off the cuff it sounds like a code issue to me though, not hardware.

EDIT: and I should point out that I have only used the momentary version a little bit.

Interesting. I haven’t seen it lock up… then again, I don’t generally leave the power connected while it’s not in use.

I’ve seen some bugs in my own STAR-momentary derivative, but I haven’t noticed any in STAR itself. I don’t think I’ve ever seen it lock up, in any case.

Do you have any of the hardware for reflashing an attiny13? It’s possible that maybe the flash was incomplete or the ROM got corrupted… but I really don’t know.

Thanks wight and ToyKeeper. It locks up when on. If I disconnect power for just even an instant, the FW works normal again.

I'm thinking its a hardware issue. Maybe a weak connection to the switch. Or, it may be that I'm tying PWM directly into the Buck Converter. There is a resistor to ground on the Buck Converter PWM input pin, but I could go downstream.

I think ToyKeeper is on the right track - even if it’s not corruption, reflashing with something else (like stock STAR momentary) would be a good way to test. If the problem goes away you can work from there. If it doesn’t go away we can be pretty certain that it’s a hardware problem.

Sounds like a good idea. Will do next time I open up the light.

By the way wight. You're idea on how to have low voltage protection with more than 1 cell in series works. I will post my experience with it so far in the HX-1175b thread as soon as I get a chance.

Thanks, that’ll be good!

Yeah, sorry, it's pretty disorganized. The plan is to redirect my webpage to the github repository which will have it's own landing page describing what the programs do. I've been busy with work and I'm making some changes for RMM, but once that is all buttoned up and tested (two separate PWM outputs and fast/phase-correct selection by level) I'll do the updates so it's easier to find.

I have a problem I haven't run into before. I'm still using AVR Studio 5.1.208.

Trying to build one of ToyKeeper's FWs, AS5 gives no errors or warnings, everything seems fine until I go to flash it in avrdude, when I get this:

avrdude: ERROR: address 0×0410 out of range at line 65 of Ferrero_Rocher_v02.hex

I did try changing the optimization to -Os, but it still won't flash. (also, how the hell do you change that setting permanently, so it doesn't have to be done every! single! time! you open the program??!)

That’s really weird. avrdude in Ubuntu handles it with no problems. Here’s the script I’m using to flash it:

#/bin/sh
FIRMWARE=$1
avrdude -c usbasp -p t13 -u -Uflash:w:$FIRMWARE -Ulfuse:w:0x75:m -Uhfuse:w:0xFF:m

To change the optimization setting permanently, the only method I know is to use a Makefile or shell script to build things. All this “integrated development environment” stuff is weird to me. However, I suspect you can probably at least configure it per-project, meaning if you save the code as a project it’ll remember the setting for next time.

First off, big big thanks to Richard, JohnnyC, Dr. Jones, Tido, etc.

I’m mostly interested in using this firmware at much lower output levels, nothing more than 1A. Instead of the 105c I’m more interested in using this firmware with an AK-47A which I’ve had success programming with various other firmwares.

My big question is if it would be possible to extend the turbo timer beyond the current 2 minutes. I’m ignorant in all things firmware but is there any reason you couldn’t have a 20 minute turbo timer (heat issues, etc. aside)?

you can easily define as many modes as you wish, with whatever output levels you desire. For example, I usually create moon mode (with the lowest output possible while still giving some light output, so that I get like 1-1.5 months of battery life on moon mode) + 4 “normal” modes. If the light is big enough that I consider it can take the heat, I don’t limit the turbo mode. If it’s a smaller light, I limit the turbo mode to 1-2 minutes.

Adjusting duration of turbo mode is just one line of code.

Understood.

As I interpreted the description of the turbo mode I read it as having a 2 minute limit.

I will try for a 20 minute turbo mode and see how it works.

You can extend it out pretty far on the momentary version without any changes, and on the off-time version if you change the WDT values. On the normal clicky you can't do it very well since the 0.5s precision is really needed for the mode lock time. Remember that on the clicky versions, the max value is 255 ticks.

This is from JonnyC:

Find this line...
WDTCR = (1<<WDTIE) | (1<<WDP2) | (1<<WDP0); // Enable interrupt every 500ms
Then switch it to one of these, whatever timeout you want...
WDTCR = (1<<WDTIE) | (1<<WDP2) | (1<<WDP1); // Enable interrupt every 1s
WDTCR = (1<<WDTIE) | (1<<WDP2) | (1<<WDP1) | (1<<WDP0); // Enable interrupt every 2s
WDTCR = (1<<WDTIE) | (1<<WDP3); // Enable interrupt every 4s
WDTCR = (1<<WDTIE) | (1<<WDP3) | (1<<WDP0); // Enable interrupt every 8s