It's not complicated. It's just very basic capacitor behavior. If there is a tricky part here then it is in the bit that is glossed over: the switches. But congrats on getting it! Analog is fun, you can get incredibly complex behavior out of a handful of components.
Yep. The state where the capacitor is fully floating relies on non-obvious details. Recall that a (real) transistor has a rated maximum voltage that it can block. But when the (ideal) transistors are opened, there's no defined voltage relationship between (either side of) the floating capacitor and the rest of the circuit; so if analyzed at this level, its not clear if the transistors are within spec or not. You need to at least think about the parasitics to convince yourself that this is sane... or build it with real parts and see that it works.
Indeed. That's why the MAX232 is such an impressive little chip, it was the first time I found an on-chip charge pump in the wild. One of the more interesting uses for charge pumps is loss-free balancing of battery cells. I really like it because contrary to resistive balancing it works with the charge already in the cells by redistributing it.
> It's not complicated. It's just very basic capacitor behavior.
All circuits are just very basic circuit element behavior. In fact a charge pump is a decidedly counter-intuitive thing, up there with things like "why a long-tailed pair makes a differential amplifier" or "how tf does a buck/boost regulator work?".
This is like looking at a 30-line function implementing a FFT and announcing "it's just very basic C code".
I don't know about that. I was building inverters from scratch on intuition when I was 17 or so and I started with electronics properly when I was 11 reading library books, taking stuff apart and putting it (or something else) back together again.
Compared to an FFT, which would require a lot of math insight it seems to me a charge pump is trivial because charging and discharging is what capacitors do, it is the most basic thing you can do with a cap. In programming it would not be the equivalent of an FFT, but more like the equivalent of putting a value in a variable and expecting that value to still be there a while later.
Now, I came into software from hardware, to me software is having an infinite parts box so what's trivial to someone that started in hardware is probably entirely different from the view a software person has of the hardware world. Which is one reason why analog is such a barrier to programmers: they tend to look for the place where the state of the system is stored, rather than that the whole circuit is a continuous function of its input and what happened before. Getting analog circuitry to behave predictably can be quite tricky because of that and just hanging a probe of it will influence the circuit.
Resistors are easy, for the most part grade school math. Capacitors harder but not a lot harder, high school math, some basic integration required. Coils are where it gets more interesting and difficult math wise. And of course parasitic components are everywhere and can make your life harder, especially at higher frequencies or, in the case of single pulses shorter rise and fall times. A piece of wire is a resistor, capacitor and a coil for free all at once. Stripline takes advantage of that fact but without tooling it is next to impossible to work out the math and get predictable results (again, for me, I know people that can do this intuitively).
Multi-pole filters, high gain amplifiers, clean oscillators, those rise to the level of that FFT (for me).
The long tailed pair I agree with, that's a puzzler.
If you don't have one yet (and I assume you do, but just in case): get a scope. They're pretty cheap nowadays and a good scope will do wonders for such insights. I only got one when I was an adult and finally could afford it and it was an absolute game changer. If I had had one earlier I would have gotten a lot more mileage out of my time, especially when troubleshooting broken hardware. You don't need a fancy one, 100 MHz dual trace is more than good enough but that's table stakes now.
One big insight for me is that hardware 'is' and software 'does'. You don't tell a piece of hardware what to do, you design it to 'be' something and a computer simply (ok, maybe not so simply) needs to be told what to 'do'. This took me a long time to really grok after making the jump from hardware to software.
I was trying to figure out where the cursed part comes into it; I assume it's the switching, that typical circuit analysis just doesn't involve discrete states that are swapped between?