How To Build a Flashlight With Perfect Modes (picture heavy)

855 posts / 0 new
Last post
Crux
Crux's picture
Offline
Last seen: 3 months 1 week ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

Welcome to BLF Markus!  There is a wealth of knowledge here.

Let us know how your program works, you can share your code if you like.

-Crux

heinzeins
heinzeins's picture
Offline
Last seen: 2 years 4 months ago
Joined: 09/19/2010 - 02:04
Posts: 73
Location: Franconia

I got all the required hardware and was able to upload the Fixed settings without any problems. Now I will try to compile the driver of my dreams, moon-l-m-h, hidden Beacon, Strobe and SOS.

Thanks to everyone involved in this great project, especially Tido!

mash.m
Offline
Last seen: 7 months 1 week ago
Joined: 07/29/2011 - 00:39
Posts: 17
Location: germany

hi crux,

nothing special at my code. only some changes at the beacon timing. fixed modes with ultra low, low, med, high and beacon.

i am an electronic engineer, not a programmer so i have to wait and hope that tido implement the trigger function for me.

i still need a other change, for a other project i have in my head. i try to illustrate my next idea: i wan to make a little flashlight that have two xp-g (high cri) an one xp-e (red) for night. now when you first power on the light the red schould be glowing. second: the white with low mode, third: white with med and so on. my idea for the shematic is that the first power on triggers any other io pin, for example pb0, from the attiny. idealy it should only go to logic high. with this a can use a 7135 to power the red one. the second power on trigger should be a normal pwm to io pb1. i think this will be no problem for a coder...

markus

Crux
Crux's picture
Offline
Last seen: 3 months 1 week ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

That's an interesting idea for a light.  The red light works well at preserving night vision.  About five years ago, I modified a headlight to use 3 red Leds (instead of 3 white ones) and one Luxeon 1W (instead of a krypton bulb).  It had a neat control circuit for selecting either light, so I kept that.  I redesigned the driver circuit to accommodate the different Leds.  It has only one mode, but will dim when the batteries get low (to extend their life).  I'm not tempted to redesign it again, even though today's Leds are brighter. 

I hope you have success with your project, I agree that it seems like a SMOP (Simple Matter Of Programming) Tongue out - but I'm not a coder either...

nickmca
Offline
Last seen: 4 months 3 weeks ago
Joined: 07/15/2011 - 00:52
Posts: 11
Location: United States

Hi,

Instead of setting the ADC reference to the internal 1.1v reference and using a voltage divider to determine the voltage it might be possible to set the ADC reference to V_cc and then sample the internal reference to determine the voltage. Then something like 

Vbat = 10 * 1.1 * 1024/ADCval + Vdiode

could compute the battery voltage. Not sure if this works with ATtiny13 but I did something similar with the ATtiny85. 

mash.m
Offline
Last seen: 7 months 1 week ago
Joined: 07/29/2011 - 00:39
Posts: 17
Location: germany

nickmca wrote:

Hi,

Instead of setting the ADC reference to the internal 1.1v reference and using a voltage divider to determine the voltage it might be possible to set the ADC reference to V_cc and then sample the internal reference to determine the voltage. Then something like 

Vbat = 10 * 1.1 * 1024/ADCval + Vdiode

could compute the battery voltage. Not sure if this works with ATtiny13 but I did something similar with the ATtiny85. 

doesn´t work with an attiny13 Frown

mash.m
Offline
Last seen: 7 months 1 week ago
Joined: 07/29/2011 - 00:39
Posts: 17
Location: germany

Crux wrote:

That's an interesting idea for a light.  The red light works well at preserving night vision.  About five years ago, I modified a headlight to use 3 red Leds (instead of 3 white ones) and one Luxeon 1W (instead of a krypton bulb).  It had a neat control circuit for selecting either light, so I kept that.  I redesigned the driver circuit to accommodate the different Leds.  It has only one mode, but will dim when the batteries get low (to extend their life).  I'm not tempted to redesign it again, even though today's Leds are brighter. 

