Mail Archives: geda-user/2023/05/10/08:54:35
Hello Karl,
On Wed, 10 May 2023, karl AT aspodata DOT se [via geda-user AT delorie DOT com] wrote:
>Igor2:
>...
>> If you are a gschem/lepton user, what could make sch-rnd interesting:
>>
>> - sch-rnd doesn't depend on guile, python, autotools, glib; smaller
>> footprint, easier to compile, less likely to break with major version
>> bumps of any of the above deps (e.g. when you upgrade your system)
>
> That is very commendable, appreciated.
Thank you!
>> - sch-rnd + pcb-rnd + camv-rnd achieves something gschem/lepton + pcb +
>> gerbv never managed: although each component is a separate project, the
>> UIs look and work similar. Same UI logic, same mouse bindings, largely the
>> same (multi-stroke) keyboard bindings, very similar menus, same config
>> file format/conventions.
>
> As a detail, I have problem doing fast zooming in and out with pcb-rnd
> since it uses a two keystroke combination, which doesn't work when I do
> a lot of zooming. My guess that you can zoom with the mouses scroll
> wheel, but for thoose with (old) three button mice, zooming is
> troublesome.
> I know that you can configure the keystroke combinations, but you are
> advertising support for old hw, will there be available alternate configs
> for thoose systems ?
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.
>> - sch-rnd has support for gtk2 and gtk4 (and for no-gui batch/cli, and to
>> some degree for lesstif)
>
> Have there been any progress with the lesstif (or rather motif) hid ?
> The last problem was that devuan/debian libXt didn't work out of the
> box.
Yes.
It turned out developing custom widgets for motif is just unreasonably
expensive, so on the long term we need an alternative for old UNIX and
X11.
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.
Next will be writing a set of librnd HIDs that use miniboxtk on the
different avialable backends. Once I have the miniboxtk+xlib backend
working, I will remove the lesstif (motif) HID in favor of it. The net
result, at the end, would be:
- even less dependencies (miniboxtk is much smaller than motif and will
probably compile and run on any UNIX system motif ran on, plus some more)
- smaller code complexity and code size (miniboxtk has simpler APIs and
internal implementation than motif); especially much cheaper to implement
custom widgets
- access to way more platforms: besides the xlib backend, miniboxtk also
offers an sdl2 and a glfw backend; glfw will provide hw accelerated
rendering on any major modern platform at any given time; sdl2 will
provide sw or hw rendering on any platform you can reasonably assume
librnd has a chance to work on; so unlike motif, the same toolkit could
really work from anything from the early 90s UNIX systems to latest
exotic platforms
- long term this will also saves me a lot headache when gtk4 gets dumped;
if we have a miniboxtk HID, I won't necessarily need to develop a
gtk5/gtk6/gtkN HID in the far future just because distros remove gtk4
Unfortunately I have only 24h a day too, and my time is pretty much booked
for sch-rnd and a bit of pcb-rnd for this year, so the librnd miniboxtk
HID will probably have to wait until next year or so. So if you can't use
gtk2 or gtk4 today, sch-rnd is not yet for you: because of a bug in the
lesstif HID, sch-rnd doesn't start up properly on motif in my experience.
In theory it could work, in practice it doesn't, and noone will go and fix
the hid_lesstif bugs.
>...
>> 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.
Now that we have sch-rnd, I can simply implement whatever is needed, so
after sch-rnd already has hierarchic design support (this year), and I am
done with other, more important tasks, I will return to this subc-in-subc
in pcb-rnd (maybe next year, maybe later). It will be like its name
suggests: you can load a whole small board as a subcircuit, with copper,
silk, mask, paste, etc _and_ its own subcircuits for footprints. Then I
could probably get sch-rnd to export a netlist in a form that plays well
with this.
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.
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.
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.
Problem c. is automatically solved, because pcb-rnd already handles
subcircuits properly vs. board sides, and subcircuits already can have
copper tracks and vias and whatnot. It's even a bit more generic: the
layer stack of the subcircuit does not have to match the layer stack of
the target board, and you have full control over the layer binding (that
is, which layer of the subcircuit goes on which layer of the board). So if
you draw your ldo+caps on 2 layers, and you have a 4 layer board, that
works, you just need to tell pcb-rnd which layer to use for the "signals"
and which layer for the "ground" (these are not hardwired layers in
pcb-rnd, I am just assuming you'd have two random layers and just named
them so it's easier to imagine the example).
>
>...
>> - simulation backends (ngspice and maybe gnucap); with an option to
>> back-annotate data from the simulation to the sheet
>
> 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.
I am already in touch with Felix, who is also working on a different part
of gnucap.
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.
I may use verilog-ams to drive gnucap in the upcoming sch-rnd circuit
simulation interfacing subproject, but I don't think I will ever try to
"load a schematics" from it. It's a bit like trying to load a PCB from
png. Technically you can, but it'd be very painful, you'd lose alot of
metadata and there's no good reason to do it. And you especially wouldn't
say you'd use gimp as a converter between kicad and pcb-rnd through png.
If user demand ever arises for loading qucs schematics, I'd just implement
a plugin, io_qucs, that directly loads it from their native file format.
It's not a big deal, I mean I've already have io_altium, which loads a
proprietary, undocumented, binary file format to a level that you can see
the schematics and all symbols and attributes and only a number of small
details are off. So there's no reason to use an intermediate converter or
intermediate file format for this.
(The sim -> sch-rnd back annotation thing wouldn't try to get back
schematics data or netlist from the sim, rather simulation results. You
are not going to rewire or redraw your schematics in gnucap... What you
are going to use it for is getting some numbers or graphs back. Maybe tune
some resistor/capacitor/inductor values and get back the final
results/measurements to your sch-rnd sheet.)
>> - 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.
> 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.
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.
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.
Best regards,
Igor2
- Raw text -