Flashlight Firmware Repository

2239 posts / 0 new
Last post
Tom E
Tom E's picture
Offline
Last seen: 43 min 56 sec ago
Joined: 08/19/2012 - 08:23
Posts: 13386
Location: LI NY

ToyKeeper wrote:
I tried a lot of firmware tricks to try to eliminate the turbo->moon flash, but nothing seemed to make any difference. It seems to be entirely a hardware issue. About the extra cap, I've been away for a few weeks and can't do much testing. However, I should have a fix to test when I get back home.

Adding a 12K resistor across the FET gait (to gnd) seems to have fixed it perfectly. I tested it on the bench and the flash went away totally, completely. Then, made the same resistor mod to a wight FET+1 driver, ATtiny25V, extra 10 uF cap stacked, running my own ported version of what started as STAROffTime (OTC). Installed the driver in a new style Convoy L2 w/UCLp, de-dedomed XM-L2 U2 (oopsy!) U4 1C on a Noctigon and got:

  EFEST 26650 4200 @4.21v - 5.24A tail

  1636 lumens @start, 1608 lumens @30 secs, and 282 kcd measured at 5m (1062 meters)

So I'd say the resistor and cap certainly don't seem effect performance, so far so good.

bugsy36
bugsy36's picture
Offline
Last seen: 2 months 2 weeks ago
Joined: 07/11/2014 - 18:15
Posts: 2475
Location: Florida USA

Cool!! Thank you for the trobleshooting.

It's the simple things that we take for granted that cost us the most

Ευκαιρία λέει πιάσε με από το μέτωπο γιατί μόλις έχω περάσει δεν θα με πιάσειs

pilotdog68
pilotdog68's picture
Offline
Last seen: 11 months 1 week ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

I’m sure this information has been laid out somewhere for the simple-minded, but I don’t understand all of the “include…… .h” all over the code. This must be the reason I’ve stuck with blf-a6 code from May.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

Halo...
Halo...'s picture
Offline
Last seen: 4 years 2 months ago
Joined: 12/15/2011 - 02:39
Posts: 3304
Location: Halo island

Grab a copy of all the .h files, tk-attiny.h, tk-calibration.h, tk-delay.h, tk-random.h, tk-voltage.h and place them in the same folder as bistro.c or blf-a6.c. You use to need to have the files in a particular folder but TK changed that, I believe the files in her main repository now include that change. You actually don’t need tk-random.h unless you enable random strobe in bistro but no harm in just grabbing a copy of everything.

pilotdog68
pilotdog68's picture
Offline
Last seen: 11 months 1 week ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

So i need to do something with those files every time I want to change one of those settings?

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

Halo...
Halo...'s picture
Offline
Last seen: 4 years 2 months ago
Joined: 12/15/2011 - 02:39
Posts: 3304
Location: Halo island

Only if the setting you want to change resides in one of the .h files. For example LVP values and OTC values are in tk-calibration.h.

pilotdog68
pilotdog68's picture
Offline
Last seen: 11 months 1 week ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

Thanks for explaining. What was the reason for moving it to this format?

I’m going to avoid the change for as long as I can, I would have to completely change how I store/archive/flash my firmwares.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

Halo...
Halo...'s picture
Offline
Last seen: 4 years 2 months ago
Joined: 12/15/2011 - 02:39
Posts: 3304
Location: Halo island

It makes some things easier. Sharing code among different firmwares, doing updates. Also once you get use to it, some things are easier when using it. Once you set the LVP and OTC values for a particular board, you make a folder for that board and drop the tk-calibration.h (and the other .h files) in there. Build bistro.c or blf-a6.c from within that folder and it will use the correct values for that board.
So if you have 4 board layouts that could use slightly different LVP or OTC values, you don’t have to tweak 4 different copies of bistro.c or blf-a6.c.

