Mail Archives: geda-user/2023/05/11/09:50:55
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
- Raw text -