STAR Firmware by JonnyC - Source Code and Explanation

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

I've never had one lock up yet on the HX1175B drivers, but I have always run through the resistors into the buck IC. I am interested to see what it ends up being.

We can probably change the "static uint8_t ticks = 0;" to be "static unit16_t ticks = 0;" so that you can extend the timer to be much longer along with changing the WDT like RMM suggested. The main downside is that we use the watchdog timer to do the counts, and the timing can be pretty far off. If you do a 5 minute timer, it might kick in at 4:30 or 5:30 depending, or even worse.

Or you could just disable turbo entirely and make it never step down.

If necessary though, you could use a limit higher than 255. Just change the declaration to be a 16-bit integer instead of the usual 8-bit one. No need to muck with WDT timings.

Edit: D’oh, JonnyC posted the same idea while I was writing this. :stuck_out_tongue_winking_eye:

My driver was modified to temperature monitoring instead of voltage monitoring. Would you please educate me to modify the code to ramp down and to shut off when the voltage of the ADC is higher than the threshold.

Johnny - thanks for the input.

I did as you suggested and changed to “static uint16_t ticks = 0” then changed the turbo timeout to 600. Let the light run for 9 minutes and did not see any step down.

Is there something I’ve missed?

Much appreciated.

You don’t want to do both voltage and temperature monitoring?

If you want to do only temperature I assume you don’t want a “critical” value which turns the light off, only a step-down temperature. In that case I’d do something like this:
Replace:

#define ADC_LOW                130
#define ADC_CRIT            120

with

#define ADC_LOW                130
#define ADC_CRIT            0

also replace

if (ADCH < voltage_val) {

with

if (ADCH > voltage_val) {

That’s a pretty dirty way to hack the code. It should work I think, but I don’t like it. For my own use I’d want a separate check done for temperature.

Thanks Wight, That is what I supposed to modify the code.

Sure. Remember that I did not try it, but I think it will work fine. Will you post a thread about your temperature monitoring? I would like to do that myself.

Here is the thread of my temperature monitoring driver. Microa's single XP driver board

This was 'solved' by using Atmel Studio 6.2, the problem code now flashes correctly.

FWIW I also tried:

Change to “static uint16_t ticks = 0” with 240 (instead of 600 above) for the turbo timeout.

This result in a timeout near 2 minutes. Not sure why 600 wouldn’t yield 5 minutes…

Thanks Microa.

Heh, :beer: