kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 2 September 2013 10:02, Lorenzo Marcantonio
<l.marcantonio@xxxxxxxxxxxx>wrote:

> 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
> obviously.
>
> 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
>
>
Hi Lorenzo,

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.

Best Regards,

Brian.