[WIP][mostly retired] 17mm DD+7135 -- linear regulated driver w/ FET turbo

I knew I forgot to mention something.

I moved the solo 7135 onto PB0. The firmware should be able to put PWM on either the FET or the single 7135. With a single 7135 you can probably get moonlight low enough and still be regulated… I’m too lazy to try it.

It seems almost certain that a driver with one chip with a low pwm input will be capable of a lower moon mode than a driver with 8 chips at the same value. This made me think of WarHawks test board for 7135’s. By hooking that board up to a driver set to moon mode it should be possible to test various 7135’s to sort them by their low level output. They’re fixed and pretty uniform at full but not nearly as uniform at low levels. Now I have to find that thread again. Where is it? I saw it under the chair a minute ago.

So is this driver actually on the card of becoming a reality?

Wow, I also have thought about adding one or two 7135 to a FET driver but you squeezed 6 on it. AWESOME!

Just publishing the Ostpark link, that we can Order and start to adjust the firmware for that driver.

Yes, I think so. The initial firmware may not be the best, but just last night I got help with a critical thing I didn’t understand (#402). I’ll try it out PWM on PB1 today on yet another unfinished project.

Your wish is my command. For this driver and others that use multiple output pins I was thinking of using arrays for mode storage. Maybe a 2-dimensional array could hold all the modes and all the PWM settings at the same time. I think that might eat up a lot of memory though, I haven’t tried it.

Any updates on this?

Honestly with what you are wanting to do…wouldn’t a ATtiny25A work better…same as the ATtiny13A but with 2K of programming space

I still think 0603 pads and still use 0805 components would free up alot of space, either way still an awesome build

Good question! No firmware updates from me, I haven’t done anything useful.

I started to do something productive (not related to firmware) earlier today and then caught myself and fired up Eagle instead ;-). I’ve decided that RBD is right, the DPAK sized FET is a waste of space. The board now requires a Power-SO8 (LFPAK) sized FET. This shouldn’t incur any cost or performance penalty, so “it’s all gravy” as they say.

I’ve implemented the [June/July 2014] anti-boost fix for the DD drivers (eg I moved the decoupling cap electrically to the other side of the diode). I removed the resistors previously present which were related to driving the FET properly, IIRC they aren’t necessary for this after moving the cap.

Between those two changes the top of the board is looking a lot less hateful for anyone who has to solder this by hand. I think it looks completely doable now.

As usual note that there is no firmware so this hardware is just for firmware developers and masochists.

Here it is on OSH Park: Firmware Developers Only - 17mm DD+7135 v012

Wight, does this use the normal attiny13a? If so, there has been firmware out for a little while that will do what you want it to do.

Interesting how the 7135 chips are addressable separately. That should greatly help improve efficiency on low/med modes. With an attiny13 though, only two can use PWM at a time and they share a counter. I’m guessing it would use PWM on the single 7135 (to cover all the low modes) and also on either the FET or the double 7135?

Although I think the desired behavior would probably fit into 1024 bytes, I don’t really see any reason to use an attiny13 on a custom driver instead of something with more space… attiny25 or 45 maybe? They don’t cost a lot more, and the extra room is always nice.

I suppose it wouldn’t be all that much beyond the existing alt-pwm driver code… one array for the pwm ceiling of each mode, one for the alt pwm ceiling, one for specifying which other channels should be on/off, maybe one to specify which pwm channel(s) should be used.

Wight is designing this board but as of yet there isn’t any code written specifically for it. It would be great if someone with consummate coding skill could step up here to help flesh this out. If there is similar code already available say for rgb drivers that might be adapted it might cut the task down a bit.

RMM, it does. I missed about 45 posts of development over on the STAR thread, but skimmed it afterwards. I didn’t think I missed something like that though. Are you sure there is a firmware which can handle this? It’s a pretty different proposition from what we do with other drivers. Either way, please link me to whatever you are thinking of! :smiley:

You are correct ToyKeeper - the two pins with PWM available are tied to the single 7135 and the FET. Really I suspect that with this many 7135 addressable like this you only need the PWM on the single 7135 for setting the brightness of moonlight. You’re also correct about the MCU - an ATtiny25 should fix any space issues. OTOH if the software fits on the same chips we use for everything else… meh.

Like I mentioned somewhere, I figure a 2D array representing each output from the ATtiny would work well. You could extend the array to cover PWM types as well. I could be wrong, I have no idea what impact on available resources an array like that would have… doesn’t seem like it would be that bad. That way you could say
(single7135, dual7135, triple7135, FET)
(1/255,0,0,0/255) - terrible moonlight
(100/255,0,0,0/255) - brighter moonlight, heh
(255/255,0,0,0/255) - 1*7135
(0/255,1,0,0/255) - 2*7135
(0/255,0,1,0/255) - 3*7135
(255/255,0,1,0/255) - 4*7135
(0/255,1,1,0/255) - 5*7135
(255/255,1,1,0/255) - 6*7135
(0/255,0,0,255/255) - FET Turbo

or anything along those lines you wanted. (I’m sure you understand this, but for the benefit of others reading… Nobody wants that many brightness levels in their regular mode group of course! You’d define the array accordingly with whatever modes you want, those are all examples.)

That’s more or less what I had in mind too. Except… 100/255 is a “moonlight” mode? On an XM-L2 with 1x7135 that’s like 80 lumens!

In any case, it doesn’t sound like it’d be particularly difficult to make the firmware for that type of driver.

I wonder if perhaps the 2x7135 circuit should have PWM instead of the 1x7135 circuit though… because otherwise you end up with a gap between 380mA and 760mA where no modes can exist, and another between 1520mA and 1900mA. The 2x7135 PWM option would make it gapless.

I missed the part where you were trying to individually address 7135s. I thought that you just needed 2 PWM outputs...that is possible.

which firmware is that?

STAR has dual PWM out now.

What’s the purpose of that RMM? I’m workin on a new project (the dual head DX21 clone) [using a PIC 18F1824] with 4 PWM out’s (3 to the 2 emitters, one to a set of red/green battery indicator LED’s). For my purpose each emitter needs 1.5PWM lines (2 but using a series of BJT’s they can share one of them).

The main purpose is being able to control a FET+7135 or a bank of 7135s then a single 7135 for a much lower and more stable moonlight--or any other combination imaginable. It is also great for the new 25mm MT-G2 Noctigon with the 4 small XQ-E pads. I am using the second output to power a 7135 slave board besides the main FET for the 4 XQ-Es.

So, yeah. The reason I think this would be easy to do is because the alt-pwm code is already written and I’m already controlling two extra LEDs individually in the firmware for another driver. That one is doing red+green LEDs to show voltage (not extra 7135s for the main emitter), but the code for it is mostly the same.

You’re doing both the R and G with a single PWM?