HighEfficiency wrote:

JonnyC wrote:

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.

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.

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…

Microa wrote:

Here is the thread of my temperature monitoring driver. http://budgetlightforum.com/node/22377

comfychair wrote:

comfychair wrote:

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??!)

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

HighEfficiency wrote:

HighEfficiency wrote:

JonnyC wrote:

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.

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.

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...

Sorry, I didn't provide all of the code for you.  Try changing...

if (ticks < 255) ticks++;

to...

if (ticks < TURBO_TIMEOUT) ticks++;

Will the following changes give me a single mode setup?

Quote:

define VOLTAGE_MON // Comment out to disable

define MODE_MOON 8 // Can comment out to remove mode, but should be set through soldering stars
define MODE_LOW 14 // Can comment out to remove mode
define MODE_MED 39 // Can comment out to remove mode
define MODE_HIGH_W_TURBO 110 // MODE_HIGH value when turbo is enabled
#define MODE_HIGH 255 // Can comment out to remove mode
define MODE_TURBO 255 // Can comment out to remove mode
#define TURBO_TIMEOUT 240 // How many WTD ticks before before dropping down (.5 sec each)

#define WDT_TIMEOUT 2 // Number of WTD ticks before mode is saved (.5 sec each)

Tried them and received several errors from Armel Studio 6.2:

Add // before a line to have it ignored.

//#define MODE_MOON 8 // Can comment out to remove mode, but should be set through soldering stars

