Mail Archives: geda-user/2023/05/10/11:03:01
Igor2:
> On Wed, 10 May 2023, karl AT aspodata DOT se [via geda-user AT delorie DOT com] wrote:
> >Igor2:
...
> We have the alternative key bindings of + and -, they are especially
> comfortable on the numpad (if you have one). This works too, out of the
> box, without any extra configuration.
Thanks, good to know.
...
> 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...
...
> >> Things that sch-rnd doesn't support yet but will in the foreseeable future
> >> (in ~12..18 months):
> >>
> >> - hierarchic multisheet
> >
> > Testing with hierarchic design in pcb with help of
> > https://aspodata.se/git/openhw/bin/get_sub_pcbs.pl
> > I found out that it works perfectly well doing that with pcb and some
> > manual interventions. So I can have a leaf sch file, e.g. a ldo+caps,
> > design that in pcb. In a higher up sch file I call for that ldo
> > subsheet, and in the corresponding higher up pcb file, I can, with
> > the help of the script above (which collects all need subpcbs, adj. them
> > for refdes) so that I can load them in the higher up pcb file.
> >
> > The problem areas I identified is:
> > a, in pcb thoose sub pcbs isn't treated as a group, like if I want to
> > move it after placement unless I do some selections which is prone
> > to errors.
> > b, the refdeses tend to be annoyingly long, and you cannot know how long
> > when designing the subpcb.
> > c, pcb cannot move a sub pcb to the other side of the board complete
> > with footprints and tracks and all.
> >
> > In your design notes there are a passus about shortening the refdes,
> > also a, should be possible in pcb-rnd.
> >
> > Any thoughts ?
>
> Cool!
>
> I have plans on this, yes (but not for 2023, rather the coming years)
>
> 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.
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.
If you need, I can finish that prototype, I might do so regardless
...
> So at the end you would get your ldo+caps as a subc in pcb-rnd, like if
> it was a footprint, but it's really just a separate board file imported.
Exactly.
> 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 ?
> For b. I don't yet have any specific idea, and I don't yet want to think
> about it, because I won't get to this subc-in-subc problem this year
> anyway.
One idea is to have the subpcb framed whith the subpcb's refdes in top
left corner, and keep the within subpcb refdeses as is.
I think kicad does it by adding 100, 200, etc. to the refdeses, though
kicad doesn't really do hierarchies.
...
> > Regarding gnucap, Al Davis wants to be able to recreate the sch file
> > from the vams file. Ideally he wants to be able to go from
> > qucs - gnucap - lepton/gschem, back and forth. Perhaps if you have a
> > good idea how to connect and communicate between program, that could
> > be an alternative to store file format specific things (e.g. a dump
> > of the sch file) in the vams file.
...
> Honestly, I never believed that converting whole schematics into some
> verilog ams would solve anything, and I especially don't think it would be
> a good format for storing schematics. For me it's just a sim-oriented
> transport format, one that could be used in the netlist role.
Ack.
From my understanding he wanted to be able access to some
simulations there which gnucap doesn't provide, and to be able to
communicate changes made in qucs back to the schematic side, which
at a least a superficial way sounds like your backannotation.
...
> >> - an optional mechanism for managing alternate pin functions of CPUs/MCUs
> >
> > I have a symbol generator
> > https://aspodata.se/git/openhw/pdftosym/pintosym.pl
> > which, with a control file, can pick out different subparts of a mcu.
> > e.g. in https://aspodata.se/git/openhw/share/gschem/_mcu/
> > stm32f100lm.inc contains pin defs. for that mcu complete with alt.
> > functions. So with stm32_analog.inc and the pin def file above, I
> > can get symbols for just the analogue parts of the mcu, whith the
> > analogue alt.func. as pinlabels, e.g. stm32f100lm.analogs.LQFP48.sym.
>
> Unfortunately I get 403 for any of the .inc filesm, and I can't read perl.
> But I can imagine what your script may do.
Sorry about that, fixed now (the 403 part). I haven't fixed the perl
part though...
> > Does your mechanism do something more than that ?
>
> If my assumtpions on what your script does are correct, I'd say slotting
> is a good example to show the difference in approach.
>
> Imagine your sch editor doesn't have slotting. You could write a symbol
> generator that reads a slotted definition of the symbol and spits out a
> separate symbol for each slot. Like 7400-slot-1.sym, 7400-slot-2.sym,
> etc. Then in your sch editor you could just load all those different per
> slot symbols. As long as your sch editor supports merging symbols (e.g.
> because their refdes is the same), if you look at the output netlist, this
> method works just as good as any slotting you would have on the GUI.
>
> 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 ?
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.
> 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.
> 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.
The downside of split symbols, is if you go from 48 to 64, you have to
replace all symbols whith that refdes.
Regards,
/Karl Hammar
- Raw text -