It was really easy testing new builds from TK’s testing repository. Grab a new bistro.c, drop it into the folder with my tk-calibration.h set up for my board and build.

pilotdog68
pilotdog68's picture
Offline
Last seen: 11 months 1 week ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

I guess I can see how that can be helpful, it just doesn’t mesh with how I do things. One day I’m sure I’ll assimilate, but

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

Halo...
Halo...'s picture
Offline
Last seen: 4 years 2 months ago
Joined: 12/15/2011 - 02:39
Posts: 3304
Location: Halo island

pilotdog68 wrote:
One day I’m sure I’ll assimilate, but

chouster
Offline
Last seen: 10 months 3 weeks ago
Joined: 02/20/2014 - 15:05
Posts: 690
Location: germany

Today I managed to get bistro running on PD68’s very nice DoubleDown Board. 3x XP-L HI, FET (PSMN3R0-30YLD) + 2x AMC7135. Had some issues with flashing but once flashed it ran like a charm, no issues whatsoever. Wonderful Firmware TK! Here’s a little little minor correction, if you don’t mind:

Quote:
411 //_delay_ms(RAMP_SIZE/20); // slow ramp 412 _delay_ms(RAMP_SIZE/4); // fast ramp

should be

Quote:
411 //_delay_ms(RAMP_SIZE/20); // fast ramp 412 _delay_ms(RAMP_SIZE/4); // slow ramp

I went with _delay_ms(RAMP_SIZE * 3/8), because I like it that slow and TURBO, BATTCHECK, RAMP as hidden modes. RAMP is sweet. I’m still playing around with it and have been for while… Made it ramp nice and dim just on the 2x AMC’s for example, looks very cool.

Thanks so much for creating and sharing another milestone.

pilotdog68
pilotdog68's picture
Offline
Last seen: 11 months 1 week ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

Hello friends.

This is a firmware that pyro1son kindly put together (from blf-a6) that uses pin3 to toggle a FET output for my TripleDown driver. It works great except for one thing: turbo/timer step-down isn’t active. Can anyone tell me what I need to do to get that working? I can’t figure it out. (I don’t want to keep pestering pyro because he has already spent a lot of his time on this for me.)

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

pyro1son
pyro1son's picture
Offline
Last seen: 5 months 2 weeks ago
Joined: 03/21/2013 - 08:18
Posts: 432
Location: UK

Hey I don’t mind but it’s now beyond my knowledge fixing this issue.

Pastebin                                      &nbs

DEL
DEL's picture
Offline
Last seen: 2 years 8 months ago
Joined: 06/28/2015 - 08:35
Posts: 559
Location: Canada

pilotdog68 wrote:
Hello friends.

This is a firmware that pyro1son kindly put together (from blf-a6) that uses pin3 to toggle a FET output for my TripleDown driver. It works great except for one thing: turbo/timer step-down isn’t active. Can anyone tell me what I need to do to get that working? I can’t figure it out. (I don’t want to keep pestering pyro because he has already spent a lot of his time on this for me.)

I’ll take stab at it…

In lines 542 and 601 we are checking if output == TURBO to decide if anything needs to be done about the turbo mode.

Problem is that output == 255 when in turbo mode, and TURBO is defined as being 245 – This condition will never go true.

So try changing the definition of TURBO to be 255 (up in line 114)? Lines 541-545 seems to be the only place where pin 3 is switched on. Not sure how it could have worked before?

I do not see pin 3 switched off anywhere, you may need to patch this in around line 602 for turbo step-down to actually do anything with the FET. Something like:

PORTB &= ~(1 << FET_PIN);

Somewhat related, line 544 may be messing with the OTC. Better form would be:

DDRB |= (1 << FET_PIN);

pilotdog68
pilotdog68's picture
Offline
Last seen: 11 months 1 week ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

Thanks for the help! Let’s see how well I follow what you said…

-

