| ID: | 560 |
| From: | ge...@igor2.repo.hu |
| Date: | Fri, 17 Mar 2017 05:27:36 +0100 (CET) |
| Subject: | Re: [pcb-rnd] [dev] API fixup - trends |
| in-reply-to: | 559 from miloh <fr...@gmail.com> |
On Thu, 16 Mar 2017, miloh wrote: > On Thu, Mar 16, 2017 at 3:07 AM, <gedau@igor2.repo.hu> wrote: <snip> > The Rhinoceros drafting CAD (not free libre software, only used a > windows version) only opens one design at a time. > > I'm not sure of the official Rhinoceros workflow for importing designs > from one draft canvas into another (it's likely to use the 'import' > command), but a common method I see is for users to open _two_ copies > of 'Rhino' and use cut and paste actions between the two. > > Yes, afaict, Rhino cannot open more than one design file at a time. > I've wondered if this is an intentional UI choice or a development > issue.. The tabs vs. single-board question... I think it's a design decision in many software, including in pcb/pcb-rnd: we are so lightweight, start up so fast, that if an user is working on multiple boards it's not that bad to just start two instances. It woudln't be very hard to get core handle multiple boards long term - it's just mechanical work, removing the global variables. This will probably happen to some degree, not because multiple tabs The hard part would be the GUI code (both hid_gtk* and hid_lesstif), that have too many desing decisions assuming there's only one board. It'd need a major rewrite to have tabs there, I don't think that'd happen any time soon. > > Also, it looks like subcircuits are more of a future possibility after > this redevelopment? That's unrelated: a subcircuit is part of our one board. It's more about the data model cleanup. A board has a so called pcb_data_t struct that holds layer info, lines, arcs, vias, elements and text objects. A paste buffer is just a pcb_data_t too. The current element object is a special thing that can host these 5 type of subobjects: - pads (basically the line object, always on copper, code slightly modified for elements) - pin (via with some hacks, modified for elements) - element-line (a modified line object, always on silk) - element-arc (a modified arc object, always on silk) - exactly 3 text objects (always on silk, meaning hardwired: refdes, value, description) So an element has its own struct (pcb_element_t) with 5 lists for these. As you see every one of these are hand crafted, special cased variants of otherwise generic objects. This means we have a lot of code duplicated, e.g. to handle both normal lines and element-lines. The other problem is that if we wanted to have anything else (like polygon on silk, copper lines and arcs that are not pads), we'd need to introduce even more special cases... So the subcricuit idea is to drop the current element model and introduce a new one that simply has a pcb_data_t instead of custom lists and special cased objects. This means whatever objects a board can hold (in the present or in the future) an element would be able to hold too. For this the two major issues to solve are: 1. have some sort of a layer mapping; for boards and paste buffers, the layers named in a pcb_board_t are very specific, e.g. "this is the top copper layer that I use for signal, this other is the 3rd inner layer that I use for VCC". This wouldn't work in a footprint, because you want to use a footprint with different boards that have different layers. Instead we need some more abstract description there, like "the outer copper layer on the side where the footprint is placed; the silk layer on the othe side". Note that it can not name "top" or "bottom" sides, it can not depend on specific internal layers or even on the fact that there would be internal layers. It must be all relative to the side the footprint is placed on. So this means we need some sort of automatic layer mapping logic too. Kicad has something similar according to their file format, and I made some experiments with a nice, abstract, still simple design with tEDAx (it is worth checking out the footprint spec on this) This would allow me the current special casing that are there because of how these objects should behave vs. layers. 2. separate the "terminal" concept from geometry. Geometry is a line, a polygon, a hole. A terminal is something that's on the netlist, has a "pin number", "pin name" but is a logical idea, has no geometry. Currently when we say "pad", it differs from a plain line mainly because it has some extra fields for the terminal info. A pin is really just a via, with a few extra fields for the terminal info. If we wanted to have random polygon pads, we'd need to invent a polypad object that's basically a polygon with the extra fields of a terminal. Then add a lot more special casing everywhere in the code. What I want to do instead is the separation of terminal and geometry with some cross-linking. If we arrive from the netlist side, we see there's a terminal, which links to a few generic geometrical objects (lines, polygons, circles, holes). If we are arriving from the geometry (e.g. a connection find on copper), we hit one of the copper objects (e.g. a line, a poly) that refers to a given terminal. This would allow me to remove the current special cases for element objects that are there because they need to know which "pin" they are. Regards, Igor2
Reply subtree:
560 Re: [pcb-rnd] [dev] API fixup - trends from ge...@igor2.repo.hu