sch-rnd-aux knowledge pool
Why should you use sch-rnd vs. gEDA/gschem or Lepton EDA?
| vs_geda by Tibor 'Igor2' Palinkas on 2022-06-15 | Tags: insight, geda/gschem, gschem, lepton, lepton-eda, comparison, table, feature, features, datasheet |
Abstract: Datasheet-like comparison table of the most important features of sch-rnd and gEDA/gschem/lepton, to help users choosing between the packages.
This page is intended to help users to chose between sch-rnd and gEDA by providing an objective comparison on various properties (as of 2023).
Major features
| property | sch-rnd | gEDA/gschem | lepton-eda |
|---|---|---|---|
| explicit abstract model | yes | no | no |
| views (different plugin filters for output, results visible on screen; e.g. slotting, devmap, portmap) | yes | no | no |
| portmap (attribute based solution to the transistor problem) | yes | no | no |
| devmap (library based solution to the transistor problem) | yes | no | no |
| arbitrary object groups | yes | no | no |
| recursive object groups (group-in-group) | yes | no | no |
| query language for listing/accessing objects | yes | no | no |
| back annotation from pcb-rnd |
yes, full
:
understands items, tracks what's done, helps navigation, auto-fix |
partial:
presents items | no |
| embedded scripting | 12+ different turing complete languages (including: awk, lua, python, perl, multiple lisp variants) | scheme (guile) and python only | scheme only (guile) |
| development | active | inactive | active |
| distro packaging support | official debian, mageia, unofficial/user: arch | gschem: phasing out | lepton: in major distros |
| loads symbol formats | native lihata, gschem sym (more to come) | only native gschem | only native gschem sym |
| loads sheet formats | native lihata, gschem's, tinycad's (more to come) | only native gschem sch | only native gschem sch |
| parametric symbols | yes | no | no |
| GUI support | gtk4, gtk2+gl, gtk2+gdk, lesstif - runtime selectable, dynamic loadable plugins | gtk2 | gtk2 or gtk3, compile time selection |
| portability | Linux, BSD, any UNIX system with motif (C89, no GNU dependency) | Linux, BSD, modern UNIX systems (C99+ and C++, requires glib, guile and may depend on GNU), windows | Linux, BSD, modern UNIX systems (C99+, requires glib, guile and may depend on GNU), windows |
| license | GPL2+ | GPL2+ | GPL2+ |
Minor features
| property | sch-rnd | gEDA/gschem | lepton-eda |
|---|---|---|---|
| translations | English only | multiple languages | |
| documentation |
user manual: html (pdf);
auxiliary/contributed: knowledge pool |
user manual: texi (html, pdf);
auxiliary/contributed: wiki | |
| configuration system | scconfig (./configure && make && make install is always enough; dependency: C89) | autotools (./configure && make && make install; may require autogen.sh, libtool; dependency: auto*, m4) | |
| native file format | lihata (tree structured text, named fields) | custom text format, positional parameters, missing tree representation | |
| runtime configuration | unified tree structure, key/value/type; mechanism for dealing with system, user, project, file and session level configs, including list merges | scheme based (executable!) | scheme based (executable!) and ini-like |
Explanation and comments
explicit abstract model
The abstract model is what the schematics capture software (or netlister) thinks the sheets of a project mean . For example there are different ways of connecting a pin to a network (graphical, by drawing wires; or using data: attributes). And there are different ways the pin number emerges (e.g. hardwired vs. slots). These are just little differences in the representation of the same final intention, which is a connection between the given pin to the given network.
In sch-rnd these conclusions (final pin numbers, network names, connections, etc). are called the abstract model, while user input (the sheets) are called concrete model. There is a common, file format independent infrastructure that calculates (compiles) the abstract model from the concrete model. This has several advantages:
- the abstract model is available for browsing in the GUI, so the user does not need to reverse engineer it from an often narrowed down netlist output format
- the GUI also has references to the sources, so if the user finds a mistake in the abstract model, the GUI helps tracing it back to the concrete model, no matter if the given mistake was done graphically (e.g. wrong wire drawn) or in data (a bogus attribute hiding in a symbol)
- most of the compilation is implemented in optional plugins, so if is easily possible to replace things like the slotting mechanism or how "pins" are ordered or labeled...
- ... and this is not coupled with any output format
- the result of the compilation is displayed on the sheet; so the final "pin number", that may be affected by devmap and/or slotting can be displayed on screen and in graphical export (ps, png, etc.) but not because it is hardwired in the GUI but because the abstract model is generated before the netlist backends and the abstract model is understood by the GUI
In gEDA the abstract model and compilation are hidden. Some parts of them are implemented in a way that the GUI is aware of it (e.g. slotting). These are usually hard to change or override. Other parts are delegated to netlist backends, which is more flexible but also forces backends to implement their own idea and otherwise generic concepts become backend-specific. The result of whatever the netlist backend does is never fed back to the GUI, so the only way to know the final network names or connections is to look at a netlist. If anything went wrong, tracing back why the central code or the format specific backend code made the decision, what sources has been used in that specific piece of output is hard.
Views
The flexible part of compilation is a configurable ordered list of plugins that should be executed during compilation. If there are different alternatives to slotting or pinouts, this configured list tells sch-rnd which one to use.
Such a configuration is called a 'view'. There can be multiple views configured and it is easy to switch between them on the GUI and in exports. For example a PCB view would do slotting and display physical package pin numbers on the sheet. A spice view would not do slotting but change "refdes" of symbols to make slots unique, and would display (the equivalent of) "pinseq". Selecting the right view will keep the relevant info shown, the info as used in the current workflow.
In gEDA there is no explicit abstract model so:
- the GUI shows input only...
- ... except for a few hardwired features like slotting
- some of the mechanisms are hardwired in the netlister backends so how exactly a transformation is done is coupled with the output file format
Portmap
The transistor problem is that with gEDA you can't have both:
- a light (generic) transistor symbol in sch
- a light (generic) 3 pin footprint in PCB
It is because the fundamentally same npn transistor comes with different pinout (e.g. "base is pin 1" vs. "base is pin 3") per package per vendor. So you have to hardwire the pinout either in your symbol or in your footprint, which means you will need to have a set of per-pinout (or per-model) symbols or per-pinout footprints.
Or you have to, as many users do, have a 3rd tool somewhere between sch and PCB that loads the pinout from a 3rd party "database" and edits the sch or the netlist or the pcb to apply the pinout. However, in this case, you usually won't be able to see the final pin numbers on the sheet, which doesn't help debugging the board.
sch-rnd solves this problem by a flexible compilation setup where plugins can make transformations. An optional plugin, provided with sch-rnd, runs the standard portmap feature, which allows specifying the pinout in a symbol attribute. This way:
- you can use both light symbol and light footprint and inject the glue (pinout info) as an attribute
- because of the explicit abstract model , the actual pin numbers are displayed on screen and in graphical export
- if you don't like how portmap works, you can write a plugin (or an user script) and replace it with a different mechanism without losing graphical/export/netlist display...
- ... and this is not coupled with output format in any way
Devmap
A standard (but optional and replaceable) plugin provides the devmap feature in sch-rnd. Devmap depends on a devmap library, which is similar to a symbol or footprint library, but instead of graphical data, it stores information about "how to edit attributes of a generic light symbol to make it model-specific". It can set any attribute, typically footprint and portmap. Together with the standard portmap mechanism, this allows the user to:
- use both light symbols and light footprints
- build a library of devmaps to customize generic symbols into specific products
- connect the two in a way that the GUI understands, works with all export (and is still not hardwired in sch-rnd)
gEDA doesn't have an equivalent method.
Scripting
Gschem and lepton depend on guile. Gschem also depends on python. You can't run gEDA without these dependencies even if you don't plan to write scripts and don't plan to use 3rd party scripts. However, if you do want to script the tools (to add new functionality) you have to use scheme (and/or python in case of gschem). If you prefer tcl or lua or awk, you are out of luck.
sch-rnd is written in C and does not run or depend on scripting for standard functionality. However, if you do want to extend sch-rnd with user script, you can choose from more than a dozen different scripting languages! But they are all only optional dependencies.
sch-rnd exposes a lot to scripting, for example user scripts can:
- create menus and hotkeys
- create and operate dialog boxes
- read sheet data (drawing objects and attributes)
- modify sheet data (drawing objects and attributes)
- contribute in the compilation process (this one is under development)
- extend the attribute editor with attribute-specific helper dialogs
Parametric symbols
Besides static file symbols, sch-rnd can generate symbols by executing external processes. This way we do not have to generate 100 different connector symbols that differ only in the number of pins (just to find the user needs a 101th), but we can provide a connector() symbol where the number of pins is just a parameter that can be any integer.
Since the symbol is generated by an external process, it can be written in any programming language, compiled or interpreted, sch-rnd doesn't care.
Parametric symbols fully integrate in the symbol library, including the GUI library window, including having a preview.
(A similar feature, parametric footprints, is available in pcb-rnd.)