pcb-rnd knowledge pool

 

Why should you use pcb-rnd vs. gEDA/PCB?

vs_geda by Tibor 'Igor2' Palinkas on 2018-01-01

Tags: insight, geda/pcb, comparison, table, feature, features, datasheet

node source

 

 

Abstract: Datasheet-like comparison table of the most important features of pcb-rnd and gEDA/PCB, to help users choosing between the two packages.

 

This page is intended to help users to chose between pcb-rnd and gEDA/PCB by providing an objective comparison on various properties (as of 2019).

Major features
property pcb-rnd gEDA/PCB
data model: explicit/editable mask and paste layers yes no
data model: footprint with no restriction yes (subcircuits) - footprint can host anything a board can no - only pins, limited SMD pads, limited pins, silk lines and silk arcs
data model: layer concept clearly defined physical and logical layers; compositing layers (additive, subtractive) on silk, mask and paste mixed physical/logical layer concept; no compositing layers
data model: user defined layer yes - arbitrary documentation/misc layers no - have to abuse copper layers
data model: padstacks, slots yes - plated and unplated slots, distinguishable from board outline no - special/restricted pin, pad and via objects, no real slotting
ability to load/save other EDA file formats rich (kicad, eagle, protel/autotrax, PADS, geda/pcb, etc.) none
embedded scripting pcb-rnd actions and 10 different turing complete languages (including: awk, lua, python, perl) pcb actions (not turing complete)
Flexible Design Rule Checker (DRC) yes - modular, user scriptable, DRC scripts are easy to share; DRC rules from netlist import no - hardwired C code
support: bugfix turnaround bugreport reaction times typically measured in hours or days bugfixes tend to take months or years before hitting a release
development pace 2..4 months between releases; releases include major feature improvements about a year between releases; releases mostly include minor features
distro packaging support official debian, mageia, fedora; unofficial/user: arch, various BSDs any major distro
import netlist formats tEDAx (works with sch-rnd , xschem, gschem, lepton) and more than a 10+ other formats (e.g. orcad, protel, pads, accel, tinycad, ...) its own netlist file format (works with gschem and lepton), tinycad
footprint formats various common footprint formats (including BXL, eagle and geda/pcb), transparent format detection and load supports only its own native .fp format
footprint access modularized footprint access: plugin for file system access, plugin for cloud access through HTTP loads only static file footprints from the file system
footprint generation support for extensible, dynamically generated parametric footprints , with GUI parameter dialogs (with the GTK HID); footprint generators implemented in any programming language m4 footprint generation; no GUI support
GUI support gtk4+gl, gtk2+gl, gtk2+gdk, lesstif - runtime selectable, dynamic loadable plugins gtk2+gl, gtk2+gdk, lesstif - compile time selectable, static linked
portability Linux, BSD, any UNIX system with motif (C89, no GNU dependency), windows Linux, BSD, modern UNIX systems (C99+, requires glib and may depend on GNU), windows
license GPL2+ GPL2+

Minor features
property pcb-rnd gEDA/PCB
translations English only multiple languages
documentation user manual: html (pdf);
auxiliary/contributed: knowledge pool
user manual: texi (html, pdf); doxygen;
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 flat key=value settings model
modularization majority of the code in plugins; plugins can be configured to be static linked, dynamic linked or not compiled at all; automatic dependency handling between plugins majority of the code in core; majority of the features are static linked compile time on/off; some can be compiled for dynamic load
autorouter 90 degree box based (internal); topological with route-rnd (extrnal); plugin for freerouting (extrnal); flexible support for external autorouters (dsn, tEDAx) 90 degree box based (internal); topological (internal)