| Thread Previous • Date Previous • Date Next • Thread Next |
jean-pierre.charras@... wrote:
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.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 copper layers.
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 onlyAs 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 for example.
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 objects.
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.
Dick
| Thread Previous • Date Previous • Date Next • Thread Next |
