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.
Or just add some status LEDs and use the Roche F6DD firmware. It keeps one status LED on at all times at about half power as a locator, plus the LEDs give you info about battery voltage under load (green/orange/red).
FWIW, the standby light is barely more than the MCUās parasitic drain. With the light completely off and the MCU in sleep/powerdown mode, the parasitic drain is 0.33mA. With the green LED on but dimmed, the drain is 0.36mA. So, it costs almost nothing extra to leave that slightly on.
Leaving the green LED fully on costs more though; then it runs at 1.23mA. And a lowest-possible moon mode on the main LED is even more ā it depends on the exact hardware used, but 5mA is a common amount for moon on a single emitter on a 8x7135 board.
For a 25R 2500mAh battery, that translates to 10.5 months of standby time with everything āoffā, 9.6 months with the green LED barely glowing, 2.8 months with the green LED fully lit, or about 21 days with the main emitter in moon mode.
Voltage measurements are not performed while the light is in standby. That would drain the battery faster and require removing other functions to make room in the firmware.
And I'm now using a 1.8K resistor on the green LED, your measurements were from one using a 1K resistor. Should be almost halved from that.
Nice ideaā¦ I like the green led. Just need something to let the user know his tail switch is on