kicad-developers team mailing list archive

["jean-pierre.charras@..." <jean-pierre.charras@...>]

Dick Hollenbeck a écrit :
> Jean-Pierre,
>
> 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.
> 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
> copper layers.
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...)
and can be seen as an "unlimited" number of layers.
> 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.
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.
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.
>
> Dick

Here is the first devils advocate's corner:
What about the Pcbnew file format (Yes, this is the main problem, in fact)?

--
Jean-Pierre CHARRAS

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

Recherche :
GIPSA-LAB - INPG
Rue de la Houille Blanche
38400 Saint Martin d'Heres