The reason a number different than 255 was used for ‘Turbo’ is so that we would still have 255 as a valid option on the main PWM channel without triggering the FET. Can the end goal still be accomplished with 245 as the shortcut?

-

As far as Pin3 not being switched off anywhere, I know it switches off in normal mode cycling, but are you saying the language (on line 602) of stepping down to the second-highest mode wouldn’t automatically turn off pin3?

-

So you’re saying that the entirety of line 544 should be just “DDRB |= (1 << FET_PIN);”

instead of

DDRB = (1 << PWM_PIN) | (1 << ALT_PWM_PIN) | (1 << FET_PIN);” ?

I don’t follow that at all, but I’ll make that change if you think it will help overall.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

DEL
DEL's picture
Offline
Last seen: 2 years 8 months ago
Joined: 06/28/2015 - 08:35
Posts: 559
Location: Canada

pilotdog68 wrote:
Thanks for the help! Let’s see how well I follow what you said…

-

The reason a number different than 255 was used for ‘Turbo’ is so that we would still have 255 as a valid option on the main PWM channel without triggering the FET. Can the end goal still be accomplished with 245 as the shortcut?

There is always a way :).
I assumed the FET has to turn on when you are in mode 4/4 or 7/7. When does it turn on? I do not see it happening in the code…

Quote:
As far as Pin3 not being switched off anywhere, I know it switches off in normal mode cycling, but are you saying the language (on line 602) of stepping down to the second-highest mode wouldn’t automatically turn off pin3?

Yes, it will switch off in normal mode cycling (or, more correctly, not turn back on as the mode is being set up after each boot). But you will need to add some logic to have it turn it off after the turbo time-out – if required.

Quote:
So you’re saying that the entirety of line 544 should be just “DDRB |= (1 << FET_PIN);”

instead of

DDRB = (1 << PWM_PIN) | (1 << ALT_PWM_PIN) | (1 << FET_PIN);” ?

I don’t follow that at all, but I’ll make that change if you think it will help overall.

Yes. The shorter code sets the PWM_PIN pin for output, without messing with the other bits in the DDRB register. It is just shorthand for DDRB = DDRB | (1 << FET_PIN). The current code does keep the two PWM outputs alive while activating the FET output, but does not take into account that the OTC pin is also set for output somewhere else in the code. That may, or may not, give weird long press/short press detection.

pilotdog68
pilotdog68's picture
Offline
Last seen: 11 months 1 week ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

DEL wrote:
I assumed the FET has to turn on when you are in mode 4/4 or 7/7. When does it turn on? I do not see it happening in the code…

When does it happen in the code? I have no idea… pyro did that Wink
that code that I linked is what pyro sent me. I changed the mode levels for testing. What i’m using is this:
Quote:
#define NUM_MODES1 3

// PWM levels for the big circuit (FET or Nx7135)

#define MODESNx1 0,255,TURBO

// PWM levels for the small circuit (1×7135)

#define MODES1×1 255,0,0

On the driver I have it set up with one 7135 on the small circuit, 3 on the bigger circuit, plus the FET. With my little power supply I can see what kind of power the driver is pulling to tell what’s happening. As I cycle modes I see it go ~0.38A -> ~1.1A -> 2.0A (psu limited, it’s the FET)

DEL wrote:
Yes, it will switch off in normal mode cycling (or, more correctly, not turn back on as the mode is being set up after each boot). But you will need to add some logic to have it turn it off after the turbo time-out – if required.

Ok that makes sense to me. Now, what do I need to add for that to work and where do I need to add it?

DEL wrote:
Yes. The shorter code sets the PWM_PIN pin for output, without messing with the other bits in the DDRB register. It is just shorthand for DDRB = DDRB | (1 << FET_PIN). The current code does keep the two PWM outputs alive while activating the FET output, but does not take into account that the OTC pin is also set for output somewhere else in the code. That may, or may not, give weird long press/short press detection.

I don’t really understand most of that, but one thing stuck out to me. Where/why is the OTC pin set for output anywhere?

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

jhalb
jhalb's picture
Offline
Last seen: 3 years 6 months ago
Joined: 03/23/2015 - 21:24
Posts: 1350
Location: California

I'VE BEEN AWAY ooops, I've been away for awhile and you guys are now working on something with a fet. I'm lost but I intend to catch up. 

DEL
DEL's picture
Offline
Last seen: 2 years 8 months ago
Joined: 06/28/2015 - 08:35
Posts: 559
Location: Canada

pilotdog68 wrote:

When does it happen in the code? I have no idea… pyro did that Wink
that code that I linked is what pyro sent me. I changed the mode levels for testing. What i’m using is this:
Quote:
#define NUM_MODES1 3

// PWM levels for the big circuit (FET or Nx7135)

#define MODESNx1 0,255,TURBO

// PWM levels for the small circuit (1×7135)

#define MODES1×1 255,0,0

OK, that explains why the FET was actually turning on. The output variable does get to be 245 (in mode 3) – Forget what I said above about 245/255. Just add something to switch it off after turbo timeout and you should be good.

Quote:
Ok that makes sense to me. Now, what do I need to add for that to work and where do I need to add it?

Some boolean gibberish :), as per the earlier post:

Quote:
…you may need to patch this in around line 602 for turbo step-down to actually do anything with the FET. Something like:

PORTB &= ~(1 << FET_PIN);

It sets the I/O port register bit related to FET_PIN to zero, without disturbing the other bits of the register. Basically you AND the register with a word that consists of all 1’s, except for the bit you want to turn of.
E.g. XXXXXXXX & 11111011 = XXXXX0XX, where X = bits that are any value and that we do not want to touch.

Quote:
I don’t really understand most of that, but one thing stuck out to me. Where/why is the OTC pin set for output anywhere?

The OTC pin is only in input mode briefly during boot to check its residual charge. After that it is set to output, and high, in lines 501/502 to keep it charged. Line 544 inadvertently sets it back to input.

pilotdog68
pilotdog68's picture
Offline
Last seen: 11 months 1 week ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

DEL wrote:
…you may need to patch this in around line 602 for turbo step-down to actually do anything with the FET. Something like:

PORTB &= ~(1 << FET_PIN);

Ok, I’ve added that to line 602 and it didn’t seem to do anything. I also tried it after the “save state” command before the ending curly brace, and I tried using ‘0’ instead of the ‘1’. Any more thoughts? Maybe I’m just putting it in the wrong place?

Here is the current version of the code”:http://pastebin.com/YgA2jqhC I’m working with.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

DEL
DEL's picture
Offline
Last seen: 2 years 8 months ago
Joined: 06/28/2015 - 08:35
Posts: 559
Location: Canada

Hi PD,

Looking more closely at the bigger structure, that ‘if..then’ in 600-606 in will never execute, it is blocked by the the ‘if…then’ in lines 542-546.

Will need to rework the program structure a little…will get back to you!

pilotdog68
pilotdog68's picture
Offline
Last seen: 11 months 1 week ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

Thanks for your help! If it makes any difference, either stepping down to the previous mode or stepping down to a pre-set value will work for turbo. Idk if that would be easier to get working.

With some hints I can look at the code and kinda figure out what’s going on, but I don’t know the language well enough to write the code myself.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

bdiddle
Offline
Last seen: 2 years 2 months ago
Joined: 12/14/2012 - 14:36
Posts: 811

So I have tried to browse the code and I think I missed it, but is there an adaption of the BLF A6 firmware for single PWM driver, like the BLF17DD/A17DD-SO8 etc?

Apologies If I missed it, I know much of the code works with those driver, but I really like the A6 software and would love to use it on my other lights.

Newb

DEL
DEL's picture
Offline
Last seen: 2 years 8 months ago
Joined: 06/28/2015 - 08:35
Posts: 559
Location: Canada

