Main	Download	News	Tutorial	Doc & FAQ & pool	Consulting	Ringdove

Ringdove Fund a Feature

The following largish features are considered for some time and are blocked because of lack of developer time and funding. If you need any of these features and you can afford spending some money, contact me. Alternatively if 2..5 users could team up to fund a feature so the cost is dispersed.

All features implemented are released as free software.

Suite level features

• FR1. Cross-selection between pcb-rnd and sch-rnd (and maybe camv-rnd too); e.g. select a trace in pcb-rnd, use some hotkey and an already running version of sch-rnd that has the same project loaded would also navigate to the net the trace is for (done)
• FR2. Real-time rename & annotation [small]
  There is a weakness in our fwd and back annotation: if you rename a component, that really looks like removing the old and adding a new because component name is what identifies the object.

  With prj-rnd you could open the project in sch-rnd and pcb-rnd in parallel and do the rename in a way that it is "cross-probed" and to a certain extent the edit is automatically done on both sides.

  (This does not include auto-renumber, just manual renames, plus I can't guarantee this would work in corner cases (like deep in a hierarchic design)).

• FR3. Experimental binpack (.app package really) for OSX [mid]
  This needs someone who can test it then someone who can sign it (== someone who registers as an apple developer and trusts me enough to sign the package I built).

  Thanks to SnakesAndStuff I do have access to an OSX server where I can do the compiling and packaging experiments, but I can't really try installation on the same machine.

  (Unlike the others, this task has some risk involved, it might be that I invest many hours in it just to find the result is unusable.)

• FR4. architecutre/design: figure if we could do more flexible netlists in fwd annotation [mid]
  This is a research project, potentially involving communication with the users. No code implemented, just possibilities considered, scenarios simulated to figure if the feature is viable in the first place.

  The idea popped up on geda-user@ more than a decade ago. It's an alternative to back annotation. In a nuthsell: sch-rnd wouldn't send off a hardwired render of the netlist to pcb-rnd, but it would list options. Like if you have quad opamps, the sch drawing would obviously have discrete opamp symbols scattered on the sheet, but they wouldn't be attributed as "name=U1, slot=2" but more like "name is one of U1, U2, U3; slot is one of 1, 2, 3, 4". This info would then be understood by pcb-rnd and _somehow_ the netlist engine would offer ways to swap options (some new GUI in pcb-rnd probably). At the end the back annotation from pcb-rnd to sch-rnd would be only which specific option you picked.

  Besides the above classic slotting problem, this could also handle the common case with MCU GPIOs and FPGA pins and custom connector PINS where you are free to pick what you connect where between a group of pins and a group of nets.

sch-rnd

• FS1. Implement hubs and real buses, as documented in the design doc.[big]
  Full, semantic, hierarchical bus support, more or less as specified in the design doc.
• FS2. Design Rule Checker [mid]
  Would introduce attributes for port types, could check if there are multiple outputs connected to the same net. Could do some symbol related checks (e.g. slot placement). But these would all be scriptable, not hardwired.
• FS3. upgrade sch-rnd's renumber plugin to use FR2. from above [small]
  Obivously depends on FR2. and can not be done without that.
• FS4. Tutorial videos [scalable: small..big]
  There are lists of tutorials planned for both pcb-rnd and sch-rnd. I obviously don't need them as I can already use these features, so I won't just sit down and do them "for fun". However, it's relatively cheap and very well predictable to do these kind of tutorial videos with my current workflow, and the ideas are split up to small portions.
• FS5. Upgrade library management [big]
  Both sch-rnd and pcb-rnd embed data in the design file, there's no external reference to the library. This makes the design files self-contained, stable and easy to distribute. In return if you fixed something in your lib, there are only accelerated but manual ways to update symbols/footprints in existing designs from lib.

  It's not becaue some fundamental design is missing (see pool node).

  It's because the actual UI (GUI, maybe CLI) is missing. I imagine something like an action that builds a table on what syms/fps you have embedded in the currently open design, what ID/version info it has and what's available from the lib, highlighting options for upgrade. Then one-by-one click for upgrading specific resources or a nice big "upgrade all" button.

pcb-rnd

• FP1. subc-in-subc support (low level) [big]
• FP2. hierarchic board from hierarchic schematics (depends on FP1) [big]
• FP3. be able to load and edit multiple board files [big]
  similar to how sch-rnd can handle multiple sheets
• FP4. arc in polygon (depends on FL1) [big]
• FP5. Tutorial videos [scalable: small..big]; see FS4 above.
• FP6. Upgrade library management [scalable: big]; see FS5 above.
• FP7. A more modern alternative to the "vendor drill" plugin [mid]
  Imagine you have a PCB designed. You have the DRC set up for your previous fab. It all passed. But now you have a new fab, that allows either more or less tight rules. You change the DRC config, you re-run DRC and you manually tweak where needed.

  Now imagine we have a plugin that uses query() and propset to translate a few very common "rules" fabs typically have on their "capabilities" table. Things like "on an inner layer minumum copper-copper clearance is 0.15mm". You pick the "rules" that have matching fab house published values and the plugin goes and modifies the board for you. This doesn't mean any re-routing, only modifications of trace widths, clearances, etc.

  And it's not very smart, it wouldn't handle all situations: you'd still run a DRC afterward and you would still need to do fixes here and there. But at least the bulk of the job is done quicker than if you had to do a lot of advanced searches and propsets manually.

camv-rnd

• FC1. Arc in polygon [big] (depends on FL1)

librnd

• FL1. Arc in polygon contour [big] (polybool2)
• FL2. Replace libgd with code implemented in librnd [mid]
  This would fix corner case bugs and would further reduce external dependencies.