X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7+dev
X-Exmh-Isig-CompType: repl
X-Exmh-Isig-Folder: inbox
From: "karl AT aspodata DOT se [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] new schematics editor: sch-rnd
In-reply-to: <alpine.DEB.2.20.2305101740130.25839@igor2priv>
References: <alpine DOT DEB DOT 2 DOT 20 DOT 2305030528180 DOT 25839 AT igor2priv> <20230510101305 DOT 795EF8615734 AT turkos DOT aspodata DOT se> <alpine DOT DEB DOT 2 DOT 20 DOT 2305101339380 DOT 25839 AT igor2priv> <20230510144307 DOT BBFFE8615738 AT turkos DOT aspodata DOT se> <alpine DOT DEB DOT 2 DOT 20 DOT 2305101740130 DOT 25839 AT igor2priv>
Comments: In-reply-to "grnd AT igor2 DOT repo DOT hu [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
   message dated "Wed, 10 May 2023 18:39:35 +0200."
Mime-Version: 1.0
Content-Type: text/plain
Message-Id: <20230511133114.27EC58615752@turkos.aspodata.se>
Date: Thu, 11 May 2023 15:31:14 +0200 (CEST)
X-Virus-Scanned: ClamAV using ClamSMTP
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Igor2:
> On Wed, 10 May 2023, karl AT aspodata DOT se [via geda-user AT delorie DOT com] wrote:
...
> One way is how gschem and lepton (and tinycad and some others) do it: you 
> store the graphics and any time you want to make conclusions on the 
> meaning of the graphics, you have to go and figure which line touches 
> which other line, where they touch pins, etc.

Yes, bad choise.

> The other extreme is what sch-rnd does: we store the sheet in a grouped 
> fashion, so storing the logics. Instead of a heap of random wire lines, we 
> have a wire net group for all the lines (and junction graphics) that make 
> up a connected "net segment" (our terminology is wirenet for this). When 
> you draw in the GUI, it just updates the groups. Like if you connect two 
> wirenet groups with a wire on the GUI, the GUI needs to merge the two 
> wirenet groups. We also have explicit connection objects that connect 
> wirenets to terminals or terminals to terminals. So you don't need to 
> guess connections by coords either.

Much better.

...
> > If you look at 
> >   stm32f100lm.power.LQFP100.sym
> >   stm32f100lm.power.LQFP48.sym
> >   stm32f100lm.power.LQFP64.sym
> >   stm32f100lm.power.TFBGA64.sym
> > from above link, you'll see that the symbol box is the same size, and 
> > that e.g. VDD_1 for all of them are at the same position. That means
> > you can start with lqfp48 chip design, realize you need some more pins
> > and just swap out the symbols, the present caps will connect at the
> > right place and you can just add the "missing" caps.
...
> Or maybe just have a single VDD and a single VSS terminal on the symbol 
> and let devmap bind it to multiple physical package pins.

Good idea.

...
> What I meant by alternate pin functionality is more like this:

I look forward to see what you come up with.

Regards,
/Karl Hammar