kicad-developers team mailing list archive
Mailing list archive
Re: PCB Layer Stackup UI
Dick Hollenbeck <dick@...>
Mon, 07 Dec 2009 15:30:40 -0600
Thunderbird 184.108.40.206 (X11/20090817)
Dick Hollenbeck a écrit :
Dick Hollenbeck wrote:
One idea to put on the table is an actual layer stack up sequence,
would be a modifiable data structure which defines the order of layers
within a board. The current notion of layer mask would stay, it's just
that a person could not assume that a layer with a mask of (1<<0) is
next to a layer with a mask of (1<<1) unless the layer stackup
says it is.
I rarely settle on the first idea, so here is another one to put on the
table. We make the BACK layer mask dynamic, not fixed. Its value would
depend on the copper layer count. If the copper layer count is 2, then
the BACK mask would be (1<<1), and the FRONT mask would be (1<<0). For
a four layer board the back mask would be (1<<3), etc.
0 0 Front
N N Back
Advantage: no dynamic stackup sequence, but does have the dynamic
BACK mask. The order of the bits in the mask set would be reversed. I
do not think this one is hard to implement, the drawing code would
simply walk the mask in reverse from what it is now, starting at
position GetCopperLayerCount ()-1. We could fix existing board files
at time of first load, once and for ever after.
Eventually we can go to a 64 bit mask and expand the number of copper
layers quite easily, using a datatype of uint64_t.
For a single layer board, the notion of back or front is moot, because
the user can name the layer anything he wants.
Oops, I guess this is not a true statement since text is reversed, but
maybe a 'side' flag in this case is needed, or we make this kind of
boards simply have two sides, with one side being empty. All boards
actually have two sides anyways if you think about it.
For a single layer board
the layer mask would always be (1<<0)
Well, i am very interested to see a board that has really just *one* side...
Here are some thoughts:
I am not sure the layers mask is a good idea (well, i am sure this is a
This is rather a legacy of the early times of pcbnew.
Layers mask is used mainly for pads.
Vias use an other way: there handle a layer pair: the first and the last
And all others items uses just a layer number
Pads could use the same way to handle the copper layers they use. (SMD
pads will just use the same first and last layer)
The method IsOnLayer() could be used everywhere instead of the layer
Others cases that use layers masks are mainly plot and print functions
to know what layers must be plotted.
In this case, this is easy to use an array of layers id to do this
instead of a layer mask.
Removing the layer masks has some advantages:
- an unlimited number of copper layers
- no need to handle both layers masks and layers numbers (or layers id)
(and no need to calculate layer mask from layer number and layer umbers
from layers masks).
And of course, solves your problem (the first layer and the last layer
in all vias and pads instances in board could be easy to update when the
layer could is modified)
I believe this could need less work (and could create less bugs) than
changing the layers masks handling.
Remember also in the footprints libraries, the number of layers is not
know, and therefore using a layer mask that depends on layers number is
In fact, we just must think about the way to handle non copper layers
used in pads (solder mask, solder paste...) (a non copper layer id array ?)
but i am pretty sure the work to code the layer pair handling in pads is
less than changing layers mask handling, and remove bugs due to this
Having said this, I am thinking the best is to keep the current layer
mask handling until the next stable release is done,
and remove the layers mask from the pcbnew and the gerbview code after
this release (and to give an unlimited number of copper layers handling
in pcbnew and gerbview).
(of course, this also involves changes in pcbnew files format).
What are you thinking about this ?
I am thinking about it, and will study the code some more in the next
couple of days/weeks. I am a little concerned about delaying the major
changes. I have some time now, I and want to finalize the UI elements
that I have committed to. I often do most of my contributions to Kicad
over Christmas. I am not intimidated by the prospect of breaking
something. It happens, but it happens not so much when I write the
code. You might actually be surprised to learn about the software I
write in my day job.
One can argue that the purpose of a beta test cycle can be to wring out
these problems (if any) and that we should use a release beta test cycle
to our advantage in this regard. So I am not in favor of waiting for
the changes, which would likely cause all the pending UI changes to have
to be re-done. Besides, any remapping is no more complicated than what
we already do in the specctra import and export. Having said that, I am
not in favor of rushing to a solution either. I just want us to agree
on a solution, then we should code it, done.
If we go this way, instead of committing to an unlimited number of
layers, lets limit it to some number <=255, that way we can hold your
layer numbers in a uint8_t byte array. Specctra DSN has a limit of 255
layers also. Maybe we could use bit 7 of the layer number as the
non-copper flag. This way we could handle 128 non copper layers and 127
BTW, I do have some SMD footprints that have heat sinking copper pads on
internal layers (all copper layers), complete with through holes to give
the heat a pathway. Can something like this be done with layer numbers,
without explicitly reserving *fixed* values for the starting and ending
layer numbers and still maintain layer count independence? That is, if
layer number for 'back' is non fixed, can a footprint like this truly be
layer count independent? In specctra you'd have to give all layer
numbers in the "padstack", and this inherently makes the footprint layer
count dependent. Currently I believe these footprints may in fact be
layer count independent, as you seem to suggest.
These are the kinds of things to sleep on. Maybe we should make a list
of questions, and play devils advocate for a day.