ringdove knowledge pool
Summary: 2023
| stat_2023 by Tibor 'Igor2' Palinkas on 2023-12-31 | Tags: insight, summary, 2023 |
Abstract: Summary about the year 2023 in the life of the Ringdove EDA project.
Imported from the mailing list archives.
Here's a list of the progress in Ringdove in 2023 (my favorites, subjective selection).
1. Ringdove EDA as a whole
With sch-rnd (and pcb-rnd and camv-rnd) reached stable, we now have a "complete" EDA suite: pcb-rnd no longer implicitly depends on 3rd party sch-editors. I no longer have the problem of "which sch editor to show to new users in tutorials".
It also means more stability for pcb-rnd long term: gEDA is fading out, but as we have the most important tools already (re-)implemented in Ringdove, we are not affected. (I mean gschem is effectively dead and probably very hard to install on new systems; lepton didn't have a commit in almost 3 months; pcb typically has very few commits with many months or sometimes years apart while gtk2 dependency is dragging it out from distros.)
Another important consequence is that we can finally implement suite-level features that were impossible before sch-rnd because gEDA refused to cooperate and other sch editors were not interested enough to implement them. 3
2. sch-rnd - the newcomer
The single most important thing in 2023 is sch-rnd release 1.0.x and the user testing (thanks!) and bugfixes so that sch-rnd is now really stable and production-usable. There are multiple users with production boards done with sch-rnd + pcb-rnd already.
Also important aspect is the tutorial video series we developed with Majenko. I think we now have a real solid offer of making it easy to learn an otherwise non-trivial tool. (If you are planning to use sch-rnd, I strongly recommend starting with the tutorial videos.)
Circuit simulation: ngspice support. A wide range of workflows available starting from the raw "export netlist and do the rest from hand written spice files with text editor" to "fully integrated GUI: single click, plot displayed within sch-rnd". I think this wide range of support, is something few EDA suites managed to achieve. Another such novelty is the "same sch for pcb and spice" approach. This includes: you don't have to decorate the drawing (or draw an extra testbench sheet) with random voltage/current sources and meters for simulation just to say "connect +3.3V to Vcc".
DNP/omit: a tiny thing, but demonstrates well what I mean by suite-level features. Add a dnp=1 attribute to a symbol in sch-rnd; get a clear visual indication of it in sch-rnd; do a forward annotation; get all footprints in pcb-rnd; the subcircuit coming from the dnp symbol now has a dnp=1 attribute automatically; export a bom from pcb-rnd and see the dnp subcircuit is not on the list. (The omit attribute is similar, but it omits the given component from the netlist output so the subcircuit doesn't even show up in pcb-rnd.)
3. pcb-rnd
gsch2pcb-rnd separation: now that we have sch-rnd, I could start getting rid of the remaining implicit/weak gEDA dependency in pcb-rnd. This doesn't mean we would stop supporting workfows from gschem or lepton-eda, it only means they are losing their historical special status and they are becoming only an n+1th alien netlist/sch workflow. This mostly affects the documentation and tutorials, but this also led to the long scheduled gsch2pcb-rnd separation. gsch2pcb was an ugly hack; I recommended using the import sch feature for many years, but still kept a gsch2pcb-rnd within pcb-rnd which by the end was essentially just a wrapper around the CLI import sch feature. In 2023 gsch2pcb-rnd got moved into a separate project and got archived (no future development planned).
Back annotation upgrades: this was one of the areas where we could have a lot more years ago but lack of sch editor support held us back. With sch-rnd available, it was a small task to extend our pcb-rnd -> sch-rnd back annotation; now it handles almost every case I could imagine.
3d models: complete set of openscad models for the standard footprint lib. Developed by Erich. The main importance is that a new user can design their first few learning-curve boards with full 3d export support, which I think helps them realise they could easily do the 3d models for their inevitable custom footprint lib (that happens when they start to use pcb-rnd seriously). Having a full 3d model helps in complete product design workflow (e.g. enclosure).
4. camv-rnd
In our smallest and less developer-intensive Ringdove app, the main new feature is multi-select file load from GUI.
Thanks to librnd 4.x.x upgrades, we also got the same export features, including the familiar export dialog, that pcb-rnd and sch-rnd have.
The tab key now flips the view, just like in pcb-rnd.
5. librnd - the underrated part that does a _lot_
The most important news was the release of librnd 4.0.0 in February. This included the essential upgrades required for sch-rnd to move on.
Part of that is the multi-design support. Originally librnd was forked out from pcb-rnd, which was (and still is) a single-design app: you can edit only one board per pcb-rnd instance. Sch-rnd requires multiple sheets open, and this needs librnd understand how to handle multiple designs (sheets, boards, whatever).
Dynamic drawing area: again for historical (geda/pcb, pcb-rnd) reasons, librnd thought the drawing area always started at 0;0 and extended only in the positive direction and has to limit where you can draw. In sch-rnd I wanted to have "automatically extends in any direction your drawing extends". Since our coord type is signed integer, there's no reason why negative coords shouldn't work. With this upgrade, you can start drawing around 0;0 and extend very far in any direction. I believe our implementation is less hackish than gschem's (where they simply put the original starting point at some high value and 0;0 is hard limit).
New font engine. Historically the font engine was coming from pcb-rnd and in turn from geda/pcb. It had just enough code for what a typical PCB needs (printing refdes on silk mostly). Meanwhile in sch-rnd I figured ttf causes more problems than it solves so I decided to switch back to this simple pcb-rnd vector font. However, in sch-rnd we need a lot more so the font engine needed a large upgrade in librnd. The new font engine includes multiline text support, proper tab support, kerning tables, &entity; support (so we will be able to print ohm and micro), alignments, baseline. And it is backward compatible with the old engine so pcb-rnd will be able to use it too.
6. Closing remarks
2023 was a real important year in the life of Ringdove. I think it was comparable to 2016/2017 for pcb-rnd 1 , with sch-rnd completing our initial EDA suite.
There is still a long way to go with sch-rnd, next step being support for hierarchic design in 2024, but I think we are on the good path, with an almost good timing 2 .
I'd like to thank NLnet for the financial backing, various contributors on code, data, doc/tutorials and of course our great users who constantly test Ringdove and provide feedback and bugreports. Big thanks to those early users of sch-rnd who were struggling with annoying bugs during beta testing.
Footnotes:
1 : that period was a very important turning point for pcb-rnd. That was when I finally decided pcb-rnd's future is definitely not in gEDA, stopped worrying whether gEDA/pcb could benefit from my patches or could ever catch up, so I could start working on major code cleanups and the new data model.
2 : In retrospect I think I should have started the intensive alpha version development of sch-rnd 2..3 years earlier instead of 2022. But well, allocating limited resources, keeping both pcb-rnd fresh and work on new tools is not that easy.
3 : This is certainly one of my mistakes/failures: between 2015 and 2021, following the gEDA spirit, I thought the way forward was to team up with other developers who work on sch editors. I was wrong. After gschem/lepton developers refused my offer on a coordinated cooperation, I seeked a bunch of other independent sch editor projects. We had partial success with xschem (but no break-through) and zero success with anyone else. I think I should have realised much earlier that the only way forward is to write our own. It's also an interesting (sociological) question why developers are so uninterested in strategic cooperations. I think this was different back in the ealry 2000s. The most trivial example is gschem and pcb: projects with very different roots and approaches being able to cooperate in a coordinated way to produce an usable EDA suite _together_. I think it's also interesting to see the slow decline of gEDA started about the time when this strategic cooperation gradually got replaced by the "I am only working on my part" mentality in the 2010s. I think nowdays developers generally underestimate the value of planning and coordination, overrate the "I do my project and publish it, the rest will just happen" myth and somehow expect features arcing over different tools to just pop out of thin air.