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.
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!
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.
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.
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.
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 1we 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.