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/head:/Tom_E/
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.
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.
Does Tom E’s version even have memory? (The stock JonnyC versions which have memory all use wear leveling to prevent this issue from appearing.)
I think you wanted Pin 2 & Pin 4.
I’d ask Dr. Jones if you paid for it. Without the source, how’s anybody going to fix it but him =\
If that’s Tom’s eswitch. He uses PB3 (mcu pin 2) as the e-switch default . It shouldn’t flash when the power gets connected though.
*Yeah wight went over Jonnys code and seen the wear leveling. murphys law kind of guy
I’m not sure which firmware you used there, but I make a point of including a brief flash on boot on all eswitch-only firmwares I make. It lets me know the power is connected and the chip is booted, and any issues afterward are therefore some other type of problem. I don’t think I’ve seen this behavior on other people’s firmware though, unless you count Zebralight.
However, e-switch firmwares generally won’t make light just because they have power. Getting light requires activating the switch, so the switch must be wired up correctly. If it won’t activate, I’d check for switch issues.
This was my problem. Thank you.
That said WOW
Oh my GOSH>>>>>>!!!!!!!!!!!!!!!!!!!!!!!!!
Let it be know that from hence forth
JonnyC and TomE are legends of flashlight
history FOREVER!
That one click OFF is the most un sung hero of the world. OOOOOOOH how I have dreamed of this. No looooooong press for OFF. NO cycling through stobe, but STILL IN THERE!!!!!!!!!!
Had I written a Christmas list I could not have asked for a thing more!
I guess I’d better try it then 
Coolabs came in today, finished the blfdd light. I noticed something interesting putting firmware in my light. I looped this line in making the beacon off while monitoring button clicks.
PWM_LVL = 0; _delay_ms(50);
I assumed it would keep the FET closed, but it didn’t. When you loop the above it makes very little amount of light on fast pwm You can put your face into it and see the die clearly. Maybe someone is interested in that- thought it was pretty cool. If you want to try it, code is at the bottom. Hold the button for ~3 seconds to get beacon and you’ll see in between pulses. Could be an even lower moon
It’s a known “bug” that PWM=0 will still produce a little bit of light when using fast PWM on a high-powered driver (FET, or 32x7135). In phase-correct PWM mode, this doesn’t happen.
I’ve been meaning to tweak my ramping UI firmware to take advantage of this, but have been too busy so far.
Well known to you It’s kind of cool, can get something lower than PWM 1. It does turn all the way off with PWM 0 least on mine. But looping it on 0 causes the lowest moonlight and it’s not ghetto looking either, it’s a nice light up of the emitter. The only time seen this low was playing around with the buck drivers sense resistors, got a similar output.
Maybe running as default when you turn on the tail switch instead of sleep?
That would let whoever has the light know they left the tail on while still being almost parasitic. Just enough light to keep the ring glowing too maybe.