kicad-developers team mailing list archive
Mailing list archive
Re: Experiments and considerations for more layer
On 2 September 2013 10:02, Lorenzo Marcantonio
> At last I tried to broke the 32 layer barrier in pcbnew. Needed the
> assembly and courtyard on both sides, so the ECO are not enough. Also
> they need to be flippable, too.
> Result: succesful, learnt things that could be useful later.
> First, the huge LAYER_NUM/LAYER_MSK work I done previously was in the
> right direction. Once I coerced the compiler to use 64 bits for the
> mask, it worked flawlessly (yay!). First trouble: in 32 bit arch that
> would be a long long int (or int64_t), on 64 bit arch simply a long int
> (still int64_t). Handling it as an enum (by the standard) make the
> compiler choose these types. Cue printf format issues and related
> warnings. New C++ has a "class enum LAYER_MSK : uint64_t" to force the
> choice but it also put the enum values in the enum namespace, so you
> have to type LAYER_MSK::FRONT_LAYER instead of simply FRONT_LAYER.
> Technically useful, but hugely unconvenient.
> 90% of the modifications had to be done in the layer include and
> pcbcommon source (obviously). The flipping thing is there too, worked at
> the first try(of course, that meant recompiling 90% of pcbnew:P)
> On the UI side: most painful the stackup dialog; I'm not a wxformbuilder
> expert but at the end the fastest thing was to hand edit the xml! That
> dialog would be a lot of fun to generate dynamically IMHO. Also the
> layer bar needed the obvious add, but nothing painful. Side note: the
> layer bar is *not* scrollable, so lots of layers could be an issue,
> there. The pad box would need change if we wanted pads on some new
> layer, of course (but these would be probably 'special' technical layer,
> anyway, so they would need special code).
> Other (minor) issue: the layer chooser (used for example in the module
> editor) works with a range and the code relies on it to exclude the
> board edges from the selection. That broke adding new layers (since the
> edge is not anymore the last). The 'right' way to fix it would be using
> a mask instead of a range (I keep the range broken, for now:D)
> Other side issues: the module editor would really need better layer
> control, especially for visibility. Ideally the layer sidebar could be
> grafted to it but I fear it relies on a board (for showing the user
> names instead of the standard names). Also layer control for text fields
> in modules would be very useful (the file format already handles it and
> IIRC there are not many things to change in the rest of pcbnew).
> Semantic for the 'show text front/back' would need clarification
> Didn't try a plot yet, but I think it wouldn't need changes, except for
> special layer handling (example: the assembly layer show references on
> the insertion point and not on the silk position, and maybe has pad
> forced on). As special layer semantics I wouldn't put it in 'work to
> make more layer available'.
> That would work fine up to 64 layers, which is the double of the
> previously available number. After that there is a *big* problem, on the
> C++ side: literals and efficiency. If I have a supported integer type,
> the compiler can fold expressions and enums/defines work fine. However,
> using something like std::vector<bool> uses objects, not integers. So,
> a thing like LAYER_FRONT|LAYER_BACK can't be compiler folded anymore.
> Also, what are LAYER_FRONT and LAYER_BACK? static constant objects?
> temporary objects on the stack? Maybe the new literal syntax defined in
> the new standard will help, when the time will come.
> Lorenzo Marcantonio
> Logos Srl
I could really do with more layers too. Although when I say *more* layers,
I mean that I could really do with dedicated assembly and courtyard layers.
The assembly layer needs the reference field on, as you say, at the
insertion point of the component as well as a physical bounding box; This
should flip when the component is flipped.
Thanks for spending the time investigating it, because I'll sure be glad of
any work that goes into supporting these layers.