← Back to team overview

kicad-developers team mailing list archive

Re: PCB Layer Stackup UI


Wayne Stambaugh wrote:
Dick Hollenbeck wrote:

jean-pierre.charras@... wrote:

Jean-Pierre, do you want to do a board like this? Do you want me to do
one? Or should we both do one and combine the concepts later?


I'll start this work asap.
But i am thinking 2 brains are better than one, and combine the concepts later is a good idea.
So feel free to also create such a board.

Attached are some ideas that I put together about the new format.

I will be working on the layer UI today, since I will be away from my desk for a few days next week.

If I were able to get to an actual DSN board text file prototype, it will be more than a week down the road. In the mean time, I suggest looking closely at the specctra DSN output files, and looking up the descriptors as you get curious in the spec. The specctra descriptors are all very well thought out.

And look over the attached document.


I just finish looking over your latest richio/dsn commit. Nice! I
forgot to ask you last night if you were going to move this into the
common library. Obviously, you already had thought of that.

Have you given any thought to creating a base LEXER and FORMATTER for
objects that should be common to all of the Kicad file formats. I'm
thinking specifically of the component library and schematic file
formats. To me it makes sense to have tokens like headers, versions,
comments, and even low level drawable objects like lines, arcs,
polygons, etc. have a common format among files. This way you would
only have to implement the LEXER and FORMATTER for objects specific to a
given file type. It would potentially prevent things like arcs being
formatted one way in board files and a different way in schematic files
and yet another way in component library files. It would also cut down
on code duplication and make it easier to read the different Kicad file
formats. I could even see using it for the Kicad project file to remove
the dependency of wxWidgets' wxFileConfig to generate and parse the
project file.

On a completely clean rewrite I *might* agree with you. But in this case I think it is actually simpler to not serve the common code master too closely. This will actually give us more degrees of freedom for now. You will notice that the specctra.h file for example declares scores of classes, does so in its own namespace, but this header file is not included in very many source files. Maybe 3 or 4 at most. Only the SPECCTRA_DB class really needs to know about these classes.

The DSNLEXER is reusable. You can define your own token space enum, it does not need to be enum DSN_T.

It can be enum BRD_T and enum SCH_T.

These tokens when encountered in the token stream, may not always have C++ objects associated with them. Sometimes they represent parameters to a larger containing object.

Common code has its limits. When you have common code you have to expose it to more client code, so it comes at a cost.

I like the idea of defining the engineering units in the file. Have you
considered making the engineering units an integer divisor. Internally
this is how coordinates are represented already and you have the
advantage of making all of the coordinates in the file in integer
format. This should make the lexer easier to implement and the files no
less difficult to read. Even for E size drawings the maximum
coordinates with units of 10000 would be 340000 x 440000. If integer
overflows in wxWidgets are a concern, use wxMulDivInt32() defined in
<wx/math.h>. Obviously the wxWidgets developers have already run into
this problem. Unfortunately, this handy function isn't documented in
the wxWidgets documentation.

You may need to read this section twice, since it seems I wrote it backwards.

The lexer already handles numbers like 123.456, so we do not save work trying to stay with integers. The problem with integer only is that it commits you to a fixed quantum or granularity where there is truly no reason to do so in the file. Yes the engineering units need be specified, but the quantum need not be fixed in the file. The specctra session file approaches this from one angle, and the specctra dsn file approaches it from the other. So I had considered and have used both strategies. I think deliberately using floating point in the BOARD file is wiser. I have no opinion on schematic library files, because I've given it no thought.

You can look at the differences in strategy by examining the specctra session file and specctra dsn files. There are elements in both to convey (units) and (resolution). I like these elements. See the spec. I implemented these tokens/keywords both in a single UNIT_RES class (so this may be an exception about dodging common code). Most of these tokens can be handled with just a few lines of code. You can see how there is scope associated with the UNIT_RES class, it can walk up to its parents. This is a way to establish limits on the scope.

In the case of future footprint libraries, I don't see any reason why a footprint could cannot use metric or imperial with this design. And a board could be a blend of both. Again, the (resolution) and (units) elements make this possible, and they have a scope associated with them. Internally in RAM, I envision a common internal unit.

The BOARDFORMATTER would be the place to put the conversion from internal units to external doubles, just before calling the ::Print() methods.

Likewise on input the BOARD_IO is a place to convert the floating point values into the internal units. It can all be isolated to a couple of routines, so it can easily be changed in the future. See the specctra_import.ccp and specctra_export.cpp files where similar conversions take place. But I am advocating member functions for BOARD_IO, rather than the statics I used.

On another subject:

The other day I said an example of a LAYERSET might be

(layers 0-4) indicating a range. I now think this was a bad design, because it taxes the DSNLEXER needlessly. 0-4 is unnecessarily difficult to tokenize.

(layer_range 0 4) would be superior, accomplishes the same thing, and is actually easier at the parser level, which is just above the lexer level. But since it came up again, it probably makes a stronger point now.