Flashlight Firmware Repository

Cool!! Thank you for the trobleshooting.

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.

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.

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

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.

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.

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.

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

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:

should be

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.

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.)

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

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);

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.

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…

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.

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.

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:

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)

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?

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?

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.

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.

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

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.

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.

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.

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!