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

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?

No, it’s not using PWM at all for those… so it works just like the two banks of 7135s which would be completely on or off on the driver in the OP. The attiny13 only has two PWM outputs, and they’re already used for the FET and one of the three sets of 7135s. So, the other two are all-or-nothing.

In other words, the red+green LEDs only have a few discrete states: red, orange, green, dim red, dim orange, dim green, off. Technically it could also do dim on one and bright on the other, but that isn’t visually distinguishable from just the bright one alone.

Unless I’m wrong (and I could TOTALLY be wrong :-D) this gap actually wouldn’t exist.

Let me add a couple of rows to my hypothetical 2D array:

(single7135, dual7135, triple7135, FET)
(8/255,0,0,0/255) – terrible moonlight
(100/255,0,0,0/255) – brighter moonlight, heh whatever :wink:
(255/255,0,0,0/255) – 1*7135

(120/255,1,0,0/255) – ~1.5*7135

(0/255,1,0,0/255) – 2*7135
(0/255,0,1,0/255) – 3*7135

(120/255,0,1,0/255) – ~3.5*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

Adding in only 1 7135 between modes will likely not look 'right' (once you get up out of the lowest levels using PWM on the single 7135). Is this intended mainly for clicky or momentary control? The number of modes needed for good spacing could get kinda... clunky with a clicky UI. Momentary it would be less of an issue.

Another thing, will the 7135s add anything at all once the FET's turbo is active? Some of those little LFPAK thingies have stupidly low Rds.

Perhaps I misunderstood something. Is the setup like this?

  • 1x7135 — w/ PWM
  • 2x7135 — on/off only
  • 3x7135 — on/off only
  • FET — w/ PWM

So, ignoring the FET for now… the output ranges would be:

  • 0mA to 380mA (smooth): ramp the 1x7135 circuit
  • 380mA to 760mA (jump): turn off 1x7135, turn on 2x7135
  • 760mA to 1140mA (smooth): 2x7135 on, ramp the 1x7135
  • 1140mA to 1520mA (smooth): 3x7135 on, ramp the 1x7135
  • 1520mA to 1900mA (jump): 3x7135 on, 2x7135 on, 1x7135 off
  • 1900mA to 2280mA (smooth): 3x7135 on, 2x7135 on, ramp the 1x7135

The gaps would go away with the PWM on the 2x7135 channel… but it would also incur a cost of making the overall ramp not very smooth. It’s unlikely that 1x7135 + 127/255*2x7135 would actually have the same output as 255/255*2x7135… but this would only matter if it had a smooth ramping mode.

In all cases, the FET could fill in the gaps, but it’d be finicky and inefficient.

What I’m talking about seems really simple to me, but the way you guys are talking makes me feel as if I may be missing something.

I intend to use a 2D array in order to change multiple settings per mode - lots of settings. In the example I’ve given in post #34 the number of settings is 4 per mode: The status of PWM on a single 7135, the binary on/off status of a pair of 7135’s, the binary on/off status of a trio of 7135s, and PWM on an FET. Manipulating those four settings simultaneously (and arbitrarily!) for each mode should be straightforward: we just dump through a loop which parses each setting and sets the output accordingly.

Doing that gives us total flexibility, ToyKeeper that’s where I feel like I may have lost you. It’s a 2D array. A 2D array is like a table: it has rows and columns. If the columns are fixed (for this driver they are the four settings I described above) then to “create” modes we just need to fill in a few rows of settings. Since we are controlling all 4 outputs simultaneously and the gap between 1, 2, 3, 4, 5, and 6*7135 is never greater than 1 we can fill in between any of those positions using PWM on the single 7135. Thus there is no gap in any position.

I have no intention of implementing a smooth “ramping” mode. Clearly that’s not gonna work here, I’m confident that we CANNOT implement a nice version of something like this.

comfychair: I’m not sure I understand what you are getting at unless it has to do with a continuous-ramping mode. Of course the mode spacing will be correct. For H/M/L it could be something like 6/2/1*7135…. if anybody wants to tweak that they can use PWM as I described earlier in this post. If you’re saying that PWM on a 7135 doesn’t generate linear output then you’re certainly right, but I don’t see how it’s a problem unless we were attempting to show the user a continuous-ramping mode (which would look terrible and notchy). We should be able to generate a greater resolution than is available with a 6*7135 Nanjg 105c, so it sounds like an improvement over the status quo.

The 7135s will certainly achieve nothing while the FET’s turbo is active. They are only there to give regulated and PWM free modes.

Hopefully I expressed myself better this time. I’m sure some of it will come off as pedantic but I don’t know where the breakdown in communications is. It could certainly be me failing to comprehend the questions, but if that’s the problem you’ll just have to tell me.

If after all that explanation there’s still a good reason to put PWM on the 2*7135 instead of the 1*7135 please try to figure out a way to tell it to me / explain it to me ;-). Thanks for the input folks.

EDIT: To be clear, she lost me. Oops! Strikethrough added for clarity on that subject. See my next post.

Oops ToyKeeper, my mistake. I see that you’ve got it down pat in your post #36. IIRC my original concepts had two single 7135’s, avoiding the two jumps you’ve pointed out. Somewhere along the line I either forgot or didn’t realize the regression(s) caused by going to a 1+2+3 config.

Your absolutely right, there will be a notch or two.

Another option is to put both 1*7135 and 2*7135 on PWM outputs. The only potential reason for the FET to be on a PWM output is really so that a turbo timer can be implemented…

FWIW, I was thinking of using four const 1-D arrays instead of a 2-D array, in part to avoid any potential need to multiply (costs extra flash space) and in part to add clarity by giving each row a name. Could also allow features to be enabled/disabled via compile-time options more easily. Same concept though, and half of it is already implemented in STAR.

Sounds like a good point. I don’t know what the “multiply” you mentioned is (link for my benefit?), but I’ve been assuming that a 2D array might be unnecessarily costly.

I’ve been eyeballing the 2D array mostly for formatting purposes in the code (easier to edit the modes), but I suppose you could format four 1D arrays in the a similar way. I guess the other advantage of a 2D array is that you might not be able to compile if you mess up the array? EG with the 1D arrays you could add a mode to one array and not to the other… what does an array return for an out of range index? I guess whatever is present in that memory area. Not really a big deal though.

Oh, the multiply thing depends on whether the compiler can figure out how to optimize it out. But if not, saying “foo = values[bar][quux]” translates into “foo = *(values + ((quux*array_width) + bar))”. Not an issue on full-featured processors, but on minimal MCUs it’s smaller and faster to split each row into its own array and do “foo = values_quux[bar]” when possible.

If quux is a literal constant though, and the array size is hardcoded, the compiler should be able to figure out how to optimize the multiply out and use a constant instead.

foo fighter=what? That's way over my head guys. È como você estivesse falando outra língua. Sem esperança.

I’ve continued to barge forward with the existing configuration (1+2+3+FET with PWM on 1 & the FET). Clearly there has been a minor overhaul to the layout. Here is what it achieves:

  • All small components have been labeled, correctly I hope. D1 just got a little triangle :frowning:
  • All non-GND pads are a minimum of 1mm away from the outside edge!
  • All physical component outlines are a minimum of 1mm away from the outside edge!
  • Zener footprint added. (optional)

Note that there is interference between outlines and bare copper, so finished boards may look different.

https://oshpark.com/shared_projects/coO0VDbI