I hope you have success with your project, I agree that it seems like a SMOP (Simple Matter Of Programming) Tongue out - but I'm not a coder either...

hi crux,

i got a little help from tido and the first driver is running. first pb0 will be active for the red led. then you can switch the programmed mode output on pb1. now i understand a little more about the µc.

markus

Crux
Crux's picture
Offline
Last seen: 3 months 1 week ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

I hesitate to ask for help because C-programing is out of my element (I'm hardware), and I don't want to waste anyone else's time.

I figured that if I could compile the stock driver.c code to a working .hex file then I would try tweaking the code to my needs.  But alas,when I build it I got errors saying mode_sos and mode_softbeacon are "undeclared here (not in a function)".  So I changed the source to look like this:

//#define NOMEMORY            // #define to disable mode memory
#define FUNC_STROBE         // #define to compile in strobe mode
#define FUNC_SOS            // #define to compile in SOS signal                      this line was commented out
#define FUNC_SOFTBEACON        // #define to compile in softbeacon mode    I added this line
//#define FUNC_ALPINE         // #define to compile in alpine distress signal

Now it compiles, but it's too big, 1088 bytes (with optimization -Os)!

        Device: attiny13a
        Program:    1088 bytes (106.2% Full)
        (.text + .data + .bootloader)
        Data:         36 bytes (56.2% Full)
        (.data + .bss + .noinit)
        EEPROM:       64 bytes (100.0% Full)
        (.eeprom)

I suspect I don't have something configured just right, but what - there so many things to learn (and so little time)...

BTW I'm using AVR Studio 5.

Any or all help is appreciated.

-Crux

Tido
Offline
Last seen: 4 months 1 week ago
Joined: 05/28/2010 - 15:28
Posts: 185
Location: Berlin, Germany

There are a few places in the code you will have to change if you are adding a new function. Let's assume that FUNC_FADE did not exist before and we are adding it. First, you will probably want to define a new mode line. This is a handy short cut and makes reading the EEPROM set up easier. It looks like this:

#ifdef FUNC_FADE
#define MODE_FADE   0x04, 0xFF, 0x01, 0x01  // fade in/out. Just a gimmick
#endif

MODE_FADE is the name for the mode, the first number is the offset into the function-array (more on this later) and the three remaining numbers are the three parameters the function may use.

Next you set up the EEPROM. This is where you add the mode line:

const uint8_t EEMEM eeprom[64] =
{   0x00, 0xFF, 0xFF, 0x00,
    0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00,
    // initial mode programming, indices to mode lines in the following array
    0x03, 0x06, 0x08, 0x00, 0x00,
    // mode configuration starts here. Format is:
    // offset in mode_func_arr, func data1, func data2, func data3
    MODE_LVL001,    // 0x00
    MODE_LVL002,    // 0x01
    MODE_LVL004,    // 0x02
    MODE_LVL008,    // 0x03
    MODE_LVL016,    // 0x04
    MODE_LVL032,    // 0x05
    MODE_LVL064,    // 0x06
    MODE_LVL128,    // 0x07
    MODE_LVL255,    // 0x08
    MODE_STROBE,    // 0x09
    MODE_POLICE,    // 0x0A
    MODE_FADE       // 0x0B <= new mode line replaces another
};

By placing the #define for the mode lines inside the #ifdef FUNC_<name> earlier, this will result in a compile time error if the EEPROM config contains a mode which has not been compiled into the binary. This is a Good Thing™. You got the compiler error because you disabled the code for the SOS-function, but your EEPROM set up still contained MODE_SOS.

Next you will have to give a forward declaration for the new mode function:

#ifdef FUNC_FADE
void fade(uint8_t offset);
#endif

This is necessary to add the function pointer to the function pointer array:

mode_func mode_func_arr[] =
{
        &const_level
#ifdef FUNC_STROBE
        , &strobe
#else
        , &nullmode
#endif
#ifdef FUNC_SOS
        , &sos
#else
        , &nullmode
#endif
#ifdef FUNC_ALPINE
        , &alpine
#else
        , &nullmode
#endif
#ifdef FUNC_FADE
        , &fade
#else
        , &nullmode
#endif
};

Why this #ifdef FUNC_<name>, &func #else , &nullmode #endif construct? This makes sure that the functions keep their place in the array by replacing functions that are not compiled in with a pointer to a dummy function. Remember the bit about the function offset earlier, when defining the mode line? This is where this offset comes from. Count the functions in this array, starting at zero, until you reach your new function. Fade is the fifth function in the array, so its offset is four.

Now all you have to do is write the actual mode function. If you want to know how to get the parameters from the mode line, look at the strobe function, where it reads its parameters from the EEPROM.

Crux
Crux's picture
Offline
Last seen: 3 months 1 week ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

I do appreciate the explanation of how the code is structured and how to add a mode, that will come in handy when I get that far...

My immediate problem was just getting the unmodified driver.c to compile, and here I must apologize.  The driver.c code I was having trouble building is the code from sixty545, not from Tido.  I just realized this during a sanity check, but after I posted above Embarassed .  I have been able to build Tido's driver.c successfully.  Output looks like this: (and it flashes too)

        Device: attiny13a
        Program:     968 bytes (94.5% Full)
        (.text + .data + .bootloader)
        Data:         26 bytes (40.6% Full)
        (.data + .bss + .noinit)
        EEPROM:       64 bytes (100.0% Full)
        (.eeprom)

(Although I'm not sure how to make the 'simple', 'fixed' and 'programmable' builds. But we'll save that for later...)

 

Its when I try to build sixty545's driver.c that I get the following warning and errors:

Warning    1    #warning "F_CPU not defined for <util/delay.h>"    c:\program files (x86)\atmel\avr studio 5.0\avr toolchain\bin\../lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h    89    3    8mode
Error    2    'MODE_SOFTBEACON' undeclared here (not in a function)    C:\Users\Bob\Documents\AVRStudio\8mode\8mode\8mode.c    299    5    8mode
Error    3    'MODE_SOS' undeclared here (not in a function)    C:\Users\Bob\Documents\AVRStudio\8mode\8mode\8mode.c    300    5    8mode

This is how I got to the point where I did the changes shown in post#368 above.

All of the supplied .hex and .eep files from Tido and sixty545 have worked, I'm just having trouble building the one from sixty545.

I'm currently comparing the two side by side to see where a difference may lie.  I'm going to take some time and if I'm still can't figure it out then I'll put together a better phrased question.

Thanks for all the help so far!

-Crux

Crux
Crux's picture
Offline
Last seen: 3 months 1 week ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

I added the -DBUILD_SIMPLE to the toolchain, compiler, symbols ... and now sixty545 code builds with no errors! Smile

However, its 1038 bytes. Frown

I know I'm close but its late, I'll get back to it tomorrow. 

Microa
Offline
Last seen: 14 hours 34 min ago
Joined: 06/29/2011 - 21:20
Posts: 228

I have just installed Studio 5 for fun but I found that BLF-VLD could not be built.

 

Tido
Offline
Last seen: 4 months 1 week ago
Joined: 05/28/2010 - 15:28
Posts: 185
Location: Berlin, Germany

It looks like AVR Studio doesn't define  F_CPU, so the delay routines don't work. If your MCU is running at 1.2MHz, just add a "#define F_CPU 1200000UL" to the code, or "-DF_CPU=1200000UL" to the compiler flags. If your MCU is running at 4.8MHz, use 4800000UL instead.

Microa
Offline
Last seen: 14 hours 34 min ago
Joined: 06/29/2011 - 21:20
Posts: 228

Dear Tido,

Many thanks for your quick reply. The F_CPU was fixed. There is one more error need to be fixed. Thanks for your advise in advance.

 

Tido
Offline
Last seen: 4 months 1 week ago
Joined: 05/28/2010 - 15:28
Posts: 185
Location: Berlin, Germany

You must have somehow removed or renamed the function start_wdt() or moved it below the point where it is called. I can't really say anything more specific without reviewing the whole source code.

Microa
Offline
Last seen: 14 hours 34 min ago
Joined: 06/29/2011 - 21:20
Posts: 228

This is your original driver.c just re-named BLF-LVD.c and amended line 1029 as per the Flashlight Wiki to support for C99. 

E1320
E1320's picture
Offline
Last seen: 6 months 2 weeks ago
Joined: 03/30/2011 - 05:26
Posts: 3330
Location: New Hampshire

All these screen shots have gotten me much closer to getting my dream light program working.Thanks guys for unwittingly helping me along with my project.

I am already visualizing the duct tape over your mouth.

Tally-ho
Offline
Last seen: 1 year 8 months ago
Joined: 07/23/2011 - 04:15
Posts: 250
Location: France

This is the absolute best thread ever read and I'm glad that it is in BLF and not in CPF. It really opens new perspectives, new "playgroung" for a rookie modder like me. I would have never imagine that it was possible.

Warm thank you to you Tido for your "sharing mind" ("sharing spirit", "sharing attitude" (don't know the appropriate translation for this))...and to all of you.

 

EDIT:

I finally received the USBasp key with 10 wires ribbon, the black SOIC8 clip without ribbon, the bleu Romonia SOIC8 clip with 8 wires ribbon.

I tried to attach the blue clip first but i had an error message: "error: could not find USB device "USBasp" with vid=0x16c0 pid=0x5dc" so I tried to find a driver for the USBasp key (I installed WINAVR before this step but it seems that it didn't install the required driver).

First I donwloaded this one: "vusb-20100715.zip" but the windows installer could not find the driver in the folder pointed in the README file.

Then I downloaded another one: "libusb-win32-bin-1.2.5.0.zip". I'm not a computer guru but the "inf-wizard.exe" that is in the "bin" folder installed it fine by double clicking the ".exe" and choose "USBasp" in the list.

 

I tested the connection as it is recommanded in the wiki but I got the error message described for a bad connection. As I read that the blue clip could make bad connection I switched to the black clip that worked immediately so I was able to backup files from a NANJG 105C, NANJG AK-47 and NANJG AK-47A.

 

I tried to read the files and codes that came with BLF-VFD but I'm lost. My bad english doesn't help.

 

I know that it is just a beginning and what I done is a piece of cake for most of you but I just would like to report to other newbies some details to solve some problems I encountered. 

E1320
E1320's picture
Offline
Last seen: 6 months 2 weeks ago
Joined: 03/30/2011 - 05:26
Posts: 3330
Location: New Hampshire

AVR Studio 4 has been my nightmare. I am in the same boat as you I can backup the files, but I am unable to write to the chips so hopefully someday I will figure it out.

I am already visualizing the duct tape over your mouth.

Microa
Offline
Last seen: 14 hours 34 min ago
Joined: 06/29/2011 - 21:20
Posts: 228

Dear E1320,

Did AVR Studio 4 show any warning when you wrote your chip? What is the programer you are using? Studio 4 does not support USBasp programer.

E1320
E1320's picture
Offline
Last seen: 6 months 2 weeks ago
Joined: 03/30/2011 - 05:26
Posts: 3330
Location: New Hampshire

Microa wrote:

Dear E1320,

Did AVR Studio 4 show any warning when you wrote your chip? What is the programer you are using? Studio 4 does not support USBasp programer.

I am using this USB isp programmer perhaps this is my problem?

I am already visualizing the duct tape over your mouth.

Tido
Offline
Last seen: 4 months 1 week ago
Joined: 05/28/2010 - 15:28
Posts: 185
Location: Berlin, Germany

It looks like you are not executing avrdude in the directory the target files are located in. Either cd into the directory holding the target files or give a full path on the command line.

Budgeteer
Budgeteer's picture
Offline
Last seen: 3 years 7 months ago
Joined: 08/24/2010 - 02:19
Posts: 3035
Location: Slovenia (EU)

Btw, before going to jump on the programming bandwagon i would like some answers from the masterminds behind this.

1. Are the KD 3x amc based drivers still working with this equipment?

2. Is it possible to program the chip to have lets say 1A high 500mA med and 50mA low AND have a beacon mode added 0,1Hz?

3. Is it possible to implement ramping with memory?

4. Can a potential beacon mode be hidden in the UI?

5. Can this be done also on the 8xamc based KD driver also?

Thanks. Smile

kragmutt wrote:

They're gonna send you a green redcat with a black LED.

E1320
E1320's picture
Offline
Last seen: 6 months 2 weeks ago
Joined: 03/30/2011 - 05:26
Posts: 3330
Location: New Hampshire

Tido wrote:

It looks like you are not executing avrdude in the directory the target files are located in. Either cd into the directory holding the target files or give a full path on the command line.

Thanks Tido I changed the location of the target files now it only cannot find the .eep file

I am already visualizing the duct tape over your mouth.

Tido
Offline
Last seen: 4 months 1 week ago
Joined: 05/28/2010 - 15:28
Posts: 185
Location: Berlin, Germany

Budgeteer wrote:

Btw, before going to jump on the programming bandwagon i would like some answers from the masterminds behind this.

1. Are the KD 3x amc based drivers still working with this equipment?

Probably yes. The last batch I ordered about three months ago was still equipped with ATtiny13s.

Quote:

2. Is it possible to program the chip to have lets say 1A high 500mA med and 50mA low AND have a beacon mode added 0,1Hz?

Yes. Well, not truly constant 50/500mA, but a PWM level that averages out to this values.

Quote:

3. Is it possible to implement ramping with memory?

No. This would require one write cycle to the EEPROM for every light level passed during the ramping. Since the EEPROM ist rated for "only" 100,000 write cycles, this would probably wear it out in less than 1000 ramping operations.

Quote:

4. Can a potential beacon mode be hidden in the UI?

Yes. Put it in the extended mode group, but not the main one.

Quote:

5. Can this be done also on the 8xamc based KD driver also?

If it is still based on the ATtiny13, yes.

Quote:

Thanks. Smile

You're welcome Wink

Tido
Offline
Last seen: 4 months 1 week ago
Joined: 05/28/2010 - 15:28
Posts: 185
Location: Berlin, Germany

E1320 wrote:

Thanks Tido I changed the location of the target files now it only cannot find the .eep file

Have you moved both files (BLF-VLD.hex and BLF-VLD.eep)?

Budgeteer
Budgeteer's picture
Offline
Last seen: 3 years 7 months ago
Joined: 08/24/2010 - 02:19
Posts: 3035
Location: Slovenia (EU)

Tido, thank you very much. Smile

It would be nice if someone makes a frontend for all that load of apps with dropboxes to quick select custom driver options and autocompile the choices in a flash ready format.

It can be done but someone must really sweat that one app. Willing to donate a few bucks for the martyr who would like to try such project and i bet i'm not the only one willing to contribute.

I really do not like the idea of learning some C++ or what is this based on (at least is not plain assembler).

kragmutt wrote:

They're gonna send you a green redcat with a black LED.

Tido
Offline
Last seen: 4 months 1 week ago
Joined: 05/28/2010 - 15:28
Posts: 185
Location: Berlin, Germany

Not me. I've even given up on keeping all possible driver configurations within a single source file. It's much easier and less error prone to just paste together a new driver from a library of standard functions and then add some glue code to make it all work together. At least if you know some basic C programming.

Budgeteer
Budgeteer's picture
Offline
Last seen: 3 years 7 months ago
Joined: 08/24/2010 - 02:19
Posts: 3035
Location: Slovenia (EU)

Sadly 0 programming experience. :/

Actually the only reason i don't have the hardware yet is i never fully understood the rewiring of the soic clip to the usb programmer interface as from what i gathered have to be fiddled with.

kragmutt wrote:

They're gonna send you a green redcat with a black LED.

E1320
E1320's picture
Offline
Last seen: 6 months 2 weeks ago
Joined: 03/30/2011 - 05:26
Posts: 3330
Location: New Hampshire

Anybody got any ideas?

I am already visualizing the duct tape over your mouth.

Pages