github.com
I've wanted to program circuits for a long time- I started experimenting with the concept of creating circuits in React almost 8 years ago and have spent many weekends since to prove the concept. Over the past 2 months, I've decided to start working on tscircuit full-time.
I'm not sure I'd really want to design an electronics project in jsx though. That's just xml, but also JavaScript. And I guess I think of it more as data than as code.
I was thinking a simple language would be nice, something alternative to a GUI and mouse.
But I was thinking more along the lines of LT Spice's netlist. Or plantuml. Or markdown
Also, I was thinking of html and css. But not so much the syntax as the separation of structure and styling.
You could even have two "stylesheets", one for the schematic and one for the board
My best definition would be: - JSX syntax - Immediate Mode - style API (computing inside UI code and having the same semantics as if it's recomputed on each render frame)
What about OpenSCAD? I haven't looked into tscircuit very much and I barely remember any of the vhdl I did in college, and maybe it's more useful/relevant to make parameterized 2d/3d shapes rather than parameterized circuit components, but I have always been more comfortable with typey-compiley rather than pointy-clicky.
Do you see the future of this project being something like a library of tscircuit components that you can compose together writing code rather than having to use Eagle or other pcb design software? Or I guess somehow autogenerating tscircuit components based on specsheets?
Looking at the code, I see that there's a reconciler here https://github.com/tscircuit/react-fiber/blob/main/src/lib/r..., but that seems to just be a thin wrapper to https://github.com/tscircuit/builder which is doing the heavy lifting of getting to a serializable format. One thing I'm wondering is why is there a need for separate repos since I feel like the tsx portion, reconciler, and builder are kinda needed together?
Yes I see the registry/central library being kind of like npm with a lot of React/tscircuit components that can be dropped into or used as a foundation for large designs, think <Arduino />, <MotorController /> or <Atmega /> etc. I also hope to make part substitution super easy, so equivalent subcircuits can be swapped based on part availability.
Separating into multiple repos makes some things really difficult but creates some nice boundaries. React Fiber is something that a lot of people don't understand (it's also not really officially documented as you may know!) so I wanted to separate it from "pure typescript" and the builder pattern which I think is a bit easier to grok if you're just fixing a bug etc. The codebases are a mess and I'm very eager to do some basic project hygiene- a lot of cruft accumulates over years of weekend development haha.
Thanks a ton for checking it out!!
Makes sense to keep the boundaries between the different libs, but was just mentioning that single repo makes dev work much simpler from my experience (lib boundaries still enforceable with CI or tooling), but obviously there's a bunch of work to get that setup too so might not be super important at the moment.
Looking forward to see where this goes! Also, I think using an LLM to generate components from specs is an interesting idea as you mentioned in a different comment is a great idea to try out too.
Going from schematic back to JSX is a major goal, I'm building an LLM that can do this as well as read datasheets- this is in part to bootstrap the registry with components that come pre-loaded with the recommended decoupling capacitors.
I'm introducing "trace baking" soon that will let you use stuff like the freerouting autorouter (or other autorouters) asynchronously, e.g. you just surround your circuit with <autoroute router="freerouting" cache_id="..."> and it'll use a remote or local server to handle autorouting.
The only minor complaint is that the wires / nets / traces are also components themselves. JSX can only build tree structures but wires turn circuits into graphs, so for those I would have used plain js classes or hooks like useWire and then pass the + and - into the components. That gives you the added benefit of warning when you haven't wired up a component fully. Also allows for required and optional wire inputs on components.
It's wayy easier to collaborate in tscircuit, people can make submodules for eachother! So I could even just take your BOM and try to put something on the registry to make it easier to build out your first design :) good luck!
Kudos, I'll check it out this weekend (or next... :)
I've got a breadboard concept but I have no idea how to polish it up. All of the software GUIs look so intimidating, but I'm very familiar with TS/React!
Also could be used to build an interactive simulator pretty easily.
I mean it's a good experiment and learning exercise but I don't see a practical case for it.
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 .
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)
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!!
This would require repetitive SPICE simulations, or basic rule checking at the very least. Nobody does full SPICE simulations at the board level however basic input/output port checking (usually in the ERC check) does get performed. Even with RF designs, you carve out the piece you need to examine or design and simulate that. For the chips I've worked on, the full chip would get a SPICE simulation that would take days/weeks but this was for more R+D oriented mixed signal designs. I guess what I'm saying is the simulation of a circuit is best performed as a deliberate, iterative step in the circuit design process.
When it comes to layout however, you do get hints from the DRC checking tool (Design Rule Constraints) that will tell you if your trace is drawn incorrectly based on the DRC constraints and nowadays sometimes from an EM simulation that can be run in the background.
Completely automated design especially for analog will most likely never be a thing for the other reasons you list. However, I already can use "known good" circuits and modularize them for reuse which does speed things up. This is critical in the ASIC world due to the large hierarchies in the design. Modular reuse is also a growing tool in the PCB world. Cadence now has a very nice module/reuse tool that can even detect and create modules to prevent you from having to redraw the layout for a sub-circuit multiple times if its not instantiated as a module already. I always like when more people want to get involved in HW, but what the OP is showing largely exists in the form of TCL and SKILL scripts in current EDA SW packages.
Cadance OnCloud Platform for PCB Design is $1500/month. Altium Designer is $11k.
Most of the universe is in the world of KiCAD, Eagle, GEDA, and similar.
The reason I gave a specific use-case is because in this use-case, it does work like that. I did not give a use-case which had RF signals, large currents, or much of anything else. I2C "fast mode" is 400 kbit/s.
The reason things like STEMMA work is because everything is slow enough that parasitics don't matter, and power is low enough that voltage doesn't sag. The lumped element model is nearly perfect there.
Even many domains not like that -- let's say audio -- have a lot of places where abstraction break, but where those failures are well-contained. An audio amplifier might have 50MHz gain-bandwidth, and the layout around it needs to be pretty tight, but once that's a block, things matter a lot less. That's why you can have all sorts of analogue synthesizers where people plug blocks together. A qualified engineer needs to design those blocks, but connecting them, abstractions hold pretty well.
No one will design an oscilloscope or a software-defined radio front-end using React for Circuits. However, as much as those occupy a lot of engineer time, they're actually in the very tiny minority of boards people want built. Most things are pretty simple and dumb.
Heck, even many high-performance designs have simple stuff around them. If you're making a radio receiver, the RF might be voodoo, but you know what's not voodoo?
- The controller for the buttons and the seven-segment displays
- The battery charger / monitor circuit (at least as a block)
- The USB-to-RF232 converter for development (at least as a block)
- The power, temperature, and other monitors
- The neato audio spectrum bar display
- The bass/treble filter (at least as a block)
- A lot of the test fixtures needed to test the RF equipment (not all; a lot of the other test fixtures are deep voodoo; it depends on what you're testing)
- Etc.