3 ms·

To me, it seems useless in the current state, but it seems potentially very useful long-term. The core thing code allows is code, constraints, and subcomponent

To me, it seems useless in the current state, but it seems potentially very useful long-term. The core thing code allows is code, constraints, and subcomponents. I can see writing: <oscillator555 frequency="10kHz"> And having this have a premade parametrized component with layout, as well as knowing about things like power supplies. I can also see this integrating more with GUI tools. There are many steps going forward, not specific to this, which would need to be in place, such as: - Allowing React XML without JSX (e.g. in data files) - Exporting to the above - CSS-style templates and state management ... and similar. Those would potentially permit both code-based tools and GUI tools to interact meaningfully, and that's where the real power would come in. You get there with prototypes like this one, and increments. Ideally, where this would end up is almost: <EPSHome> <ESP8266/> <Sensor/> <Sensor/> <Sensor/> </ESPHome> And a crude-but-working layout comes out, which gets made for $10, populated with ESPHome, and monitors whatever I want to monitor at home. Not much more than STEMMA, but with a nice PCB instead of a dozen cables .

cjk2 2y ago
The thing is though, stuff rarely works like that when it comes to reality. It shows more of a lack of understanding of electronics than is required to build something end to end. There is a lot of futzing that goes on after the idealisms are found to be less ideal and contracts between components are never quite what they seem (consider logic interfacing/impedance etc). And when it comes to analogue things, it gets pretty wild. At that point you have to break the abstraction and know exactly what you are doing. This is a typical failure mode of the Arduino ecosystem; the abstraction only goes so far and then you're shit out of luck. On top of that concerns like decoupling and power routing/distribution are never straightforward. So you have an ESP8266 and you connect it to a sensor and an actuator. When your sensor fires, the actuator causes voltage sag, which causes the sensor to flip back to the existing state. etc etc. Another good example is the ubiquitous LM358. The designer needs to know about the electrical interface and constraints of both the input and the output. The input does not have compliance across the full supply line and the output can only push and pull current on certain load curves leading to weird things like distortion. The abstraction of the black box of the IC is broken then. It's a very complicated subject which is very hard to abstract away. For ref I was an RF design engineer for several years and designed PCBs before that. I moved into software because it paid more and was much much easier (hint)
- seveibar 2y ago
  I think a major issue with how datasheets are translated into existing EDA tools is none of the major constraints are transferred, and you usually need to manually place de-coupling capacitors or other major important components which is pretty tedious. Some tools are a bit better at this, but they might not have parameterized variants or other things that limit how well they can do it. I 100% agree that at some point somebody graduates from Arduino and has to understand that traces are antennas. But the gap is very wide, if every EDA tool gave great static analysis errors, people could incrementally learn many EE concepts that are best learned in practice. A classic error is connecting an LED directly to digital output w/o a resistor for example, why doesn't that throw in every EDA tool? Also: assembly is fairly cheap now- part of the reason people use Arduino is because directly placing an MCU would make a circuit more difficult to assemble, and Arduino stuff can be stacked etc. I think we should have a lot more people's first circuits go right to PCB/assembly, but to do that there has to be good static analysis. For analog designs, SPICE output and static analysis is a big goal. For complex routing, I do think people will often export into other EDA tools or need a GUI router (maybe this is important enough that simple GUI routing should be built in- I have some ideas on how to do this while keeping it code) Unless there is a really really good autolayout engine that can take user-specified hints the reality is real boards will need careful layout and re-layout. > Another good example is the ubiquitous LM358. The designer needs to know about the electrical interface and constraints of both the input and the output. The input does not have compliance across the full supply line and the output can only push and pull current on certain load curves leading to weird things like distortion. The abstraction of the black box of the IC is broken then I think this can be represented pretty well in code, one of the planned outputs is SPICE models and 3d. Sometimes it's not practical for an IC to have a SPICE model, but I think you could emulate a group of components with a black-box SPICE model if it's set up properly. One of the things I'm looking forward to is "complex linting" where a dev could get an error if they e.g. don't emulate a power path via SPICE. If you're open to it (likewise to frognumber above!!!) I'd really love to talk through some of the solutions/alternatives I have planned and see if they land. My email is seve at tscircuit dot com!!
  - mwbajor 2y ago

cjk2 2y ago

The thing is though, stuff rarely works like that when it comes to reality. It shows more of a lack of understanding of electronics than is required to build something end to end. There is a lot of futzing that goes on after the idealisms are found to be less ideal and contracts between components are never quite what they seem (consider logic interfacing/impedance etc). And when it comes to analogue things, it gets pretty wild. At that point you have to break the abstraction and know exactly what you are doing. This is a typical failure mode of the Arduino ecosystem; the abstraction only goes so far and then you're shit out of luck. On top of that concerns like decoupling and power routing/distribution are never straightforward. So you have an ESP8266 and you connect it to a sensor and an actuator. When your sensor fires, the actuator causes voltage sag, which causes the sensor to flip back to the existing state. etc etc. Another good example is the ubiquitous LM358. The designer needs to know about the electrical interface and constraints of both the input and the output. The input does not have compliance across the full supply line and the output can only push and pull current on certain load curves leading to weird things like distortion. The abstraction of the black box of the IC is broken then. It's a very complicated subject which is very hard to abstract away. For ref I was an RF design engineer for several years and designed PCBs before that. I moved into software because it paid more and was much much easier (hint)

seveibar 2y ago
I think a major issue with how datasheets are translated into existing EDA tools is none of the major constraints are transferred, and you usually need to manually place de-coupling capacitors or other major important components which is pretty tedious. Some tools are a bit better at this, but they might not have parameterized variants or other things that limit how well they can do it. I 100% agree that at some point somebody graduates from Arduino and has to understand that traces are antennas. But the gap is very wide, if every EDA tool gave great static analysis errors, people could incrementally learn many EE concepts that are best learned in practice. A classic error is connecting an LED directly to digital output w/o a resistor for example, why doesn't that throw in every EDA tool? Also: assembly is fairly cheap now- part of the reason people use Arduino is because directly placing an MCU would make a circuit more difficult to assemble, and Arduino stuff can be stacked etc. I think we should have a lot more people's first circuits go right to PCB/assembly, but to do that there has to be good static analysis. For analog designs, SPICE output and static analysis is a big goal. For complex routing, I do think people will often export into other EDA tools or need a GUI router (maybe this is important enough that simple GUI routing should be built in- I have some ideas on how to do this while keeping it code) Unless there is a really really good autolayout engine that can take user-specified hints the reality is real boards will need careful layout and re-layout. > Another good example is the ubiquitous LM358. The designer needs to know about the electrical interface and constraints of both the input and the output. The input does not have compliance across the full supply line and the output can only push and pull current on certain load curves leading to weird things like distortion. The abstraction of the black box of the IC is broken then I think this can be represented pretty well in code, one of the planned outputs is SPICE models and 3d. Sometimes it's not practical for an IC to have a SPICE model, but I think you could emulate a group of components with a black-box SPICE model if it's set up properly. One of the things I'm looking forward to is "complex linting" where a dev could get an error if they e.g. don't emulate a power path via SPICE. If you're open to it (likewise to frognumber above!!!) I'd really love to talk through some of the solutions/alternatives I have planned and see if they land. My email is seve at tscircuit dot com!!
- mwbajor 2y ago