It seems it works as I modify:
#define ADC_LOW 130 (130=56C)
#define ADC_CRIT 140 (140=60C)
Change
if (ADCH < voltage_val) { if (++lowbatt_cnt > 8)
to
if (ADCH > voltage_val) { if (—lowbatt_cnt > 8)

In fact, the 140 shut off the light will not happen because the power to LED already has been ramped down when the temperature reach 130.

Better now but still getting this

If you're using MODE_HIGH as your single mode, and not turbo, you also need to comment out #define TURBO_TIMEOUT.

Are you also disabling low voltage monitoring? (if so, why?) When you comment out settings at the top, you have to go hunt for other stuff farther down that refers to the things you disabled. If you re-enable #define VOLTAGE_MON those two errors will go away and it builds correctly.

You saved me once again!
If I have only one mode (turbo), voltage step down will work, since I re-enabled the vol mon?

Microa wrote:

It seems it works as I modify:
#define ADC_LOW 130 (130=56C)
#define ADC_CRIT 140 (140=60C)
Change
if (ADCH < voltage_val) { if (++lowbatt_cnt > 8)
to
if (ADCH > voltage_val) { if (—lowbatt_cnt > 8)

In fact, the 140 shut off the light will not happen because the power to LED already has been ramped down when the temperature reach 130.

zeremefico wrote:

You saved me once again!
If I have only one mode (turbo), voltage step down will work, since I re-enabled the vol mon?

I think RMM has a post about that subject around here somewhere. I don’t recall how he was working around it.

zeremefico, “MODE_TURBO” (255) mode includes a timed step-down to “MODE_HIGH_W_TURBO” (110). This is independent from the low-voltage-protection step-down. “MODE_HIGH” (255) uses the same brightness but does not include a timed step-down. You do want Turbo?

I had problems with high (set at 255), as only mode, so i chose turbo only.

JonnyC wrote:

HighEfficiency wrote:

HighEfficiency wrote:

JonnyC wrote:

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.

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.

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…

Sorry, I didn’t provide all of the code for you.  Try changing…

if (ticks < 255) ticks++;

to…

if (ticks < TURBO_TIMEOUT) ticks++;

Johnny – that did it. Thank you very much for your help. It’s certainly appreciated.

I took star off-time memory 1.3 and modified it to add the feature that the longer press (of reverse clicky switch) cycles back the mode. (It’s less than 10 lines of additional code).

Finally I have the perfect driver for me.

Let me start by saying thanks to RMM and to everyone who has contributed to this code.

Let me say next you can put what I know about doing this between these 2 brackets ( ).   Not much.    With that in mind...

Tom E wrote:

I added strobe mode to my custom version of JC's STAR momentary driver, link to source code here:

Google doc - eswitch.c

Basically what I did was added an extra long hold feature to access strobe. I use more aggressive delays, so mode switching stays very responsive, and my priority (as previous versions) is for one click OFF.

 - quick click for + mode (std)

 - long click/hold of 1/3 sec for - mode (std)

 - one click to turn the light OFF, after 1.2 sec in any mode (custom)

 - extra long click/hold of 3/4 sec for strobe mode (any click will return you to original mode) (custom)

So for example:

• the light is OFF - hold for 3/4 sec - strobe, click or hold turns the light OFF
• the light is in Hi mode - hold for 3/4 sec - strobe, click to go back to Hi
• the light is in moonlight mode - hold for 3/4 sec - strobe, click to go back to moonlight

For entering strobe, the long duration next mode will briefly engage (between the 1/3 to 3/4 sec times) but I don't find it much of a distraction, as long as it returns to the original mode you were in. 

Tom that is awesome.   

Am I understanding correctly that this code can be used with a 7135 based driver and ONLY a momentary switch (no dual switch)?

If so how do you wire the switch?   Got a picture maybe?

Finally would it be possible to get this code in an elf or hex?    I really know nothing a bout writing code, but I do have an avr programmer running AVR studio 4 if that will work.

Thanks again all.

vex_zg wrote:

I took star off-time memory 1.3 and modified it to add the feature that the longer press (of reverse clicky switch) cycles back the mode. (It’s less than 10 lines of additional code).

Finally I have the perfect driver for me.

So are you saying you can now use the forward/reverse function with just a reverse clicky? No secondary momentary switch?

In a dual-switch light (momentary side, tail clicky) the tail switch just acts as a lockout, it won't change modes. The driver will behave the same as if you disassemble to swap batteries, meaning the FW will reset back to whatever the default starting mode is after using the tail clicky.

edit: Is the dual-switch specific version able to avoid that, so the tail switch lets it work for signaling/whatever? I haven't looked at that one yet.

I guess I need to read through these 500+ replies. So it’s possible to get some of the features of this firmware with just a reverse clicky?

I might have to get myself a programmer.. Is there a thread about how to get started programming your own drivers?

http://flashlightwiki.com/AVR_Drivers

There are different firmware versions for different switches. There's clicky-specific (both forward & reverse, which physically break power) versions, and momentary-specific (electronic, which just ground a pin on the controller) versions.

I’ve done clicky-only firmwares and momentary-only firmwares but haven’t done a dual-switch one yet. It shouldn’t be hard though, since it’s just momentary plus memory, and JonnyC has already done most of the work.

In general, there are enough people familiar with STAR that we can probably help with most questions, or make the modifications necessary for anything reasonably small.

One of the mods I made has 14 modes (clicky switch only), including a variety of strobes and signal flashers which don’t have to be cycled through in order to use the main solid modes. Another is a smooth ramping firmware for momentary switches, with click for on/off and shortcuts to min/max. I need to make a ramping strobe UI too, among some other things. But I just do it for fun, and release all the code for anyone to use.

Ok, I understand the switch part of this now.  Thanks

I could certainly still use some help getting the file from TomE converted to a hex or elf though.  

I did attempt multiple times to downlaod the version of AVR studio that comfy did the tutorial on, but for some reason the download fails each time.     

That said I am having a bit of trouble converting the file in studio 4.      

After opening new project I took the option that said
AVR GCC and it then asks for a project name to which I wrote MomStar and it let me move forward.
I am then asked to select a debugging platform and the micro.   I just took AVR ONE! and Atiny13A

Next ( and this may be where I blew it??) I copied all of the data from tomEs page from the place where it starts like this

//-------------------------------------------------------------------------------------
// Used for 7135 based Phase Corrected PWM:
//-------------------------------------------------------------------------------------
//#define MODES	0,5,15,92,255		// 5=moonlight, 15=6%, 92=36%, 255=100%


All the way to the bottom of the page and pasted it in the blank box in avr. 
Next I clicked build an nothing happened.

All I got in the box below was 

"Build started 28.10.2014 at 20:43:19"



Anyone wanna take a guess at where I went wrong :) 
I know there are many places to choose from.

For starters make sure you grab the whole thing. You definitely left out a define:
#define F_CPU 4800000UL

Also if you need to you could try a newer version than the one in comfychair’s tutorial. Download it directly from Atmel.

If it helps, I added that code from Tom E to my collection, compiled it, tried it on my test torch, and uploaded it. You can get a copy (including the .hex file) here:

http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/h...

I don’t know how to build it on Windows on OSX though. I used avr-gcc in Linux.

Toykeeprer, thats a big help.       

I have done this once before using a hex, but I'm still not doing something right.     

I took the hex from your link and copied it to notepad.   Then saved it as MomStar.hex

I opened the programmer as usual.  Went to the program tab, but rather than going to the bottom where my elf files are I used the top box where it says "flash" and input hex.     When I tired using the file it just said "Getting isp parameter.. SD=0x06 .. OKUnable to open the specified file"


Any idea what I have done now?

I’m not sure about flashing it in Windows, but you probably want to download it directly instead of copying the contents through notepad. On the page above, there should be an icon to the far right of each item with a down arrow on paper; try right-clicking that and selecting “Save link as” or whatever similar function your browser has. This will at least avoid issues with the file being incomplete or translated while pasting/saving through notepad.

Then I flash it with a command like this:

avrdude -c usbasp -p t13 -u -Uflash:w:eswitch.hex -Ulfuse:w:0x75:m -Uhfuse:w:0xFF:m

BTW, this firmware uses PWM=1/255 as its lowest mode, so the lowest mode won’t even be visible on many drivers. It needs a FET or a lot of 7135 chips to produce any light at that level. More common nanjg-style drivers typically don’t light up until somewhere around PWM=6 to 9.

Awesome.   I think that took care of the problem.      The programmer did run it and I will try it out tomorrow when the epoxy on my LED dries.


I really really appreciate everyone patience with me on this, I feel like the new guy tying to swim in the deep end all over again when I launch out into this programming stuff.

VOB, really glad you find value in this!  You are selling lights with your own custom firmware correct?

I've been adding some features to the stock programs per RMM's request, so those newly updated versions of the code can be found on Github now linked to from my website - http://www.jcapsolutions.com/flashlights/firmware/.  I changed the name of the files for each program so that it will hopefully make more sense...

STAR - Original single clicky program

STAR_off_time - Same as STAR but with off-time memory with the use of a capacitor (brilliant idea by another member documented somewhere here - I should really put that info right in the program)

STAR_momentary - For lights that have a momentary switch, like the SRK

STAR_dual_switch - For lights that have a momentary switch and a rear clicky (bench tested but I actually haven't built a light with it yet)

The new versions are somewhat experimental, so you can always download the older versions from the old links on my site.  I swear I will update my site with all of the new features once I find the time.

Hey Toymaker you could add :i to the eswitch.hex too, just so guys research the format field instead of just copy/paste

I modded Toms code a bit too for my white lights. EDIT Tested and updated. http://pastebin.ca/2866670 Final v.3

Its just a quick mod, all the main code is those guys. I didn’t even clean it up and check for high to low or low to high modes, which would be nice for turbo and voltage monitoring ramps. Just off, high to low eswitch. Hidden moonlight and beacon mode. Removed ramps. No memory, always starts off- Turbo and voltage monitoring optional. I got thinking about this and I don’t like writing to the chip for memory. I dunno why, think down the road some guy gonna get errors and roid rage if it’s anything like the old flash sticks.

Look in Toys collection there V and you’ll find pretty much anything you need. Tom Es mod of JonnyCs work is all commented and easy to understand as are a lot of gems you can pull out of the other work too. You can basically do anything you dream of with the code that’s there.

JonnyC wrote:

VOB, really glad you find value in this!  You are selling lights with your own custom firmware correct?

You are correct.  I just had DrJones write me some code and he told me how to flash micros with it.  My understanding of this stuff is pretty minimal at this point, but I am catching on a little.    Thanks for putting this out for us.






Sadly it appears I am still not doing something right.    I thought I was on a roll for a minute.   After I got the code from toykeepers link my programmer did recognize the file, and it did seem to flash the micro.   No errors reported and I got a string of OK!, OK! OK!s at the bottom of the page.

I then hooked up all the driver wires as normal (7135 based driver) and added the momentary switch between pin 1 and pin4 of the micro.      However this is where the good news ends. 

When I tired to power it on nothing happened.     I tired it with 2 boards and it was the same.   I then reflashed the micros with standard firmware and removed the mom switch and it worked fine.

I think the micro is getting the flash, but it seems that something is not translating.   The ONLY flash of light I ever got was right when I hook up the battery.   It give one very tiny pulse at first contact.     This is repeatable if I disconnect and reconnect the cell.


I think I am flashing the micro correctly, because it does change something about the driver.    I use the first box like this.