Seve - @Abse RE: pico in common<subcircuits.M...

<@757706909351411845> https://github.com/tscircuit/footprinter/pull/709 https://github.com/tscircuit/circuit-json-to-footprinter/pull/10

<@757706909351411845> no sure about the variables names for the usbc footprint haha let me know if you got something better https://github.com/tscircuit/footprinter/pull/712

Specific variants, also dont use any speculative params

Every param needs a test footprintjbb.

Ie, a real footprint it was creted to match

Speculative params are extremely dangerouus

usbcmidmount or whatever is alredy the correct fn for your proposed footprint

I merged it if im not mistaken

Wasnt merged https://github.com/tscircuit/footprinter/pull/708

Idk if that pr is good, but midmount is a good term to indicate it has pill holes

We want to have major variations with expicit fn names

Idk if those examples are real so idk if that pr is mergqble or not

Ok I will take the PR and work over it

Yea its good stuff

I think the configurable/custom pads were the worse thing but lots of good stuff- we just shouldnt have that much customization because it means we were not able to do proper data modelimg

We dont want footprinter to look like a footprint as a string

so if we wanted to support 6 pin we make a 6 pin variant and not pad count ?

possibly! Depends if it has a name that is nice and domain specific

Do you have an example of that? Maybe we can pull all the jlc usbc footprints into footprinter somehow??? Then try to match them and think the best names?

midmount is nice because it implies its mounted, in the middle, most likely with pill plated holes

smdusbc is similarly nice

I dont know anything about 6pins atm

There are ones that stick “straight out of a board”- they would have a custom variant i think

old code , but this is one

Good

this will also be midmount

6pin ?

Yea

Is it midmount tho?

What does the part look like?

Could be 90 degrees

Yep midmount

Yep

just to make sure I understand we will use the same midmount you had in your pr and add _6pin flag ?

usbcmidmount6 seems ok

I think

I dont know if my pr is that great- your original seems very broad but most of the params are ok

Wish i could do a proper review

can you review this , this is after taking inspiration from your pr https://github.com/tscircuit/footprinter/pull/712

we can also wait until you finish the opensauce dont want to make it on a rush

no that seems pretty good imo

<@757706909351411845> I think I finally found the subcircuit bug ``` The child subcircuit routing itself was correct. The bug happened when Core prepared the parent-board SRJ. Expected flow: Route the Pico subcircuit. Preserve its copper as static traces. Mark which exact PCB ports each preserved trace physically connects. Route only the remaining board connections. Actual flow: Core preserved the child copper geometry, so the autorouter saw it as static obstacles. But Core dropped the autorouter’s connectsTo: [portA, portB] property. It replaced it with broad connectedTo electrical-net metadata, which the autorouter does not use for physical route state. Therefore, the board router saw the child copper but did not know that its endpoints were already connected. It generated the Pico’s internal MST connections again, tried routing over the static Pico traces, and eventually ran out of iterations. The fix: Core now preserves the native connectsTo property with only the exact endpoints connected by each physical trace. It no longer expands a child trace into every identifier on the electrical net. This uses explicit properties—not trace-name or exposed_net.* string matching. In the autorouter, overlapping physical pairs are now merged transitively. For example, [A,B] and [B,C] correctly mean that A, B, and C are already one connected component. Verification: Generated board SRJ: 51 remaining connections and 136 child traces. All 136 child traces had physical connectsTo pairs. The full SRJ routed successfully in the autorouter in about 84 seconds. A clean rerun passed and matched the generated full-board SVG snapshot. Core also completed the Gameboy routing using autorouter 0.0.696 with zero autorouting errors. So this was a routing-state contract bug between Core and the autorouter—not a need for more iterations or a Gameboy-layout workaround. ```

most of the snapshots changes is in the svg metadata for the core version when you use `export BUN_UPDATE_SNAPSHOTS=1`

https://github.com/tscircuit/core/pull/2732

<@757706909351411845> https://github.com/tscircuit/circuit-json-to-footprinter/pull/13

<@757706909351411845> https://github.com/tscircuit/tscircuit-autorouter/pull/1708

ooh