Update Oct 3: PD68 TripleDown/TripleStack - Tri-Channel Driver

I'm totally out of FET's, wait'n on a MtnE order to arrive, so can't reflow boards til maybe tomorrow anyways. Should have throw in a few on my Mouser order cause those are in. Think Richard got overwhelmed over the holidays for sure.

Pyro I was building one of these boards and sadly the code you posted gives a bunch of compile errors. Most of it was stuff a little over my head. The base firmware looks very different from what I remember seeing before. Is it 13a based, or is it for one of the bigger MCU’s?

……………………………………………
You can see I have the mcu partially shifted off its pads. This was necessary in order to be able to flash on-board.

I’ll have another look at it tonight but no promises as firmware isn’t really my thing.

Wondering bout one thing I'm seeing on these new board designs - the missing grnd pad under the 7135's, and for the center pin. The extra connections are not needed for electrical contact because as long as you have some connection to grnd, its ok, but thinking more of a heat path. The 7135's do throw off some amount of heat. I think O-L sort of proved you need a good heat path. I believe he found performance issues with stacked 7135's as opposed to mounting them on a separate board properly heat sync'd.

Wondering if this was given any thought? Maybe this is ok considering we are not stacking?

For the firmware - not sure bout the firmware changes - what is wanted, what to be used as a baseline.

I just received my rev2z boards. I won’t be able to get to rhem for a while but I will be watching this thread closely so that I might be able to get a working firmware to power one xpl hi on one channel and two Nichia 219 on the other. I will need another board to add some extra 7135s to the lone 7135 on top. We will see?:slight_smile:

Thanks for making these boards by the way!

Unfortunately, most of these designs require traces to run under the 7135’s in order to make everything fit, not allowing room for a big ground pad.

I will be making one change to the board as soon as I can. The ground tab for the 7135’s on the back is essentially part of the ground ring, and when reflowing it tends to “suck” the 7135 all the way out to the edge. I’m going to get rid of the traditional ground ‘ring’ and just add exposed parts of the ring in between the 7135’s

For the firmware, I use BLF-A6 as a starting point for almost everything, so that’s what I would prefer it to be based on. It’s what I’m most familiar with. Essentially we would just need TK’s “TURBO” shortcut to turn Pin3 on instead of just go to ‘255’ on Pin6, and of course make sure the turbo timer still functions. I believe that’s exactly what pyro attempted to do, but I got a lot of compile errors, and the base FW looks weird to me, like it was an Attiny25 version or something. (I’m still stuck on 13a’s). The compile errors looked to be coming from parts of the FW that pyro hadn’t touched.

Ohh yes, I've seen that happen as well - the 7135's getting sucked outward.

Ok on the firmware - I got the boards and all the parts now, and have worked with BLF-A6 before. Just dunno when I can get to it unfortunately - still not over this being sick thing (over 3 weeks now). Yep, I'm not doing much on 13A's now though but still need to support them. I think the base BLF-A6 firmware is super tight in code space, so might not be do-able without losing something.

If something has to be lost, you could probably ditch one of the strobes, those are probably the least-used modes in blf-a6. Personally, I disable all of the hidden modes whenever I use it. I just like it for the easy control of the PWM channels, the two mode groups, and the memory toggle. I don’t really like overly complicated things for clicky lights. Even the multiple mode groups I usually just use to essentially toggle ‘moon’ on/off. I’m going to order some 45’s to use in my dual-switch lights though.

Think I’ve sorted the Firmware: HERE

Sweet, hopefully I’ll have time to give it a shot tonight

That’s for ATtiny13A, right? I thought three outputs wouldn’t work on the t13, or one wouldn’t be able to reflash without a high voltage programming device, wasn’t there something like that?

What we have done is re-purpose pin3 that was originally used for config stars.
Now its just on or off which controls on or off for the FET for TURBO

Wow, that’s cool. I wonder why nobody hasn’t done this before…

Probably a few reasons:

  1. Only on/off possible, no PWM
  2. Multi-channel drivers are still a relatively new-ish thing around here
  3. Someone had to be the first!
  4. Someone probably has technically done it before, but it wasn’t useful at the time.

I’ve made five channel drivers by putting the off time cap, voltage monitoring divider and the E-switch on the same pin. Nothing released though, still working on the 17mm version with four channels of AMCs and a FET on the fifth… and the five AMC channel driver in this light isn’t finished yet either: Custom dual switch driver finally seeing some light.

This board was made with the mindset of bringing some of the functionality of Mike’s driver and Dr Jones’ similar driver, while being more accessible and (hopefully) easier to adapt existing FW. Mike’s is kind of an all-in-one solution from what I understand, the FW and the driver are a package deal (or will be when released).

Either way, I didn’t really do anything revolutionary here.

I remember some Polish(?) guy made a PIC based driver that did about the same about a year ago, and was going to put a mini USB interface on it. I never saw if that project ever got finished. Anyhow, it was his driver and ideas that planted the seed in my head, but at the time I had no skills to make drivers. Anyone know if those drivers with mini USB interface ever became a reality? I’ve probably jumbled up a bunch of different people and projects, I don’t really remember.

If I’m hijacking the thread, let me know and I’ll shut up.

This is the one:

The OP hasn’t been online in over a year, it probably won’t ever happen. It would have been pretty freaking awesome honestly. I wish the pictures would load so I could see how it was laid out.

I think my earlier issues were due to me having no idea how to work with how TK has the new FW set-up (with .h files and such). So I took this and moved all of your changes over to an earlier version of blf-a6 that I can comprehend. Here is a diffcheck of what you posted on the left, and what I just threw together on the right.

I’m down to a final few errors.

About that, on the “nobody has done it before” theme… any idea why nobody has done software based PWM? Only because it has not been needed before? I understand the 13A has built-in PWM on two pins but from what I’ve seen of driver code, it spends most of its time idle so it shouldn’t be too much trouble to toggle any output pin on and off in a loop during that time. I haven’t thoroughly read the CPU’s specs so maybe there’s a catch but the way I see it, it should be possible to get some kind of PWM done on all pins.