Schematic generation

[shanemmattner]

I've been working on generating a schematic with a SKiDL. Here's my progress so far:
To simplify the problem I generate a hierarchical schematic for each subcircuit:

The logic to generate each hierarchical schematic follows this order:

1. Range through default_circuit and create a dictionary of parts/nets for each subcircuit
2. Generate bounding box for each part based on pin locations
3. Assume the first part declared in the subcircuit is the central part. Range through subcircuit nets and place parts connected to central part. Check for bounding box collisions, keep nudging the part 50mil until we're clear of other parts by 100 mil
4. Range through the remaining nets in the subcircuit and place parts connected to the central part ( ie D1 or J1 in the STM circuit). Again we nudge the parts to avoid collision
5. Generate net wires and place them (collision detection with parts is implemented but I don't do anything with it yet)
6. Generate power stubs
7. Draw the rectangle and label the circuit
   
   

There's still a lot more to do but I'd appreciate any feedback. Here's the repo

[devbisme]

I don't know if I have any substantive feedback. The results look as good or better than anything else I've seen, which means they'll still need a lot of manual cleanup. I suspect you'll handle many of the defects as you proceed, but simple heuristics may only get you so far. There may come a point when you want to try elkjs for doing the placement and routing and then convert that back into EESCHEMA files.

You say in step #3 that the first part in a subcircuit is the central part and you go through the circuit placing and connecting each part that connects to the central part. Then in step #4 you talk again about connecting each part to the central part? Did you mean that you go through the parts and connect any that are attached to the parts you connected to the central part in step #3? And then you proceed by connecting any parts that connect to those and so on until all parts are connected?

[shanemmattner]

I tried netlistsvg a while back and it didn't do the greatest job with a whole 80+ piece circuit board. But maybe for smaller sub-circuits a routing library like elkjs would work.

I place all parts before drawing nets. First round of placement is for parts directly connected to U1 (the central part). 2nd round is placement of parts connected to parts placed in the first round. After placement I draw nets, but at this point they are just straight lines from pin to pin so I'll have to figure out how to make them orthogonal.

[devbisme]

netlistsvg seems oriented toward circuits that have a flow, usually from left-to-right (like logic circuits). I think elkjs has a configuration file that can be used to change that (within limits). It might be worth looking into if you run into a roadblock with your current techniques.

Thanks for doing this! Looking forward to seeing the next iteration.

[shanemmattner]

I tried elkjs and the results weren't very good. You can try this for yourself by copy/pasting elkjs.txt into this online editor.

Trying to route myself I've made some progress in orthogonal routing and rotating passives connected to power nets (gnd connections face down, power face up):

As you can see the schematic is ok but not quite pretty enough to use. I'm thinking about 2 solutions to this problem:

• Moderately complex circuits will be wrapped up into their own subcircuit (ie the usb circuit)
• Most/all nets connecting to the central part should be stubs. Similar to what Phil did in this video

We'll see how it turns out. If anyone has ideas/comments please let me know.

[devbisme]

I agree the placement results from elkjs don't look as good as what your code is outputing. One reason for that is elkjs is a flowgraph generator and it needs some extra information on each pin to indicate whether it is an input or output. This works for gate-level logic circuits because there are well-defined inputs and outputs. For a general-purpose schematic, it's more difficult (e.g., bidirectional I/O pins, passive pins on resistors, capacitors, etc.). So you need heuristics to assign I/O directions that will lead to an "attractive" schematic. Not an easy problem to solve.

You're taking a more direct approach and working from a circuits-based perspective (rather than a flowgraph). And you're developing your own heuristics to guide the arrangement of the components. If you think that's the easiest way to get a workable schematic, then I'm good with that! I plan to try your code on a few examples later this week. Should be interesting. (I assume your code doesn't currently handle multi-unit parts like resistor arrays. Correct me if I'm wrong.)

You've used the term "central part" several times. How do you determine which part that is? Is it the one with the most pins? What happens if more than one part fits the criteria for being "central"?

[shanemmattner]

It's probably better to hold off on trying my code for a bit.

I'm going to try and switch to a layout more like the Phil's Lab schematic above and use hierarchical/global labels. This should be easier to make rules for but we'll see how readable it turns out.

[shanemmattner]

I've made some more progress and it might be worth a try. I'm generating all the subcircuits by themselves, then placing them above the central hierarchy:

Here's a little closer view of the subcircuits:

As for the SKiDL code it seems like I ran into some bugs where I cant' use the powerful duplication features of SKiDL like multiple instances of a Part(). For example, declaring 5 filter caps with the code below results in the parts running into themselves infinitely when we try move them and do collision detection.

fc1,fc2,fc3,fc4,fc5 = 5 * Part("Device", 'C_Small', footprint='C_0603_1608Metric', value='100nF')

But if I declare them like this there's no problem:

    fcap1 = Part("Device", 'C_Small', footprint='C_0603_1608Metric', value='100nF')
    fcap2 = Part("Device", 'C_Small', footprint='C_0603_1608Metric', value='100nF')
    fcap3 = Part("Device", 'C_Small', footprint='C_0603_1608Metric', value='100nF')
    fcap4 = Part("Device", 'C_Small', footprint='C_0603_1608Metric', value='100nF')
    fcap5 = Part("Device", 'C_Small', footprint='C_0603_1608Metric', value='100nF')

Let me know what you think and if you need help getting my example running. I'll update the README with instructions.

[devbisme]

That looks surprisingly good.

For the multi-capacitor example, try:

fc1,fc2,fc3,fc4,fc5 = Part(num_copies=5, "Device", 'C_Small', footprint='C_0603_1608Metric', value='100nF')

I'll look into the multi-part problem when I try this out.

Good work!

[shanemmattner]

Thank you! It's a cool project and I appreciate your feedback/help.

Another possible bug: I need to redeclare a net as netclass='Power in every function (found in subcircuits.py) or I get errors

def stm32f405r(vdd, gnd, v_5v):

    l_vdd = Net('+3V3', stub=True, netclass='Power')
    vdd += l_vdd
    l_gnd = Net('GND', stub=True, netclass='Power')
    gnd += l_gnd
    l_5v = Net('+5V',stub=True, netclass='Power')
    v_5v += l_5v

Error logs when I remove the lines above, and replace the net names throughout the function with the argument names:

Traceback (most recent call last):
  File "/home/cdsfsmattner/Desktop/skidl/examples/stm32_usb_buck/main.py", line 24, in <module>
    generate_schematic(file_ = schematic_path, gen_iso_hier_sch=False, sch_size='A3')
  File "/home/cdsfsmattner/Desktop/skidl/skidl/circuit.py", line 1621, in generate_schematic
    if p.part.hierarchy != ("top."+h):

[devbisme]

I found the error that was causing the infinite recursion when multiple parts were instantiated. The problem is that copying a part gives each part a bounding box that is a reference to the bounding box in the original. So when you change a bounding box's origin, the bounding box changes in all the copies and they always overlap.

The fix for this is to define the bounding box for a part when you call the generate_bounding_box method:

    def generate_bounding_box(self):
        self.sch_bb = [0,0,0,0]  # Define bounding box here.
        for p in self.pins:
            if self.sch_bb[2] < (abs(p.x)):
                self.sch_bb[2] = abs(p.x)
            if self.sch_bb[3] < (abs(p.y)):
                self.sch_bb[3] = abs(p.y)
        if self.sch_bb[2] < 100:
            self.sch_bb[2] = 100
        if self.sch_bb[3] < 100:
            self.sch_bb[3] = 100

You should also remove the references to sch_bb in the __init__ and copy methods.

You also need to move step 4 ahead of step 2 in the generate_schematic method in order to have the bounding boxes defined before the part rotation happens.

After that, everything works.

[shanemmattner]

When I started building bigger circuits I started seeing more bugs in the layout. Which encourages small circuits and nested hierarchies. However, I'm struggling with how to layout the nested hierarchies within each other. See the buck0vin_protection circuit:

Any ideas? Placing nested rectangles seems like there should be a canned solution somewhere but I haven't found it.

[devbisme]

I'm probably misunderstanding the question. Why is placing a subcircuit nested within a larger circuit difficult? Can't you view the nested subcircuit as a type of component with a bounding box and then place it the same way as you do "normal" components like capacitors?

[shanemmattner]

I thought it would be that easy but it's proving a bit more complicated that moving parts around inside the hierarchies. For the parts bounding boxes I'm using bb = [x,y,height,width] but you can see how that makes the hierarchy outlines large and has a lot of wasted space, especially when you involve nesting.

I'm thinking I'll have to keep track of the bounding box as a set of points. Thanks for the input, it helps to think through these problems.

[devbisme]

I'm not sure why your bbox representation causes so much empty space. (I assume the dotted boxes correspond to the bboxes.)

At the risk of explaining what you already know, here's how I might approach the problem:

1. Go to the lowest level of the hierarchy which should consist of blocks containing nothing but primitive parts (resistors, capacitors, ICs, etc.). Attach whatever net stubs to these that are needed. Then find the bbox for each stubbed part. Then, arrange the bboxes tightly and use this tight bbox to represent the complete hierarchical block. You'll also have to remember the (x,y) where each primitive part bbox was placed within the block bbox.
2. Repeat step #1 for each of the lowest level blocks in the hierarchy.
3. Go up to the next level of the hierarchy. Repeat steps #1 and #2 using the bboxes you computed for any lower-level blocks along with the bboxes for any primitive parts at this level.
4. Once you've reached the top-most level of the hierarchy, you'll have a complete arrangement of nested blocks. Draw the schematic by going downward through the hierarchy, drawing each block.

As for arranging the bboxes tightly, here's a paper that addresses that problem. I'm not saying you have to use that procedure, but it may spur some ideas for how to do it in your particular application.

Here's a simpler rectangle packing algorithm.

[shanemmattner]

The hierarchy bounding boxes were taking a lot of space because I centered them on the first part instead of the relative 0,0 point for all the parts.

Arranging parts within hierarchies seems to be working well. Making a logical layout of the parts is different than rectangle packing algorithms. We're not necessarily trying to optimize space as much as logical function.

Arranging hierarchies is also different than rectangle packing. I'm trying out a strategy of laying out the hierarchies in levels. So hierarchies attached to the root are placed first, then children hierarchies of those are placed below their parents, etc.. I think this is promising, but will need a readjustment at the end to space everything out logically. Ie boot_sw0 and oscillator0 should move left so buck0vin_protection0 is clearly only under buck0. Then I'm thinking to draw rectangles around parents/children to clearly show what subcircuits belong to what parents.

[devbisme]

Looks good!

[shanemmattner]

Thank you. There's some bugs to work out but overall it's getting close to usable. Here's the whole STM32 board based on Phil's video referenced above:

I'd like to solve the bug (or perhaps I'm doing something wrong) where I need to re-declare nets in functions to connect nets:

@package
def stm32f405r(v_12v, v_5v, vdd, gnd):
    l_12v = Net('+12V',stub=True, netclass='Power')
    v_12v += l_12v
    l_5v = Net('+5V',stub=True, netclass='Power')
    v_5v += l_5v
    l_vdd = Net('+3V3', stub=True, netclass='Power')
    vdd += l_vdd
    l_gnd = Net('GND', stub=True, netclass='Power')
    gnd += l_gnd

    # MCU
    u = Part("MCU_ST_STM32F4", 'STM32F405RGTx', footprint='LQFP-64_10x10mm_P0.5mm')
    # Label signal pins
    u.p5.label = 'OSC_IN'
    u.p6.label = 'OSC_OUT'
    u.p7.label = 'NRST'
    u.p8.label = 'HB' #heartbeat
    u.p16.label = 'USART2_TX'
    u.p17.label = 'USART2_TX'
    u.p31.label = 'vcap1'
    u.p47.label = 'vcap2'
    u.p45.label = 'USB_P'
    u.p44.label = 'USB_M'
    u.p46.label = 'SWDIO'
    u.p49.label = 'SWCLK'
    u.p55.label = 'SWO'
    u.p58.label = 'I2C1_SCL'
    u.p59.label = 'I2C1_SDA'
    u.p60.label = 'BOOT0'

    # Bulking cap
    bcap = Part("Device", 'C_Small', footprint='C_0603_1608Metric', value='4.7uF')
    # Decoupling caps
    fcap1 = Part("Device", 'C_Small', footprint='C_0603_1608Metric', value='100nF')
    fcap2 = Part("Device", 'C_Small', footprint='C_0603_1608Metric', value='100nF')
    fcap3 = Part("Device", 'C_Small', footprint='C_0603_1608Metric', value='100nF')
    fcap4 = Part("Device", 'C_Small', footprint='C_0603_1608Metric', value='100nF')
    fcap5 = Part("Device", 'C_Small', footprint='C_0603_1608Metric', value='100nF')

    #VCaps recommended by ST
    vcap1 = Part("Device", 'C_Small', footprint='C_0603_1608Metric', value='2.2uF')
    vcap2 = Part("Device", 'C_Small', footprint='C_0603_1608Metric', value='2.2uF')

    # I2C pull-ups
    pu_scl = Part("Device", 'R', footprint='R_0603_1608Metric', value="2.2k")
    pu_sda = Part("Device", 'R', footprint='R_0603_1608Metric', value="2.2k")
    pu_scl.p2 += u.p58
    pu_sda.p2 += u.p59

    # Subcircuits
    buck(l_12v, l_vdd, l_gnd)
    usb(l_5v, l_gnd, u.p43, u.p44, imp_match = True)
    boot_sw(l_vdd, l_gnd)
    led(u.p8, l_gnd, 'blue', '5.6k')
    anlg_flt(l_vdd, l_gnd, u.p13)
    oscillator(l_vdd, l_gnd, u.p5, u.p6)
    screw_term_2(l_12v, l_gnd)
    debug_header(u.p7, u.p49, u.p46, u.p55, l_vdd, l_gnd)
    header_4pin(l_vdd, pu_scl.p2, pu_sda.p2, l_gnd) # i2c header
    header_4pin(l_vdd, u.p16, u.p17, l_gnd) # uart header
    mounting_holes(l_gnd)

    # Connect pins
    vcap2.p2 += u.p47
    vcap1.p2 += u.p31
    l_vdd += u.p1, u.p19, u.p32, u.p48, u.p64, bcap.p1, fcap1.p1, fcap2.p1, fcap3.p1, fcap4.p1, fcap5.p1, pu_sda.p1, pu_scl.p1
    l_gnd += vcap1.p1, vcap2.p1, u.p12, u.p18, u.p63, bcap.p2, fcap1.p2, fcap2.p2, fcap3.p2, fcap4.p2, fcap5.p2

