DrJones,thank you for answering my question! After testing such setup I agree with you that extended modes not needed as blinkies are far at the end and no need to cycle all modes in order to get the first one.Definetly ,such UI seems rather convenient.
Dr Jones, what are the output levels of the 6 steps by default (particularly the lowest) and how low can the ramping go?
Dr Jones,
Firstly I would like to thank you for posting this because I have searched everywhere for this as the programming is much more difficult than other μc (say picaxe μc’s). Secondly, I wanted to know if it is possible to program the chip to make possible another mode where the electrical output is changed from the default pin to another so I can add an led fader circuit to it. Or if it is possible to program an LED fader mode.
Also, could you tell me the name of this type of programming so I could learn it?
Thanks again
If it is possible to program an LED fader mode, where the led contstantly fades in and out, could you get me started by coding a bit of it or showing me a website where I could learn to code the fading mode my self
Welcome aboard, donkey55!
Well, the ramping in luxdrv does that - in 25 steps though, so it's not a smooth fade. Also it always writes into EEPROM, which wears that out after some hours, so you could copy that procedure and omit the EEPROM writing.
Additionally, TIDO's firmware and sixty545's variant have that, see here and here (posts #254 and 264).
The output pin can be changed in these lines, which refer to pin6, PB1, OC0B
#define outpin 1
#define PWM OCR0B //PWM-value
to pin 5, PB0, OCR0A:
#define outpin 0
#define PWM OCR0A //PWM-value
It must be one of these two pin though, since only these have hardware PWM.
When building luxdrv with Atmel Studio 6, I get this:
Error 1 Cannot find include file: avr/pgmspace.h 33
Error 2 PROGMEM: Unknown instruction or macro 43
Error 3 uint8_t: Unknown instruction or macro 43
Error 4 modes: Unknown instruction or macro 43
Error 5 syntax error, unexpected ‘=’ 43
If include this in the tool chain path:
…/…/…/…/…/…/…/Program Files (x86)/Atmel/Atmel Studio 6.0/extensions/Atmel/AVRGCC/3.4.1.81/AVRToolchain/avr/include
The errors turn into this:
Error 1 typedef: Unknown instruction or macro …/…/…/…/…/…/…/Program Files (x86)/Atmel/Atmel Studio 6.0/extensions/Atmel/AVRGCC/3.4.1.81/AVRToolchain/avr/include\stdint.h 121 0 luxdrvChig
Error 2 signed: Unknown instruction or macro …/…/…/…/…/…/…/Program Files (x86)/Atmel/Atmel Studio 6.0/extensions/Atmel/AVRGCC/3.4.1.81/AVRToolchain/avr/include\stdint.h 121 0 luxdrvChig
Error 3 syntax error, unexpected FUNCTION …/…/…/…/…/…/…/Program Files (x86)/Atmel/Atmel Studio 6.0/extensions/Atmel/AVRGCC/3.4.1.81/AVRToolchain/avr/include\stdint.h 121 0 luxdrvChig
Okay, seriously I don’t know what I’m doing. This seems more difficult than it should be. And frustrating.
Maybe you could just include the other files in the download so I don’t have to compile my own? (although that removes the possibility of customization)
I have now successfully compiled Tido’s code in Atmel Studio 6, so I officially know how to do it. Yay!
By copying the method I used to make his work, I got further this time with luxdrv, but I now get this error:
Error 1 variable ‘modes’ must be const in order to be put into read-only section by means of ‘attribute((progmem))’ Line: 41
If I change this line:
PROGMEM byte modes={ 0, 6,51,255, 254, 251, 252, 253 }; // with ramping
to this:
const PROGMEM byte modes={ 0, 6,51,255, 254, 251, 252, 253 }; // with ramping
it compiles, but is also too big. 
I don’t know, it seems to be the same problem referred to here:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&theme=print&p=860835
I was just about to write that - prepend const.
About size - well, it seems that AVRstudio4+winAVR produce slightly smaller code. However most people do not need that 5-minute-timer. Just deactivate it :)
Change
PROGMEM byte modes[]={ 0, 6,51,255, 254, 251, 252, 253 };
#define TIMER 5 //use timer (5 min, max 6 in this setup)
to
PROGMEM byte modes[]={ 0, 6,51,255, 254, 251, 252 };
//#define TIMER 5 //use timer (5 min, max 6 in this setup)
(delete "253" and prepend "//")
I just about laughed out loud, because I had the exact same thought process, and even already removed the timer before I read this!
I’m seconds away from flashing my new file to the chip, so here goes nothing, THANK YOU!
How did you solve the library problem btw?
When I created the project to copy the code into, I had chosen the wrong type. I accidentally used “AVR Assembler Project” Instead of “GCC C Executable Project” I think the problem was the fact that the wiki was a bit grey in that area, as it was referring to an older version of Atmel Studio.
BTW, I just flashed my board, and it works like a charm… huge grin on my face cycling through the modes.
How much lower is PWM 5 than 6? I want my low to be REALLY low… and 5 is the lowest, right?
EDIT I just tested, and 5 is perfect.
Thank you again! I love this driver, you put some really good thought into it!
Outstanding job there DrJones, you should do a video with NANJG 105C + XM-L T6 to present your software… 
just had an idle thought sitting at my bench - do 12V drivers have similar programmable Atiny chips? I was day dreaming about upgrading a microscope light source (currently halogen) with a high CRI LED and wondered if there was anyway to vary light of the LED by ramping. I’m not entirely sure it’s necessary as I only ever use mine at one level, just curious.
It would certainly save me being pestered every month or so by a student wondering why they can’t see anything through their microscope
Okay, so I have made a few modifications, and I ended up with an unexpected result. I changed these lines:
const PROGMEM byte modes={ 0, 255,51, 254, 251, 252 };
(High, Med, Ramp, Strobe, Beacon)
case 251: mypwm=255; while(1){ PWM=mypwm; _delay_ms(15); PWM=0; _delay_ms(45); } break;
(faster strobe)
if (ticks==LOCKTIME) eepsave(1);
(memory off)
I used these fuses:
0x75 0xff
What happened:
High and Med work as expected. Strobe is “blank” No light when this mode is active. Beacon only works as a beacon, the battery monitor flashes are invisible. Ramping only works after the first three or four lowest steps have passed, and the first one or two visible ramps are EXTREMELY dim.
Any ideas?
I have only tried this program once, as after I flashed the chip, I installed it (semi permanently).
Maybe it’s a bad driver? I did install an additional 7135, and I suppose I could have overheated something… But I don’t know exactly what would cause this. The 105c with extra chip pulls the expected 3+ amps on high.
Strange. None of these changes should cause that behaviour.
Lowest missing ramp levels indicate a wrong CPU frequency; maybe verify the fuse settings.
Missing strobe: Have you adapted the “#define RAMPMODE 4” line to 3?
Missing battery indicator: have you deleted/commented out the “#define BATTMON 125” line? The battery indicator depends on it.
My suggestion: Restart with the original luxdrv03 and test that; if that works as intended, apply the changes you posted (and RAMPMODE) and test again.
Hello DrJones, i started with your driver just to create a falshlight driver for my parents 
As i wanted High Med Low Strobe Modes, i did customise it like that:
const PROGMEM byte modes={ 0, 255,51,10, 251 }; // with ramping
// dummy main modes ramping, ramped mode, strobe, beacon, timer
//#define TIMER 5 //use timer (5 min, max 6 in this setup)
//#define RAMPING //use ramping
#define MINPWM 5 //needed for ramping
#define RAMPMODE 4 //the number of the ramping mode (254) in the modes order; e.g. ramping is 4th mode -> 4; not counting dummy
#define LOCKTIME 12 //time in 1/8 s until a mode gets locked. 12/8=1.5s
#define BATTMON 125//enable battery monitoring with this threshold
In order to compile it without error i had to add const. and outcomment “Timer 5” and “#define Ramping”
the only problem is, if the flaslight is turned on it start with the last stored mode BUT:
it does: high med low high med low high med low strobe high med low strobe….
it takes a couple of cycles to get the modes right and to have strobe again, maybe a firmware bug?
there are some wired modes inbetween, do i have to flash the eeprom inside the atiny as i only flashed the .hex file?
Can you add oscillating strobe mode? just to get this as a weapon led driver
I use luxdrv 0.3 a lot and don’t know that problem.
Try switching faster; luxdrv uses short-cycle memory: if you use a mode >locktime, memory kicks in AND the next mode after that will be reset to 1st mode. That feature allows to have many modes without the need to always cycle through all of them. Very effective if you have your most used modes at the beginning of the list.
Sorry if you already knew that and meant something else.
After a few other attempts since the original failure I posted above, I determined a few interesting things:
The missing strobe was exactly what you had stated. I forgot to change “#define RAMPMODE 4” to 3. Simple enough.
I’m almost certain that the cpu frequency is not being set correctly, as you mentioned above. I also assume this is causing the rest of the problems. Now that the strobe is again working, it appears to be at approximately double speed. Also, when attempting to flash the chip, I noticed there is an error afterwards, when verifying the program there is a data mismatch. I tried reseating the connector numerous times, but couldn’t get past the error. Is it possible for the fuses to be locked and unable to be modified?
As a make do solution, I changed all the lowest PWM level from 5 to 10, and everything now works, aside from the data mismatch still comes up when flashing. I’m wondering if this may cause future problems… if the cpu is running too fast, it may not operate properly at low battery levels?
Can you somehow read out the fuse settings? 0x75 0xff should be right (4MHz). Indeed, running 8MHz at low voltages may cause instabilities.