kicad-developers team mailing list archive
Mailing list archive
Re: PCB Layer Stackup UI
Tue, 08 Dec 2009 19:37:24 +0100
Thunderbird 126.96.36.199 (Windows/20090812)
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
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)
These are the kinds of things to sleep on. Maybe we should make a list
of questions, and play devils advocate for a day.
Here is the first devils advocate's corner:
What about the Pcbnew file format (Yes, this is the main problem, in fact)?
Maître de conférences
Directeur d'études 2ieme année.
Génie Electrique et Informatique Industrielle 2
Institut Universitaire de Technologie 1 de Grenoble
BP 67, 38402 St Martin d'Heres Cedex
GIPSA-LAB - INPG
Rue de la Houille Blanche
38400 Saint Martin d'Heres