Stepping through the program I see the the passed nets to stm32f405r() and other functions are passed as protonets. If I comment out this section of code above then I get errors:

WARNING: Merging two named nets (+12V_1 and +12V_2) into +12V_1.
WARNING: Merging two named nets (GND_1 and GND_2) into GND_1.

2 warnings found during netlist generation.
0 errors found during netlist generation.

Traceback (most recent call last):
  File "/home/cdsfsmattner/Desktop/skidl/examples/stm32_usb_buck/main.py", line 31, in <module>
    generate_schematic(file_ = schematic_path, sch_size='A2')
  File "/home/cdsfsmattner/Desktop/skidl/skidl/circuit.py", line 1621, in generate_schematic
    if netPin.part.hierarchy != ("top."+h):
AttributeError: 'NoneType' object has no attribute 'hierarchy'

Any ideas how I might solve this problem?

[shanemmattner]

Interestingly, if I declare the net in a function (ie stm32f405r() and then pass the net to another function the net properties appear to transfer just fine.

# analog supply filter circuit
@SubCircuit
def anlg_flt(vdd, gnd, vdda):
    # Redeclare power nets, TODO: possible bug
    # l_vdd = Net('+3V3', stub=True, netclass='Power')
    # vdd += l_vdd
    # l_gnd = Net('GND', stub=True, netclass='Power')
    # gnd += l_gnd
    # l_vdda = Net('+3.3VA', stub=True, netclass='Power')
    # vdda += l_vdda

    # Create parts
    c1 = Part("Device", 'C_Small', footprint='C_0603_1608Metric', value='1uF')
    c2 = Part("Device", 'C_Small', footprint='C_0603_1608Metric', value='10nF')
    l1 = Part("Device", 'L_Small', footprint='L_0603_1608Metric', value='29nH')

    # Connect pins
    vdda += c1.p1, c2.p1, l1.p2
    vdd += l1.p1
    gnd += c1.p2, c2.p2

Results in:

[devbisme]

I think what you're seeing is an artifact of the @package decorator. I had to to invent Protonets so that the parts in a package could be connected but not have the nets exist in the total circuit until the package pins were connected to external circuitry. This has some unexpected consequences which you've run into. Changing to the @SubCircuit decorator avoids these problems but requires you to use a function-call interface instead of instantiating the module like it was a Part.

I've recently come up with a simpler way to get the advantages of the @package decorator using the @SubCircuit decorator and returning an interface object that can be used like a Part. Here's ans example of how I do that for a simple voltage divider.

In the future, I may remove @package and ProtoNet because of their over-complicated structure and weird problems.

[devbisme]

When it's convenient, maybe you could issue a PR for what you've done and I'll merge it into a separate branch that multiple people could work on.

[shanemmattner]

Thanks for the explanation. I made a PR targeting development. I'm still learning the git/PR process though so let me know if it's not right and I'll fix it.

[devbisme]

Your PR worked fine. I've made a new branch called gensch from your stuff. It passes all tests. You can work from that and make additional PRs as you proceed. This shouldn't be a big change to your flow; you'll just be working from gensch instead of development. But it will make it easier for me to track what you're doing and make corrections if needed.

[shanemmattner]

I did a little refactoring and created another PR. I just wanted to check that I'm following the process you had in mind before continuing further: I'm developing on my forked master and then creating a PR targeting gensch.

[devbisme]

I refactored the SKiDL tools directory so each tool could have its own directory instead of cramming everything into a single file. That said, do you think it's time to start moving some of the schematic-generating code into the development branch?

[shanemmattner]

There's a bunch of functions in circuit.py that I'd like to move to a appropriate file. I also need to clean up a bit and add comments. I'll make some time this week to get this done.

[devbisme]

OK, it's not a rush thing.

[devbisme]

I merged the development branch into the gensch branch and pushed it to Github. You can pull that and merge in your stuff. Then I can merge gensch back into development.

[devbisme]

Any update on merging your changes to gensch? Doesn't have to be perfect; I can merge it into development if I have something to work against. I just don't want development to diverge too far from what you have.

[MastellaM]

Hi guys,
I saw the project regarding converting netlists into schematics with skidl.
I think it's super cool and I would be super interested in it, since it can speed up a lot PCB design.
I installed the library checking out gensch, but when I try to create schematics starting from one of the Hello World of skidl* I get an empty cell.
I saw on the code that after :

def sort_parts_into_hierarchies(circuit_parts)

the circuits parts, that originally were:

[
 GND (): Power symbol creates a global label with name "GND" , ground
    Pin #PWR1/1/GND/POWER-IN, 
 VCC (): Power symbol creates a global label with name "VCC"
    Pin #PWR2/1/VCC/POWER-IN, 
 Q_PNP_CBE (): PNP transistor, collector/base/emitter
    Pin Q1/1/C/PASSIVE
    Pin Q1/2/B/INPUT
    Pin Q1/3/E/PASSIVE, 
 Q_PNP_CBE (): PNP transistor, collector/base/emitter
    Pin Q2/1/C/PASSIVE
    Pin Q2/2/B/INPUT
    Pin Q2/3/E/PASSIVE, 
 R (): Resistor
    Pin R1/1/~/PASSIVE
    Pin R1/2/~/PASSIVE, 
 R (): Resistor
    Pin R2/1/~/PASSIVE
    Pin R2/2/~/PASSIVE, 
 R (): Resistor
    Pin R3/1/~/PASSIVE
    Pin R3/2/~/PASSIVE, 
 R (): Resistor
    Pin R4/1/~/PASSIVE
    Pin R4/2/~/PASSIVE, 
 R (): Resistor
    Pin R5/1/~/PASSIVE
    Pin R5/2/~/PASSIVE
    ]

result into an empty dictionary hierarchies, which seem kinda be the center of the next part computation.
Am i doing something wrong? I don't have subcircuits at the moment, maybe this is a problem?
Thank you very much for all your effort!
The Hello World i mean:

from skidl import *

# Create part templates.
q = Part("Device", "Q_PNP_CBE", dest=TEMPLATE)
r = Part("Device", "R", dest=TEMPLATE)

# Create nets.
gnd, vcc = Net("GND"), Net("VCC")
a, b, a_and_b = Net("A"), Net("B"), Net("A_AND_B")

# Instantiate parts.
gndt = Part("power", "GND")             # Ground terminal.
vcct = Part("power", "VCC")             # Power terminal.
q1, q2 = q(2)                           # Two transistors.
r1, r2, r3, r4, r5 = r(5, value="10K")  # Five 10K resistors.

# Make connections between parts.
a & r1 & q1["B C"] & r4 & q2["B C"] & a_and_b & r5 & gnd
b & r2 & q1["B"]
q1["C"] & r3 & gnd
vcc += q1["E"], q2["E"], vcct
gnd += gndt

generate_netlist()

[devbisme]

Hmm. You can try pointing at a location where there aren't any KiCad part files:

lib_search_paths[KICAD] = ["/usr/local/etc"]

Then it should throw an error that it can't find any part libraries. If it doesn't, then something is amiss with how it's finding the libraries.

You can also put something like this in main.py:

print(lib_search_paths[KICAD])

and then see where it's looking.

[s39674]

lib_search_paths[KICAD] = ["/usr/local/etc"] does throw an FileNotFoundError.
print(lib_search_paths[KICAD]) without hard coding shows ['.', '/usr/share/kicad/symbols'].

The KeyError: 'x' exception probably arises from using a KiCad 6 library instead of a KiCad 5 library. The skidl library parser adds some extra information to Part objects to aid in schematic generation. This isn't done when parsing KiCad 6 libraries so some attributes are missing. You'll need to use the KiCad 5 libraries.

could you please point me to where it "adds the extra information"? i just don't understand how it adds an extra attribute to the pin class based on a KiCad library version.

Thanks so much by the way!

[devbisme]

OK, now I understand the problem. Your lib_search_paths is pointed at the /usr/share/kicad/symbols directory which stores part definitions in the KiCad6 format. You need to point it at the KiCad5 library directory, and you need to do that before the imports of stm32_circuit and power_circuits (otherwise they'll use the symbols directory). So, right after the from skidl import * statement, place the lib_search_paths[KICAD] = ["/usr/share/kicad/library"] statement and that should cure the current problem.

[s39674]

no luck... i also tried inserting that line in skidl.py:44 and still the same problem...

could you please point me to where it should have inItialised the "x" attribute?

[devbisme]

Look in skidl/tools/kicad/kicad.py at lines 661-663

[shanemmattner]

Sorry, I've been busy finding a new job. And now I just joined a start-up so I don't have the bandwidth to work on this project for the time being. I'll still follow the SKiDL project so if you have questions about my code I'll be happy to answer them.

…

On Tue, Nov 9, 2021 at 12:51 PM Dave Vandenbout ***@***.***> wrote: Any update on merging your changes to gensch? Doesn't have to be perfect; I can merge it into development if I have something to work against. I just don't want development to diverge too far from what you have. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#125 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFJCZNBQLNHZHSR7T54LIYDULGCUPANCNFSM5CJ6P2VQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[devbisme]

Congrats! Hope it works out well.

Is your latest work checked into the gensch branch in the skidl repo? If so, I'll start integrating from there.

[shanemmattner]

Thank you! Yes, all my work is up to date in ```gensch``` branch.

…

On Tue, Nov 9, 2021 at 1:29 PM Dave Vandenbout ***@***.***> wrote: Congrats! Hope it works out well. Is your latest work checked into the gensch branch in the skidl repo? If so, I'll start integrating from there. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#125 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFJCZNEJFIYKNB77RDNQCBDULGHE7ANCNFSM5CJ6P2VQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[devbisme]

I've merged your code into the development branch. The merge still passes all my unit tests and it successfully generates the your example STM32 schematic.

Thanks for your effort!

[devbisme]

Well, after about 21 months of effort, I've released the newest version of SKiDL that generates KiCad schematics. You can read more about it here.