4 ms·
There's a nugget of a great idea here, the realization that there has to be a better way to describe schematics than drawing them. Unfortunately, most comments
by patrickyeon 10y ago
There's a nugget of a great idea here, the realization that there has to be a better way to describe schematics than drawing them. Unfortunately, most comments seem to be distracted by the trees of what is started here and are missing the forest that is the potential. (Aside: ever stuck on a problem or need to prompt someone else to start talking through a problem, especially in an interview? Ask "what's the worst solution that could be argued to work here? How do we improve it?")
So, what would a more exciting example include? How about sensible "default initializers" so that I don't have to wire up all the power pins, decoupling caps, pull-ups, pull-downs, and no-connects that 98% of the designs for a particular chip need?
What if instead of having to draw this: http://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/166/2541.Untitled.png http://e2e.ti.com/cfs-file/__key/communityserver-discussions... I could just enter:
cpu = msp430(vcc=3v3)
storage = sdcard(vcc=3v3)
sd_bus = storage.connect(cpu, I2C_FAST) # let cpu and storage negotiate their pins
# sd_bus is now a list of nets that make up the connection
utils.apply_pull_ups(sd_bus, 50K)
That's all very possible, computationally, but so much less tedious than drawing it out and so much more descriptive of what I'm actually trying to achieve. As a bonus, it has properties programmers forget so many other people's tools don't: it's good for line-based diff, search/replace, and source control.
Another example: Most of what's going on here: http://www.mikrocontroller.net/attachment/162013/freqgen.png http://www.mikrocontroller.net/attachment/162013/freqgen.png is defaults (it's also, and I wish I could say this nicely, in my opinion a very poorly drawn schematic). Instead:
loop_filter = utils.third_order_bandpass(freq_min, freq_max, RC_ONLY)
freqgen = adf4350(vcc=3v3, cp_filter=loop_filter) # boom, all sensible defaults
for pin, color in zip(freqgen[LD, CE, LE], ('green', 'red', 'yellow')):
pin.net.connect(status_led(color=color, brightness=30mcd))
# let the computer work out your resistor value
freqgen[RFOUT_A].connect(BNC(50Ohm, SINGLE_ENDED))
freqgen[RFOUT_B].connect(BNC(50Ohm, SINGLE_ENDED))
# let the computer work out that it terminates the complementary output
The linked project isn't nearly at this point, but I consider it in the same spirit. We have to go through the awkward solutions while we iterate towards a great one, I would say.
- TFortunato 10y agoOn this note, as an embedded systems guy, I was happy to see STMicro thinking about tools like this, with the STCubeMX software they've been developing: http://www.st.com/en/development-tools/stm32cubemx.html http://www.st.com/en/development-tools/stm32cubemx.html One of the pains about larger embedded designs, is that while newer processors/microcontrollers have so many different peripherals and ways to use them, there are just as many constraints about which functions can go to which pins, how each peripheral is clocked, etc.. Their tool is similar to what you mentioned, in that you tell it what peripherals you want to use, and how, if you have any pins you need to lock down, etc. It will then solve these constraints and give you a pinout and clock setup that will work, along with boilerplate code to get you started. I would love to see an open-source effort in this space...basically a parametric framework / boilerplate generation for embedded systems designs (hardware and software).