21 Replies
GitHub
Implement the
<connector standard="usb_c" /> flow · Issue #748 ...Lots of steps, many PRs Implement Connector.ts in tscircuit/core Implement the relevant API inside the parts engine to retrieve USB connectors https://github.com/tscircuit/parts-engine Make sure th...
I want to work on this with @Anas
okey doke
should we make the standard prop enum with only tested connectors in it >
?
What kind of connectors do we have to start with?
you can focus on just USB_C
CC @Rishabh IIUC they'll also need async footprint loading, that alone is pretty tricky.
how can we do this ?
The autorouter and parts engine inside core both use async effects. Basically you want to pause rendering until you’ve found the requested part and footprint. You’ll probably need to introduce a new render stage
Its not that complex it just requires understanding the pipeline a bit
what should we take from ] jlcpcb everything like pin labels , footprint,3d or just footprint
Everything yea
You also have to ensure that the standard pins are always provided
Otherwise its not viable
The parts engine should handle some of that
where is the api that return the components from jlcpcb ?
The parts engine uses jlcsearch.tscircuit.com
GitHub
GitHub - tscircuit/parts-engine: The tscircuit platform parts engine
The tscircuit platform parts engine. Contribute to tscircuit/parts-engine development by creating an account on GitHub.
@Seve can't we just use the easyeda-converter in core for fetching the footprint ?
No core isnt allowed to have any third party integrations
The parts engine is allowed to
kk
You may need to somehow get jlcsearch to return footprint information and/or cache it appropriately
If easyeda goes down we dont want circuits to fail, so we may need a long cache. But if you implement something clean in the parts engine this should be nbd
Eg i think with the easyeda converter you can swap the api url to api.tscircuit.com which can cache stuff
we will make the connector a chip like component and get the footprint , cadmodel , pinlabels etc from the parts-engine is this right ?
Sort of. Keep in mind the bigger picture. If a user uses
<connector standard="usb_c" />, then they should always, 100% of the time, be expecting the same pin labels and the same schematic representation. That should never change, there should never be new or unexpected pin labels. However, the footprint might change depending on what the parts engine returns. That's what makes the connector useful but also difficult to implementshould we hard code that pinlabels and parse them for eg: GND1 = A1/B1
Yea basically, you should use the most standardabels for usb. And yea you can hard code those into core for the standard