Another good one: seeing the last diagram, a person on Mastodon said "MOSFET vendors should add pins at 19 + 22. I'd totally buy a few reels for the infinite batteries alone."
I really love this blog for what it is. An incredible source of real life explanations for what you always had for granted that it’s “black magic inside black plastic molded bits that ocassionally happens to let out magic smoke”. I only have some basic college knowledge and what I know is what I’ve learnt from mistakes and successes. Thanks for all these insights and your time to share them with us ❤️
It's a bit like the difference between source code and compiled code under the "as if" rule (the schema on the datasheet would be the source code, what happens in reality, the compiled code).
Is there a better way? Assuming you really want that much detail, a list of math equations doesn't seem like it would be an improvement over the circuit diagram for the MOSFET.
For simple cases, I think you can draw equivalency between the "one slightly more complex equation" and "three less complex equations". I don't *dislike* the approach in electronics, it's just that other disciplines do it differently.
For the transistor case, I think a good litmus test is "would this be more readable in this form, or as a piece of well-commented, expressive code"? Probably the latter, TBH. And it *is* a representation of code, it's just that the underlying xSPICE language is most certainly not self-documenting or readable.
Well-designed source code certainly gives you more room to name things and write comments. And subroutines do help. But having the diagram as well also seems valuable as a map of the code. Otherwise, you need to assemble the connections in your head.
I'm reminded of using OpenSCAD to create CAD drawings. Perhaps some people could visualize the drawing by reading the code, but I wouldn't want to have to work on it without having a preview of what the drawing looks like.
Another good one: seeing the last diagram, a person on Mastodon said "MOSFET vendors should add pins at 19 + 22. I'd totally buy a few reels for the infinite batteries alone."
https://infosec.exchange/@drahflow/114638228092446067
I really love this blog for what it is. An incredible source of real life explanations for what you always had for granted that it’s “black magic inside black plastic molded bits that ocassionally happens to let out magic smoke”. I only have some basic college knowledge and what I know is what I’ve learnt from mistakes and successes. Thanks for all these insights and your time to share them with us ❤️
It's a bit like the difference between source code and compiled code under the "as if" rule (the schema on the datasheet would be the source code, what happens in reality, the compiled code).
Looks like the link to the datasheet is broken. Just links to "source"
Fixed!
Is there a better way? Assuming you really want that much detail, a list of math equations doesn't seem like it would be an improvement over the circuit diagram for the MOSFET.
For simple cases, I think you can draw equivalency between the "one slightly more complex equation" and "three less complex equations". I don't *dislike* the approach in electronics, it's just that other disciplines do it differently.
For the transistor case, I think a good litmus test is "would this be more readable in this form, or as a piece of well-commented, expressive code"? Probably the latter, TBH. And it *is* a representation of code, it's just that the underlying xSPICE language is most certainly not self-documenting or readable.
Well-designed source code certainly gives you more room to name things and write comments. And subroutines do help. But having the diagram as well also seems valuable as a map of the code. Otherwise, you need to assemble the connections in your head.
I'm reminded of using OpenSCAD to create CAD drawings. Perhaps some people could visualize the drawing by reading the code, but I wouldn't want to have to work on it without having a preview of what the drawing looks like.