kicad-developers team mailing list archive

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

yes, I've thought about this.

-- The multiple units per device are not such an issue if, like me, you
group all the units in a given device onto one sheet. I think this is a
semi-reasonable assumption. It becomes too confusing if you do not do
this.
-- Concerning long references, it is not such an issue if you name your
sheets with really short names .. like "0" or so. Then reading a
component adds a maximum of one digit to the component reference. But, you
are right in that ultimately all this is compiled down to a board, which
is 'flat' in both a physical and hierarchal sense, and numbers are a
concise way of writing & storing unique identifiers :) Yet if you do use
0402, SC-70, CSP etc there is no room for silkscreen anyway.

That said, we could avoid all of these problems by extending the .SCH file
format to include the possibility of multiple references per device (or
unit). This was my original intention, but then somebody (Frank Bennett)
on the list suggested a hierarchal system of naming. Actually, it would
not be impossible to allow both naming schemes, selectable via a radio
button. You would have to modify the file format, though. I suggest
extending the
L R R35
line to something like
L R R35 R67 R99 R131
etc
I think this would not break old versions of eeschema.
The location and size of the text would still be stored in the
F 0 "R35" H 6650 1800 50 0000 C C
line, with the R35 exchanged with an entry in the reference list, indexed
by the # of the containing sheet.

Right now, I've split up DrawSheetStruct and SCH_SCREEN so the former
contains a reference to the latter. Hence, you can have multiple
DrawSheetStructs referring to one SCH_SCREEN. SCH_SCREEN has the
EEDrawList of components. I think this is better than having a number of
duplicates in the hierarchy, as is done now, as this allows changes to one
schematic to immediately propagate to all other schematics, each which
ultimately is tied to the same file anyway.

While I'm at it:
-- Would it be ok to split the header files up? Right now, if i make one
change to wxstruct.h, I have to recompile eeschema, which takes a while.
-- What about class names? There is:
--- SCH_SCREEN,
--- DrawSheetStruct,
--- EDA_DrawLineStruct,
--- WinEDA_ErcFrame, & others.
I get the Win{...} files, they are all derived from wxWidgets classes. 
Would it be good to clean all this up?
-- The file names are confusing: there is:
--- annotate_dialog.cpp and dialog_find.cpp,
--- component_class.cpp and class_screen.cpp and sheet.cpp.
Class member functions are often spread out among different files. It
does not bother me -- I have everything in KDevelop, and when i want to
change something i just grep all the files, but ... ?

Anybody have opinions on these things?

> Tim Hanson a écrit :
>> Hi,
>>
>> Yes, I'm willing to do this, and I've already got some start.
>> Originally
>> I had planned to give every component a different reference depending on
>> the sheet instance it is in (orcad style, i guess), but a hierarchal
>> name
>> is much, much better (and requires no change to the file format), so
>> let's
>> do that? It will make the netlists longer, but it will also make them
>> more readable. Unless anyone has better ideas, I'll start tomorrow ...
>> cheers,
>> Tim
>>
>
> This does not work for components which have more than one part per
> package, like a 74HC00.
> In this case the component must have the same reference in all sheets
> (say U1), and this is only the selected part (U1A U1B or U1C...)
> and not the reference which changes from a sheet to an other sheet, and
> **not** the reference.
> Of course, the board knows only U1.
> In fact, handle the multiple parts per package components is the main
> difficulty.
> And most of cases we can't have long references in a board, because smd
> footprints are smaller and smaller,
> and only very short references (also true for values) can be drawn on
> the board.
> (And if a sheet includes an other sheet, references can become *very*
> large.)
>
> --
>
> Jean-Pierre CHARRAS
>
> Maître de conférences
> Directeur d'études 2ieme année.
> Génie Electrique et Informatique Industrielle 2
> Institut Universitaire de Technologie 1 de Grenoble
> BP 67, 38402 St Martin d'Heres Cedex
>
> Recherche :
> GIPSA-LIS - INPG
> 46, Avenue Félix Viallet
> 38031 Grenoble cedex
>
>
>