kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature