kicad-developers team mailing list archive

["Tim Hanson" <tim@...>]

Hi Everybody,

I'm about ready to commit the 'branch' which allows for proper
handling of multiple instances of sub-sheets and sub-sub sheets in any
type of hierarchy you like (so long as it is not circular), including
proper (so far as I can test) netlist and BOM and erc creation.
Component references are also handled in a flat way, with different
refs on different instances of the same sheet (as the hierarchy will
be compiled down to a nice flat board:). These are stored in the
schematic file in a way that is backwards compatible with old
schematics, but for the following changes:
* GLabels are proper global labels, and connect all sheets in a
hierarchy. They are still called Glabel in the schematic file, so if
you (like me) meant 'Hierarchal label' when you inserted a glabel in a
past version of eeschema, you'll have to go back to the .sch file and
change 'Glabel' to 'Hlabel' (= hierarchal label). (I still have not
made a new icon for hierarchal label on the right toolbar..)
* you will have to re-annotate, but only if you use a hierarchy, so as
to fill out the hash which converts path to reference.
* all sub-sheets in a given schematic file *must* have different names
(SheetLabel in the C++ struct), as the SheetLabel is used to generate
comprehensible netlists.

Internally, frame->m_CurrentScreen has been replaced with
frame->m_CurrentSheet, which is an class which stores an array of
DrawSheetStructs. This array is a class whose Path() routine returns
a 'path' corresponding to the timestamps of the DrawSheetStructs (or a
human-readable path, in the case of PathHumanReadable() ) The path is
used as a 'key' to the reference hash. Dont' use m_CurrentScreen
(it's null!), use GetScreen(). I made GetScreen virtual because some
of eeschema's dialogs keep around a WinEDA_BaseFrame (or something)
pointer, whose GetScreen() method improperly returns m_CurrentScreen.
nothing complex... but better to say than not to.

Cross-probing on PCBnew seems to work; only one change was required
(an int to wxString for the sheet 'path'). cvpcb (which I normally
don't use?) did not have to be changed at all, as it already handles
the unique IDs or timestamps as wxStrings.

svn status | egrep "^C" returns nothing on my ~/kicad, I can make
clean and make with no warnings (on linux)... I would be happy to make
a branch somehow (as Dick requested), but this might be hard since we
have no 'trunk' directory; I guess what would make me happier would be
to submit the changes and get everyone's immediate feedback. I'll be
running eeschema in gdb for the next few weeks just in case ;) I
certainly would not be happy if all my diligent work will only be used
by me!

thanks,
Tim

On Jan 24, 2008 8:49 AM, Dick H. <dick@...> wrote:
>
>
>
>
>
>
> --- In kicad-devel@xxxxxxxxxxxxxxx, "Tim Hanson" <tim@...> wrote:
> >
> > Hi Dick,
> >
> :
> :
> > I'll just keep modifying my branch until there
> > is overbearing reason to use it (like import gEDA files..)
>
> Recently I have been working on a bridge (specctra import/export).
>
> Building bridges, I have come to realize recently, is
> a great value proposition. All the value on the other
> side of the bridge comes to you, merely for the cost of
> building the bridge.
>
> The gEDA import is interesting. Four paths come to mind:
>
> File type____________convert__________import__
> ----------------------------------------------------------
> eeschema symbols 1 2
> pcbnew footprints 3 4
>
> We could pursue either batch converters, or we could pursue
> an abstract import API which would allow Kicad to use the gEDA
> libraries directly, with "on the fly conversion", as
> the file is read in.
>
> Of course, I'd prefer 2 and 4 in the above matrix, and I want them
> done tomorrow. :)
>
> Boy, that felt good. (I'm usually on the other end of that type of
> interchange.)
>
> Dick
>
>