Ringdove

What's Ringdove EDA?

Ringdove EDA is a free/open source EDA suite. Target audience is hackers, UNIX users, command line wizards. Ringdove is a toolkit of independent projects. There are multiple workflows possible within Ringdove and any part of any workflow can be easily replaced with external software.

How does it differ from gEDA?

Ringdove tries to take and advance the good ideas from gEDA while learning from but leaving out the bad ideas. A few examples:

Fine, but how that could be better for me in practice?

Why a new, separate EDA suite?

I had a vision of how a proper UNIX/toolkit/free EDA suite should work. It included cooperation between developers of different tools. It included thinking about features from a workflow/suite point of view. It included fixing a few design decisions in some of the existing tools.

Originally, when I already had pcb-rnd, I tried to convince other developers in gEDA about this vision. They didn't share any of it and refused to cooperate.

Having to split my attention to so many different tools instead of being able to concentrate on one (for example pcb-rnd) is clearly suboptimal. Having others working on sch editors, gerber viewers, autorouters, etc., would have been much easier. So I really tried hard, probably for too long, but failed to bend gEDA to at least converge with my vision. So my only option was to implement my vision in a new EDA suite.

But then Ringdove competes with gEDA!

Yes. The same way as it competes with KiCAD or Eagle. The same way lepton competes gschem. Or gschem competes lepton. (It all depends on which one is your default, the other one would be the competitor to it.)

Healthy competition is not bad.

sch-rnd

What's sch-rnd?

It is a schematics capture software written from scratch (it is not a fork of anything existing). It is part of the Ringdove EDA suite. It implements the cschem data model. It uses librnd so it looks and works similar to pcb-rnd and camv-rnd.

It supports multisheet design, optional project files, portmaps/devmaps, back annotation from pcb-rnd. Later on will support hierarchic design and real buses.

How does it differ from gschem/lepton?

Here is a long, technical list of the major differences.

Most importantly, it is not a gschem rewrite but a brand new schematics capture tool, designed from ground up for Ringdove, so it differs on many levels:

So knowing gschem doesn't immediately mean one can ue sch-rnd fluently. sch-rnd's learning curve is about only as steep as gschem's was. However, sch-rnd has excellent tutorial videos, following these videos learning the whole thing should take only about 2..3 hours.

Fine, but how that could be better for me in practice?

Why didn't you just fork gschem/lepton?

There is some fundamental design decisions in gschem that would have been very expensive to change. For example that gschem doesn't know about nets or that some of the flexibility is implemented only in gnetlist but the conclusions/output of gnetlist can not be fed back to gschem.

For me, as an user, gschem and lepton were a huge pain to compile and keep up to date. Mostly due to the guile (and in case of gschem python) dependency. It make life much easier to loose those unnecessary dependencies.

Unfortunately a big part of gschem is written in scheme and/or python. Lepton went even further and actively converted more C code into scheme. The problem is that I don't speak either scheme nor python, which means I couldn't have maintained those parts of the code.

A very important goal was to make sure applications of the EDA suite look and work similar. This includes having the same config file conventions, similar menus, similar hotkeys, similar UI logic. Huge parts of gschem/lepton would have to be rewritten to meet this requirement.

These three combined leads to: a fork would have been much more expensive than a clean rewrite.

pcb-rnd

What's pcb-rnd?

It is a printed circuit board editor software originally forked from gEDA/pcb, with vast majority of the code base changed or rewritten since the fork. It is part of the Ringdove EDA suite. It uses librnd so it looks and works similar to sch-rnd and camv-rnd.

It supports any object on any layer in footprints. It supports editing every layer (fab layer included). It has padstacks with real slots. It has a scriptable DRC. It can load KiCAD, eagle, altium, protel boards and footprints and BXL footprints.

(Plus a lot more formats and features I am not going to list here).

How does it differ from gEDA/PCB?

I used to have a list of improvements. It grew too large so I tried to maintain a list of major improvements only. Grew too large too.

Here is a very small subset, a datasheet-like, technical list of the major differences.

In short: gEDA/PCB is mostly the feature set of PCB editors from the '90s; pcb-rnd with all the extra features and the new data model is more like how PCB editors work in the 21st century.

Fine, but how that could be better for me in practice?

If you ever bumped into any limitation in gEDA/PCB, something you had to work around with multiple smd pad objects, hand-editing the file, objects that should have been part of an Element really drawn directly on the board next to the Element... Or had to manually search and tweak things because there was no way to get PCB find the given objects and select them and no action to change the specific property on all selected objects...

... there's a very high chance pcb-rnd has already fixed that.

Plus pcb-rnd already offers a gtk4 HID (while also maintains the gtk2 HID).

camv-rnd

What's camv-rnd?

It is a PCB related CAM (Computer Aided Manufacturing) file viewer. It can display multiple gerber, excellon and g-code files.

How does it differ from gerbv?

It uses librnd so it supports all GUI HIDs pcb-rnd and sch-rnd does, including both gtk2 and gtk4, while gerbv depends on one specific version of gtk.

Gerbv's internal structure mixes gerber parsing/executing with GUI rendering. This has far reaching consequences on fixing gerber rendering bugs, introducing new GUI frontends or new file formats. In contrast, camv-rnd loads any file format into a very simple, flat, static data model and the renderer works from that data model. Having the flat model in between makes it very easy to implement loaders for new file formats. It also guarantees that a new GUI HID in the future will automatically work with any file format.

Fine, but how that could be better for me in practice?

While developing camv-rnd, I wrote the gerber parser from scratch. I actively looked for corner cases and tested them with ucamco's reference gerber viewer (ucamco is the maintainer of the gerber format) and made sure camv-rnd renders the same. While doing that I also tested the same files with gerbv and the version of gerbv at date failed to render some of the test cases properly.

Is there more?

Yes.

There's librnd that is the common, generic part of the GUI apps. It doesn't know anything about the apps, their data models, their data file formats, their menus, but contains all the shared code for GUI HIDs, dialog box API, menu systems, the configuration system, the plugin system, user scripting. This means:

Furthermore there's an external PCB autorouter called route-rnd and an user contributed symbol/footprint/devmap/script collection called edakrill (which is somewhat similar to gedasymbols.org).

It's likely that there would be further smaller projects added to the suite later.