Thanks! I’ll hopefully be able to try it tomorrow evening.
I’m going need some hand holding on the “patch” part though. I’m used to the way STAR was originally, I haven’t even figured out TK’s config files yet
It doesn’t appear to use any of those config files. At least not the version I started from.
And a patch is just the difference between the original code and the new version, which is more compact than relisting the whole thing. But if you have trouble with it, this is the whole source.
Finally got a chance to build a driver and test this tonight, sorry for the delay.
It’s very close! For the most part it functions correctly, but the turbo timer steps down when channel 1 is at ‘255’ and it doesn’t step down on the new ‘Turbo/254’ (when the FET is on.) I haven’t tested any lvp function yet, maybe tomorrow.
No worries, I have my own firmware project to keep my busy. And kids. And work. etc :] So take all the time you need, I’ll still be around to fix bugs.
I always forget the simplest things 
Got it fixed and updated.
The modified STAR dual switch could use some testing. Source is here and compiled firmware here .
The SRAM is nearly full because of the way the eeprom is read so you can add at most one extra mode. This looks easy enough to fix but I’d prefer if you tested this version before I introduce more potential problems.
The whole thing is now eerily similar to the STAR momentary code.
Edit: STAR dual switch seems to have buggy low voltage protection, at least from reading the code. It looks like it will step down from low to turbo. Better be careful with it in its current state.
Awesome. Should have time to try it tomorrow.
I ordered this board some time ago and today completed the driver with one 7135 on top and three 7135 chips on the bottom. I used the firmware in the OP and tweaked the values so that now I have moon, low, 0.35A, 1.4A (using all 7135 chips) and turbo.
Really like it that way, the last three modes are all without pwm.
Now I just need to adjust the turbo timer because it is set really low at 5 seconds in the firmware in the OP.
I’m glad someone else gave it a shot! I have them in a few lights now, and I’m really liking them. e-switch and dual-switch firmware adaptations are in the works (possible already done, I just have been to busy to properly test them).
I have the boards and all the parts and I’m in need of some drivers(mostly e-switch). I’m also set up to flash the chips but I haven’t learned how to do so yet. I have the programmer and the program’s downloaded to my PC so I hope any day I will be able to give it a try.
Has anyone else had difficulties with the 7135’s control pin bridging across to the big FET pad / LED- pad? Those two are just a hair apart from each other on the 17mm designs.
Are you saying you have had issues with it, you are you just looking at the Oshpark renders? There’s about 3x more gap than Oshpark shows (though it is still tight). I have only built 2-3 but haven’t had any issues.
Someone built a few and sent me one to get code running on, and there’s a solder bridge where I highlighted in purple. Looking at it in person, it looks difficult to not bridge there:
I’ve tried to remove solder, which didn’t help. Tried to cut it, but perhaps I need to cut deeper. So far, MCU pin 5 still tests positive for continuity with LED-, so when I power it up the LED turns on at a low mode and I can’t flash the firmware.
Sounds like it was hand-soldered perhaps. I would remove the FET and 7135 and suck all the solder off the pads, then reflow with just a little paste under that pin.
Or maybe the board is damaged or misprinted.
I did a little more cutting and it works now. It seems what I needed was an old x-acto blade with a broken tip and very very dull edge to force the extra solder out of the way. Previously I had only tried with a sharp one, which didn’t help.
Just a quick note… I updated the level calculator to work with any number of power channels. It assumes some things though, like that there is only one FET channel (at most) and it’s the most powerful channel and it works better by itself than with other channels turned on. It’ll bail and refuse to run if you tell it a FET channel has less output than all the others combined.
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/tiny25/view/head:/bin/level_calc.py
Here’s an example use, calculating 7 evenly-spaced modes on a tripledown with 1x7135, 6x7135, and 1xFET driving a triple XP-L at a max of 3000 lumens:
> ./level_calc.py
How many power channels? (1) 3
How many total levels do you want? (4) 7
Describe the channels in order of lowest to highest power.
===== Channel 1 =====
Type of channel: ["7135"] or "FET": (7135) 7135
Lowest visible PWM level: (6) 3
How bright is the lowest level, in lumens? (0.25) 0.25
How bright is the highest level, in lumens? (1000) 140
===== Channel 2 =====
Type of channel: ["7135"] or "FET": (7135) 7135
Lowest visible PWM level: (6) 3
How bright is the lowest level, in lumens? (0.25) 1.5
How bright is the highest level, in lumens? (1000) 840
===== Channel 3 =====
Type of channel: ["7135"] or "FET": (7135) FET
Lowest visible PWM level: (6) 1
How bright is the lowest level, in lumens? (0.25) 10
How bright is the highest level, in lumens? (1000) 3000
1: visually 0.63 (0.25 lm): 3.00/255, 0.00/255, 0.00/255
2: visually 2.93 (25.12 lm): 47.85/255, 0.00/255, 0.00/255
3: visually 5.23 (142.85 lm): 255.00/255, 3.41/255, 0.00/255
4: visually 7.53 (426.32 lm): 255.00/255, 88.60/255, 0.00/255
5: visually 9.82 (948.41 lm): 255.00/255, 245.51/255, 0.00/255
6: visually 12.12 (1782.01 lm): 255.00/255, 255.00/255, 101.08/255
7: visually 14.42 (3000.00 lm): 0.00/255, 0.00/255, 255.00/255
PWM1 values: 3,48,255,255,255,255,0
PWM2 values: 0,0,3,89,246,255,0
PWM3 values: 0,0,0,0,0,101,255
You can also specify all the options on the command line, like this:
> ./level_calc.py 3 7 7135 3 0.25 140 7135 3 1.5 840 FET 1 10 3000
Since it’s close already, I’d probably manually adjust the values a bit afterward to make sure one mode is exactly 140 lm and one mode is exactly 980 lm — so that modes 3 and 5 would have no PWM.
Does this mean you have a firmware with 3 pwm outputs?
No, not yet. I should have a tripledown version of bistro pretty soon though. I just wanted to start with the ramp calculator before I look at how to turn on the other PWM circuit.
So, it took a while to figure out exactly how to configure the third PWM channel. There’s this weird dependency between PB4 (FET channel) and PB1 (6x7135 channel) that I don’t fully understand. And then I thought I still had it wrong because my test light doesn’t have much output difference between 7x7135 and the FET. The host I used gets the following outputs:
- 1x7135: 160 lm
- 6x7135: 760 lm
- 7x7135: 880 lm
- FET: 1190 lm
It didn’t help that I gave it a ramp calibrated for a 3000-lm light, so it spent a lot of the ramp on the FET modes and thus looked like nothing was changing.
Anyway, it’s working now:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/tiny25/files/head:/ToyKeeper/bistro/
(requires an updated tk-attiny.h too, to get the TRIPLEDOWN_LAYOUT definition)
(also requires tiny25/45/85 since tiny13 lacks space and can’t do PWM on more than two channels)
This has a ramping test mode enabled instead of bike flash and police strobe, to help with testing driver functionality. I also haven’t attempted to calibrate voltage or OTC timings for this exact driver; those will also need tweaking on a per-driver basis.
This is with a triple xlp host? What battery did you use?
No, not a triple-emitter host. It had only a single emitter.
However, it has three power channels and it implements a smooth brightness ramp using all three channels. This is much like a FET+1, except with three channels instead of two (so the medium-high modes are more efficient).
To use it in a higher-powered light, you’ll need to generate new ramp values (as in the example a few posts ago).