<wpwrak>
the theory is that the comparator opens the p-FET until Vout ~ Vin (~ = approximately equal). then it closes. when the load discharges the silo capacitor, Vout drops and the comparator opens again
<wpwrak>
so far the theory. the question is whether this would actually work or whether i'd get mad oscillations, etc.
<wpwrak>
overshoot should be around td * Imax / C where td = propagation delay of the comparator, Imax = maximum current through the FET, and C = the capacitance of the capacitor
xiangfu has quit [Remote host closed the connection]
<wpwrak>
so even if we assume an extreme worst case of Vout = 0, with Ron = 1 Ohm, C = 100 uF, and td = 1 us, that would be 1 us * 3.3 A / 100 uF = 33 mV
<wpwrak>
what puzzles me is that nobody seems to use this sort of regulator circuit. seems pretty ideal if you need a programmable reg, already have DAC and comparator (common in many MCUs), and don't need huge currents
<whitequark>
wpwrak: oh well, I can say what would be wrong in my view
<whitequark>
(though it's pretty much EE 101 so I would be surprised if you haven't considered that still?)
<whitequark>
your "equivalent circuit" for the FET relies on an invalid assumption. that is, that the turn-on/turn-off time of the FET is insignificant
<whitequark>
you miss a resistor right after the comparator, which will be required to bring the current through the pin in line to absolute maximimum ratings of the MCU
<whitequark>
which will limit the charge/discharge rate of the gate.
<whitequark>
thus, you will operate the FET in the region where it's least efficient pretty much all the time
jekhor has quit [Ping timeout: 246 seconds]
<whitequark>
in the best case you will get, well, a linear regulator, not entirely unlike lm317
<whitequark>
they seem to have needed a more complicated control circuit for ripple rejection
<whitequark>
ah, no, nope, the second opamp is for overcurrent protection
<wpwrak>
(turn on/off time) naw, it should only not be excessively slow. the comparator also has delays in the tens if not hundreds of nanoseconds. so you can just add any FET delay to the comparator's td
<whitequark>
but that's not about FET delays.
<wpwrak>
(resistor) FETs don't need that, only BJT ;-)
<whitequark>
but of course they do
<wpwrak>
not unless ~1 uA is a problem :)
<whitequark>
I am not talking about steady state
<wpwrak>
ah, i see. naw, even then it should be fine. you get a few MHz, tops. that should be pretty negligible.
<whitequark>
the first is the turn-on transient
<whitequark>
which /can/ kill an MCU's output cascade
<whitequark>
like, i have myself killed a few MCU pins before i figured that out
<whitequark>
it's pretty reliable.
<whitequark>
you need at least an ohm there or something.
<whitequark>
the second is the average dissipated power at your "few MHz", which is actually a ton
<whitequark>
let's calculate
<wpwrak>
e.g., the DMG1013T has a "total gate charge" of 580 pC
<whitequark>
and its threshold voltage?
<wpwrak>
[0.5, 1] V
<whitequark>
900mΩ at -2.5V
<whitequark>
or well
<wpwrak>
yes
<whitequark>
really, what your MCU runs on?
<whitequark>
3.3 probably
<wpwrak>
yes, 3.3 V
<wpwrak>
(LP2975) neat ! :)
<whitequark>
hrm
<whitequark>
0.58mA
<wpwrak>
negligible :)
<whitequark>
seems you're right
<wpwrak>
maybe you get this sort of trouble with larger FETs
<wpwrak>
this one is pretty much as small as it gets
<wpwrak>
(for that kind of form factor)
<whitequark>
yeah, that's where my guess was coming from
<whitequark>
I still think you won't be able to get it to switch that fast and it will work as a linear reg
<whitequark>
but that's just another guess
<whitequark>
try it
<whitequark>
I wonder what the effective resistance of the MCU pin driver is?
<wpwrak>
200 Ohm
<whitequark>
8 MHz
<whitequark>
I dunno.
<whitequark>
now I'm interested.
<whitequark>
build it already
<wpwrak>
;-))
<wpwrak>
i guess something like 10 uF may even be enough there
<wpwrak>
let's be generous, 22 uF
<eintopf>
hi
pcercuei has quit [Ping timeout: 250 seconds]
pcercuei has joined #qi-hardware
<eintopf>
did anybody ever see that two GPIO pins are connected together, in firmware one as output the other as input. And then they making some handshake algorithmn to confirm that the firmware running on the right board? :-/
<eintopf>
makes no sense for me
<wpwrak>
could be for identifying board variants, with different boards having different such connections