kicad-developers team mailing list archive
Mailing list archive
Re: PCB Layer Stackup UI
Dick Hollenbeck <dick@...>
Tue, 08 Dec 2009 14:28:27 -0600
Thunderbird 18.104.22.168 (X11/20090817)
Dick Hollenbeck a écrit :
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.
Well, I hope this next "Kicad Christmas" will be a merry Christmas, Dick.
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.
Well, thinking before coding is always a good way of work.
But I believe this change can be made for the next release, if you are
thinking you have the time to do that.
Well a uint8_t byte array with a bit 7 as a flag sounds like a
signed_int8_t byte array.
128 copper layers and 128 technical layers seems reasonable (at least
for very simple and small boards...)
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
What is the most number of layers for a PCB board that you have ever
heard of? I cannot tell if you are being humorous above or not.
and can be seen as an "unlimited" number of layers.
Currently, Pcbnew does not know stacked pads (assuming stacked pads are
pads with different sizes/shapes on different layers).
So footprints are not dependent on layers count, because a pad can be
currently on top (front) layer or bottom (back) layer or all layers.
Even we handle pads stacks, handle separately top, bottom and inner
layers could be acceptable for the Module Editor.
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.
Layers count is important only for tracks and vias (and mainly microvias)
I think if we introduce a new class (hierarchy?) called LAYERSET we can
hide the details of how the IsOnLayer() method is done, along with the
hiding the data that is used in that test. So BOARD_ITEM::IsOnLayer(
aLayerNumber ) would then call LAYERSET::IsOnLayer() to do its work, and
the LAYERSET data would be hidden inside itself. This way we can
support a number of different types of layerset specifications,
including but not limited to: list, range, and all copper layers. The
problem with using "list of layers" to also indicate "all layers" is
that this becomes a layer count dependent test. Same for range.
Whereas if we have a special flag for the "all copper layers" case in
the encapsulated data of LAYERSET, then we can handle both situations.
A LAYERSET element would become part of a D_PAD element. And would have
its own textual representation when being serialized to a file. The
textual representation could be dropped into the current location for
layermask for D_PADs in your existing *.brd file format.
Examples of a textual representations for LAYERSET specs (range, list,
and all) would be:
(layers 0-14) # a range
(layers 0 1 2) # a layer list of arbitrary length
(layers all) # all layers
(layers front back) # a list, but with special layer names
(layers front) # front only
(layers back) # back only
As said, these textual representations could be placed anywhere you are
currently using a layer mask or multiple layers in the current format.
A wholesale board file format change is not needed, but I am not
expressing resistance to said wholesale change.
I suggest that we add a parameter to the xxx::IsOnLayer() test in
addition to aLayerNumber, that being the BOARD*. This way we can query
the layer counts without walking up a datatree from a D_PAD to the BOARD
As an implementation detail, I probably would still go with a bitmap of
enabled layers, but expand it to the necessary number of bits required
to support all our desired layers. It is a simple matter to create a
bitmap mask from aLayerNumber. This is a direction of conversion, from
index to mask, that is no problem. It is the other way around that is a
problem, mask to index, and we should not use or need any conversion in
this direction. The important thing is that the file format change does
not limit us in any way, and the details of how we represent LAYERSETs
should be encapsulated, and only exposed through sensible member
functions which aid in the data hiding. You probably need to forget
what I said before about byte arrays being useful internally. It think
a bitmap is still superior to a byte array. (But a bitmap can be done
in the future or now with a byte array. Until we exceed 64, I would use
a uint64_t to hold the bitmap.)
So we would swap the direction of the layer numbers, and start at 0 for
FRONT. The question I still have is what value would we use for BACK?
This is important only internally, since the new file format never
exposes the numerical value of BACK!
We should probably add a Save() or Format() type function to LAYESET to
maintain the data hiding duties and understanding within the class itself.
If you want to take on more and redo the entire board file format, then
I suggest the specctra format, and starting with a sample using a text
editor. See if you can create a board file using a simple text editor
according to your heart's desire.
Out of this will fall out the new format, and the format of all nested
Or we can dissect out the layer specs and layermasks that he have now in
the current format, and replace them with the LAYERSET textual
representation, and mark the new file format revision in the header.
Then we have to decide on whether we keep all the board legacy
conversion code in PCBNEW or put it into an external conversion program,
so that PCBNEW can be leaner.