pilotdog68 wrote:
Thanks for your help! If it makes any difference, either stepping down to the previous mode or stepping down to a pre-set value will work for turbo. Idk if that would be easier to get working.

With some hints I can look at the code and kinda figure out what’s going on, but I don’t know the language well enough to write the code myself.

OK, back at the computer and reworked the code a little.

You can try this:

http://pastebin.com/EtZKy9td

I moved the ON+OFF control for the FET pin to the set_output function in line 377.
This is a little cleaner than patching it into the main.

It compiles (does not fit on a Tiny13 with my compiler), but I do not have a convenient way to test it. Just let me know if it is not exactly what you need.

DEL
DEL's picture
Offline
Last seen: 2 years 8 months ago
Joined: 06/28/2015 - 08:35
Posts: 559
Location: Canada

bdiddle wrote:
So I have tried to browse the code and I think I missed it, but is there an adaption of the BLF A6 firmware for single PWM driver, like the BLF17DD/A17DD-SO8 etc?

Apologies If I missed it, I know much of the code works with those driver, but I really like the A6 software and would love to use it on my other lights.

It should work as is, just adapt the levels for the 1st PWM output to what you need.
By default they are 0 for the lower levels.

Look for these defines around lines 119 and 129 respectively:

Quote:
#define MODESNx1 0,0,0,7,56,137,255

#define MODESNx2 0,0,90,255

First one contains the levels for the 7-mode group, the other for the 4-mode group. Change the zeroes to useful levels.

pilotdog68
pilotdog68's picture
Offline
Last seen: 11 months 1 week ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

DEL wrote:
OK, back at the computer and reworked the code a little.

You can try this:

http://pastebin.com/EtZKy9td

I moved the ON+OFF control for the FET pin to the set_output function in line 377.
This is a little cleaner than patching it into the main.

It compiles (does not fit on a Tiny13 with my compiler), but I do not have a convenient way to test it. Just let me know if it is not exactly what you need.


As far as I can tell at this point, everything is working perfectly. I’ll of course report if I notice anything weird with more use. For me it compiled at 93% of capacity for the 13a. Thanks so much! My S8 can finally get a new heart Wink

TK: I feel this would be a good one to add to the repository. It is so far the only one that works with my TripleDown driver boards.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

pyro1son
pyro1son's picture
Offline
Last seen: 5 months 2 weeks ago
Joined: 03/21/2013 - 08:18
Posts: 432
Location: UK

Ahhhh I see how you’ve done it. Very clever.

Pastebin                                      &nbs

DEL
DEL's picture
Offline
Last seen: 2 years 8 months ago
Joined: 06/28/2015 - 08:35
Posts: 559
Location: Canada

pilotdog68 wrote:

As far as I can tell at this point, everything is working perfectly. I’ll of course report if I notice anything weird with more use. For me it compiled at 93% of capacity for the 13a. Thanks so much! My S8 can finally get a new heart Wink

TK: I feel this would be a good one to add to the repository. It is so far the only one that works with my TripleDown driver boards.

Smile
pyro1son
pyro1son's picture
Offline
Last seen: 5 months 2 weeks ago
Joined: 03/21/2013 - 08:18
Posts: 432
Location: UK

HELP!!!

I’m having issues flashing. Over christmas I upgraded my PC to Win10 and since can no longer flash firmware. I have tried different USBasp driver but I’m getting this message:

avrdude: verifying …
avrdude: 250 bytes of flash verified
avrdude: reading input file “0╬75”
avrdude: invalid byte value (0╬75) specified for immediate mode
avrdude: read from file ’0╬75’ failed

Can anybody help?

Pastebin                                      &nbs

bdiddle
Offline
Last seen: 2 years 2 months ago
Joined: 12/14/2012 - 14:36
Posts: 811

Run it from a virtual machine

Newb

Pages