Tim Hanson a écrit :
>
> 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.
>
A problem when using the sheet number or the sheet name is these two
items are subject to change:
- the sheet number changes when adding a new sheet.
- the sheet name changes when the user edit it...
- Adding the sheet number or name to the reference is a good idea for
simulation,
but this usually creates a big problem for boards if the reference of
already placed footprints changes.
In fact we can reannotate a schematic without problem on a board, but
only if we take care.
All the items in kicad have a time stamp (m_TimeStamp member of the
EDA_BaseStruct class) which is set when the component is put on a sheet.
This time stamp is different for alls items, and does not change when
editing (but it changes if we delete a component, and reload a new
identical component )
This feature allows to reannotate components in the schematic and send
the changes to the board in a 3 steps manner:
1 - create a fresh netlist and read it by pcbnew (not really necessary,
but ensures the time stamps are corresponding between the schemativ and
the board)
2 - reannotate schematic and create the new netlist
3 - Reread the netlist by pcbnew, using the option "module selection" by
time stamp. the new references will be updated, from the time stamp.
So remember the time stamps must be handled like the references
> 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.
>
As prevously seen, the time stamp and also must be handled in a similar
manner...
Obviously, the .SCH file format will be changed to support this new
feature.
Of course we can't expect old versions of eeschema read a new feature in
.sch files.
In fact, this is not a problem.
I think the .SCH file format might not change when the projectno has
not a complex hierarchy
If the project has a complex hierarchy, new format will not be read by
old eeschema version,
but in fact, it is already the case! because annotations and time stamps
are lost.
Do not bother with old eeschema versions.
So we can add new lines for each component in a complex hierarchy like
(and somewhat more verbose than other lines):
$Comp
L GND #PWR01
U 1 1 4718A579
AltRef "sheet_id" Ref="Ref" Part=n TimeStamp=<TimeStamp value> // as
many lines as sheet instances and therefore sheet_id
P 8650 4550
F 0 "#PWR01" H 8650 4550 30 0001 C C
F 1 "GND" H 8650 4480 30 0001 C C
1 8650 4550
1 0 0 -1
$EndComp
> 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.
>
Ok.
>
> -- 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?
>
Cleaning up files is a good thing.
I suggest for file names:
all dialog files start with "dialog_":
dialog_xxxx.pjd (created from dialogblock)
dialog_xxxx.cpp (when created from dialogblock, use dialog_blocks to
rename files)
dialog_xxxx.h (when created from dialogblock, use dialog_blocks to
rename files)
all files relatives to classes start with "class_" :
class_xxx.cpp (and class_xxx.h)
>
> > 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
> >
>
--
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
