[HN Gopher] Show HN: React for Circuits
___________________________________________________________________
Show HN: React for Circuits
Hi HN! I've been working on a new way to build electronics/PCBs
with Typescript/React, I'd love to know what you think!! 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.
Author : seveibar
Score : 160 points
Date : 2024-04-26 22:39 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| WaxProlix wrote:
| I initially laughed, but this is very cool actually. I love the
| pluggable/reusable 'component' registry idea.
|
| Kudos, I'll check it out this weekend (or next... :)
| seveibar wrote:
| Cheers! Yes the reusability is really why React blew my mind
| years ago, unlike other frameworks at the time, React could
| really just be "dropped in"
| Flux159 wrote:
| Nice, it's an interesting concept and always like exploring new
| ways of using react in other contexts (react-three-fiber being
| easy to use for simple 3d projects, I have also written an Unreal
| Engine reconciler prototype earlier built on an Unreal JS plugin,
| but decided not to pursue it further).
|
| 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?
| vbezhenar wrote:
| I tried to use JSX syntax to generate PDF files. In the end I
| didn't go this way, but it was interesting idea, worth
| exploring.
| seveibar wrote:
| That's awesome to hear!! React Fiber is super cool and I love
| to see new stuff on it!
|
| 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!!
| swalsh wrote:
| This is really cool. As someone who knows enough to get
| something working, but nothing more, I've always dreamed of
| something like you're describing.
| Flux159 wrote:
| Yeah the reconciler docs were even worse when I was working
| with it, I had to ask the team to help with better docs or
| code pointers.
|
| 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.
| looneysquash wrote:
| Looks pretty cool.
|
| 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
| seveibar wrote:
| Really appreciate the insights!! I think JSX/TSX are a lot more
| powerful than most data representations because 1) you can
| modularize and import sub-circuits really easily and with an
| effective known pattern (the npm registry installation pattern)
| 2) you can compute pretty complicated data from relatively
| simple React components, e.g. <DualInlinePackage pad_count={6}
| /> produces 6 pads with standard spacing. I also think it's
| really powerful you can add type validation (e.g. any odd
| number is invalid for pad_count). I'm counting on smart people
| creating awesome patterns/higher-level-components just like
| they did with React for web!
| sesm wrote:
| It kind of interesting to think, how can you define 'React
| for X'?
|
| 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)
| fendy3002 wrote:
| Yeah because jsx is popularly used by react (and even maybe
| the first?), people associate jsx as react. We need more
| jsx (tsx) outside of react, or compilable / type definitive
| xml.
| kennywinker wrote:
| You might be interested in atopile or pcbdl - they're much more
| like what you're describing
|
| https://atopile.io/
|
| https://google.github.io/pcbdl/doc/_build/html/readme.html
| meta-level wrote:
| Could this approach also be used to script a Factorio blueprint?
| seveibar wrote:
| You can build anything with a React Fiber layer, people have
| compiled things to mobile, 3d, VR, equations etc. Unironically
| I think that's a great project :)
| tmitchel2 wrote:
| Awesome work, I've developed my own projects which are fairly
| similar to this. I would say that the auto router is the most
| important aspect for this to work well, and unfortunately one of
| the most complex areas :)
|
| 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.
| seveibar wrote:
| useWire and other type-safe routing features are coming soon!
| You are 100% correct that the way it's currently being done
| can't leverage the type system. I also agree that autorouting
| and auto-layout are critical (in the same way flex is important
| for web!!)
| tmitchel2 wrote:
| Also checkout projects like spinalhdl, it's not really for
| PCBs and doesnt have JSX but the concepts are similar. Has
| things like wire bundles which is where the payback from
| these approaches really kick in.
| clord wrote:
| I like the idea of autolayout like flex for routing wires.
| There needs to be things like busses etc., feels like there
| is something there that could be flexed. Problem is the
| multiple dimensions of connections, so maybe something
| inspired by grid layout and grid template area?
| seveibar wrote:
| Exactly! I'm hoping to expose autorouter/autolayout to
| userland (e.g. "drop your function here") and see what
| clever people come up with. I have some ideas but there's
| so many fun ways to do it so I'm cautious to sink too much
| time in. But it's a super important problem and I do think
| a new multi-layer flexbox/cssgrid could make wiring work
| really well.
| franky47 wrote:
| This is really cool. I've been doing a lot of EE and PCB design
| back in the day with Eagle, nice to see this kind of tech landing
| in the browser. Great job!
| gedy wrote:
| Very nice work, thank you. This is a nice intersection of my tech
| interests, both React and I like to make custom keyboards. I've
| never liked using the drag and drop design tools for circuits, so
| I'm keen to try this.
| seveibar wrote:
| Let me know how it goes! I would love talking to people working
| with it, so if you'd like drop me a line!! seve at tscircuit
| dot com
|
| 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!
| cjk2 wrote:
| Not wishing to kill the idea, but this looks much harder rather
| than easier to lay out boards. Also the outcome is not what I'd
| call even remotely normal for a board design.
|
| I mean it's a good experiment and learning exercise but I don't
| see a practical case for it.
| frognumber wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| "....why doesn't that throw in every EDA tool?"
|
| 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.
| UberKryos wrote:
| Hi, this looks sorta interesting, I was wondering if you would
| have plans to be able to go from schematic or layout back to the
| jsx, so people familiar with the more traditional tools would be
| able to port stuff to this ecosystem? Also I would love to see
| something like being able to length and/or impedance match traces
| as well as input pcb design rules and net constraints. Will there
| be an easy way to represent gnd and pwr planes/polygon pours?
| seveibar wrote:
| There will absolutely be stuff like ground pours (probably via
| a <pour /> component) and the ability to create user-specified
| constraints and static analysis.
|
| 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.
| imtringued wrote:
| This is only useful for the code generated parts of a design. For
| most basic circuits the freerouting autorouter already works well
| enough. The real challenge isn't laying out a PCB. It is
| simulating and checking that it works before production. The
| proprietary tools can do that. Board houses often inspect your
| work using proprietary software. What is needed is an open source
| equivalent that packages the existing solvers in an easy to use
| UI.
| seveibar wrote:
| I totally agree that static analysis is critical and that's
| going to be a major effort. I see tscircuit as a great
| foundation for open-source static analysis as well as GUI tools
| to be built on (otherwise, it's kind of hard to render circuits
| to the web!)
|
| 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.
| junon wrote:
| In your video you mention that with 50 dollars you could have
| that board shipped to you, but my brother in christ if you are
| paying anywhere near 50 for that board you are being scammed :D
| amelius wrote:
| Fwiw, I often pay $5 for a board, and $40-$50 for shipping from
| China.
| seveibar wrote:
| yep I ordered something like the board in the video (with a
| couple extra components) and for 5 boards (min quantity) it
| was $5 for PCB, $35 for assembly + parts, $25 for shipping.
| It'd be great if prototyping was cheaper but for a business
| it's totally fine.
| nixpulvis wrote:
| Would be really cool if you could omit the x, y coordinates and
| it would place a reasonable layout for the schematics and
| footprints.
| seveibar wrote:
| Actively working on this! It will take some time to get right
| but I agree it's a critical feature
| https://x.com/seveibar/status/1783672107702030778?s=46
| shepherdjerred wrote:
| Could I use this to create a board that hooks up a
| ESP32/Raspberry Pi to some LEDs/switches/potentiometers?
|
| 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!
| seveibar wrote:
| It's a bit buggy right now but you should absolutely be able to
| do a simple project like that! I'm happy to help, my email and
| a community chat are on tscircuit.com If you haven't built PCBs
| before it can be a bit tough, but it's worth it for how many
| potential boards you can build!!
| iyifr wrote:
| Why react ??
| throwaway11460 wrote:
| Reusable parametrized components and state updates (for
| designer tool) for free.
|
| Also could be used to build an interactive simulator pretty
| easily.
___________________________________________________________________
(page generated 2024-04-27 23:01 UTC)