Mail Archives: geda-user/2023/05/10/12:59:38
On Wed, 10 May 2023, karl AT aspodata DOT se [via geda-user AT delorie DOT com] wrote:
>...
>> I mostly finished my own toolkit last year, called miniboxtk,
>> between an sch-rnd and a librnd rush. Miniboxtk is small, portable,
>> focuses only on being a toolkit, so unlike gtk it doesn't want to be a
>> programming environment. It has different backends; one of the backends is
>> raw xlib - no xt, no xm, no nothing, just raw, direct xlib.
>
> xlib is slowly beeing replaced by xcb...
Doesn't affect miniboxtk. On the hosts where you have xlib, you can use
the xlib backend which clearly has the smallest footprint. Then on the
hosts where you don't have xlib because xcb or wayland or whatever else,
you can use the sdl2 backend. Which has a large footprint, but works
"everywhere" (except old, pre-c99 UNIX). The large footprint and higher
software stack is the price you pay for the fancier GUI system (e.g.
wayland) I guess.
(In theory I could write an xcb backend to miniboxtk, but I really don't
see any situation where it would get me support a system that sdl2
wouldn't support. So it'd be just waste of time to write it.)
<snip>
>> For a., my plan from long ago is to have subc-in-subc support in pcb-rnd.
>> During the big data model rewrite many years ago, I already had this in
>> mind so everything is prepared to make it possible. However, I couldn't
>> get gEDA to cooperate from sch editing side back then, and without sch
>> side support subc-in-subc is pretty much useless in practice, so it went
>> on hold.
>
> I think what is needed is a netlister that doesn't go down to subsheets,
> just one that says between theese symbols and theese subsheets we have
> theese connections.
Yup, I have provisions for such thing (except we don't have netlisters in
sch-rnd, we use a different mechanism: concrete and abstract models and
compilation in between).
> I was doing a prototype such, but realised that there is implicit nodes
> in nets: if a net lines endpoint is on a horizontal or vertical net line,
> then thoose two net lines belongs to the same net. So when detecting
> nets it isn't sufficient to look at the endpoints, and there is a
> difference between inclined lines and horizonta/vertical ones. It would
> be best if nets only connected through the line segments endpoints.
We don't have that problem with sch-rnd. It's a design decision.
(Warning: boring design/implementation details coming)
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.
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.
This makes implementing the GUI much harder, and I spend some time
debugging and fixing related bugs. But it also makes everything else much
simpler, as nothing needs to deal with line coordinates. You look at a
line object, it has a parent, if the parent is a wirenet group your line
is a wire. And then you instantly know the whole wirenet plus it's very
easy to look up the connection objects that refer to it, and then going
through those connection objects you already know what other objects are
connected to this wirenet. All this without ever looking at any
coordinate.
(There are in-between soltions too; altium for example seems to store
mostly graphics like gschem, but it also explicitly stores the junctions.
But for wire-pin connection or wire-wire endpoint joint (like an L shape,
no junction) it doesn't store logical info, so that still goes by coords.
So you still need to figure which wire line touches which other wire line
or terminal, but at least you don't need to figure which wire-wire
crossing would connect the wires and which ones would not. But I guess I
am going too deep in implementation details again.)
<snip>
>> We already have an external edit feature so pcb-rnd can fork and run a new
>> pcb-rnd instance for you to edit the content of such a subcircuit.
>
> Nice.
>
> One thing with lepton-schematic I really like (cannot run gschem since
> no python 2.7), is that I can copy things I select between instances of
> the program, and also that it can have a few schematics in different
> tabs.
>
> Pcb cannot do either of that, which is a thing that I miss.
>
> Can I copy&paste between instandes of *-rnd ?
Not the buffer at the moment. But it wouldn't be too hard to implement.
It couldn't work the same as with other software, plain ctrl+c/ctrl+v,
because of the way paste buffers work in pcb-rnd (and geda/pcb too),
including the UI logic and how/where the data is stored and that there are
multiple buffers. But I think it would be easily possible to create a
virtual buffer that interacts with the system clipboard.
You can copy&paste some things through system clipboard already. For
example padstacks in pcb-rnd: you can create a padstack in one instance,
put it onto system clipboard and paste it in another instance.
Implementation details:
- the librnd HID API has a pair of calls for putting and getting textual
data on the system clipboard
- we can serialize any part of our data in our native file format, based
on lihata; lihata can represent a tree, so it's very easy to deal with
subtrees
Putthing these together, it's trivial, usually some few dozen lines to
implement a full round trip of some data through the system clipboard; the
real question is always how it fits in the existing UI model. And whether
any actual Ringdove user really needs it.
For example with paste buffer the demand is low since pcb-rnd can save and
load buffer content to/from file. This differs from saving
buffer subcircuits: it's not saving "footprints", it's really saving the
whole buffer content. So you can simply use a temp file for communicating
between instances. In sch-rnd we support opening multiple sheets and the
buffers are shared, so you rarely run multiple instances, demand is low
there too.
<snip>
>> Where this method doesn't work so good is editing. When you need to swap
>> two slots, it's much esier to edit 2 attributes then fully replacing two
>> symbols. Plus keeping only one slotted symbol file in a lib instead of a
>> slotted symdef file then many generated per slot sym files is much easier
>> too.
>
> Isn't devmap a good candidate for handling slotting ?
It is, and that's our standard slot support for many months already.
> E.g if you have lots of opamps, and in the subsheet you don't know
> which refdes and slot this or that opamp will have since at the
> subsheet level you don't know what the user will combine this subsheet
> with.
At the end, if the name ("refdes") matches, symbols combine, regardless of
slotting. For hierarchic setup we'll have mechanisms to avoid unwanted
combinations - this is part of the design doc, already documented,
available on the web page.
Anyway, I brought this slotting exampel up only as a parallel. If letpon
didn't have hardwired slot support in GUI, you would have written a
similar script that produced a set of symbols for slotting. Same goes for
alternate pin functionality: if the editor doesn't offer a mechanism, you
have to work it around, most probably by a very similar symbol generator,
which I think you wrote for lepton. But sch-rnd will have (an optional)
mechanism so you don't necessarily need to make any workaround.
>> I don't yet know the details, I will design the system when I get there
>> (probably later this year), but it will be attribute based, it will have
>> GUI and CLI support and just like slotting, it will be able to get
>> displayed on the sheet too. And it will all sit in an optional plugin
>> distributed with sch-rnd.
>
> So, you are aiming for something that just changes the pin label so to
> say.
More generic: changes attributes.
We don't have "pin labels". That's too hardwired. We have text objects:
any number of text objects you want, and they can reference to attributes
in their parent (or grandparent) objects to print. In fact they can
reference multiple attributes because you really write a template that can
mix static strings and attribute printouts. (And it has access to both
concrete and abstract attributes, that's how we can easily print the
"output of the netlister" on the sheet.)
So we don't have magic properties like pin name and pin number (altium
for example does, with bits controlling whether exactly one copy of them
is visible or not). And we don't need our mechanisms to deal with such
special cases. Our mechanisms can always just deal with attributes in
general. Then we let the user (and GUI helper functionality) decide what
attribute to print where and when.
>> Probably a system of symbol attributes describing the alternate functions
>> per pin or per function, then another set of attributes to configure which
>> functions you want to use. Then a plugin to calculate what pin does what
>> exactly at the end, considering contradictions/collisions too (like if you
>> wanted SPI, that takes away PB5 and then you can't have uart2 because that
>> had RX on PB5). Then the same plugin offering a GUI dialog and some
>> actions for "more user friendly" manipulation of the function config
>> attribs for those who don't want to edit the attributes directly. Then the
>> same plugin hooking in into the sheet compilation to set attributes in the
>> abstract model with the resulting pin functionality.
>
> Collision detection is good, I have to inspect netlist for that.
>
> One thing I can do which you probably could do with a attrib approach,
> is to make the pinout of symbol for different packages to line up.
> 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 if I construct power subsheets for the mcus, I can start with
>https://aspodata.se/git/openhw/share/gschem/_sub_page/stm32f100lm.power.LQFP48.sch
> then copy it to
>https://aspodata.se/git/openhw/share/gschem/_sub_page/stm32f100lm.power.LQFP100.sch
> swap out the symbol, add caps and be ready.
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.
It's the good old heavy symbol vs. heavy footprint problem. Your symbol
is heavy, encoding footprint properties. As a user I dislike that, I'd
rather have a single VDD terminal on sch that says it's really pcb pin
"24, 36, 48". So the symbol doesn't need to be drawn for a specific
footprint, which means the symbol can be a light symbol.
In Ringdove we don't have that problem at all: we can do this with devmap.
3 minute tutorial video on how this works in practice:
https://archive.org/details/sch-rnd-tut-multipin-portmaps
This one uses a generic (light) mosfet symbol that has 3 terminals, with a
so(8) footprint that has 8 pins. No special footprint, no special symbol,
all stock, light, and a custom portmap in between. Which is really just an
attribute entered in the symbol instance. If I wanted to do this often, I
would set up a devmap file for this, so I don't need to specify (or copy)
the portmap all the time. The devmap is not about pinouts, it's a generic
mechanism that can set any attribute. Including the portmap attribute
(for the pinout) and the footprint attribute, which are the two you most
commonly would set from a devmap for the pcb workflow.
> The downside of split symbols, is if you go from 48 to 64, you have to
> replace all symbols whith that refdes.
Only if you had heavy symbols. If you used devmap, it's enough to
replace the devmap attribute. We have tools to find all symbols (really:
group objects) that have a specific attribute (regex match included) and I
am sure we could find a relatively simple way to automate the edit too.
Btw, this part we discussed here with number of pins and footprints is all
about slotting and devmap, not about alternate pin functionality.
What I meant by alternate pin functionality is more like this:
https://forum.armbian.com/uploads/monthly_2018_07/Orange-Pi-Zero-Pinout-banner2-700x700.jpg.fdf4c8994a5cb0236101407b17fe4891.jpg
look at the the pin on the right, under TX: it's either SIM_DET or
external interrupt (PA_EINT10) or just a plain digital port PA10. You
can just list them all in your symbol. But if you also print them all, and
you then make a specific connection, you usually select one functionality.
Having the other functionalities printedon the final schematics is
confusing.
This also affects a future DRC: if there's no mechanism to select
functionality, this pin is "everything", digital input, digital output,
with or without tristate, pullup, pulldown, etc. So a fancy DRC would just
accept anything you connect to it because there's surely a pin function
that fits that connection. But if you can select one specific
functionality, like EINT10, the DRC can now deal with this pin as
input-only.
Constraints/collisions: now check thenext, orange pin under that SIM.
It's either SPI1_CS or PA13. If you select it to be SPI1_CS, you surely
want to also select SPI1's CLK, MISO and MOSI. So there are some
dependencies.
Again, I don't yet know the details, and at this point I don't want to
think about them, but this is the generic problem I intend to solve for
alternate pin functionality:
- without external scripts
- without having to generate different symbols per function selection
- in a way that it hopefully uses attributes and an optional plugin only
- can have both strong GUI and CLI support
- and can be orthogonal to other mechanisms like devmap, portmap (and
slotting in general).
Best regards,
Igor2
- Raw text -