5 Please note that this document is a work in progress and
6 currently represents a proposal for a future enhancement.
7 The goal of this document is to define what changes need
8 to be made to the .pcb file and library handling.
9 Hopefully with sufficient up front
10 thought and review, the implementation will correctly address
11 some of the issues faced in real printed circuit board design
14 Once the functionality describen in this document have been
15 implemented, this document will be replaced by a corresponding section
22 Currently the elements in the pcb database are stored with the
23 following features/limitations.
25 - rotated elements have their internal contents all rotated as opposed
26 to the element as a group having a parameter specifying a rotation.
27 This causes two main problems. The first issue is that there is no
28 way to determine the rotation of a part without resorting to
29 looking for which quadrant pin 1 is in relative to the center of the
30 part. This algorithm may not be correct for all footprints and
31 will cause issues with the XY manufacturing file.
33 The second problem is that it makes it harder to globally update a
34 particular footprint in a design. Suppose you find a problem with
35 your 0402 footprint and you want to update all of them in your
36 layout. Your .pcb file currently may have up to 8 versions (4
37 rotations, 2 sides) of the 0402.
39 proposal: store a board side and rotation flag for the element as a
40 whole. The internal contents of the element will show top layer
44 The internal contents should remain rotated and on the layer they are on.
45 This avoids constantly re-computing these values for every re-draw for
46 example. The flags can inform the system how to transform the component
47 back (or transform a replacement version forward) to the "standard"
48 format. Presumably this would be an uncommon operation in which the
49 computations take place.
52 - footprints largely don't have a concept of where they came from.
53 This means there is not a convenient way to tell pcb "update all of
54 the 0402's on this board". In addition, there is not a good way of
55 telling if an element has been modified after placement. For
56 example, place an element and move the silk location or change the
57 soldermask clearance. It would be good to be able to distinguish
58 these "post-instantiation" changes from the original footprint.
60 proposal: store the elements in two parts: the unmodified
61 footprint followed by a list of changes (move silk by (+10,+25)
62 mils, change square flag on pin 1, etc.).
65 better to again store the modified footprint followed by a list
66 of how it was modified (thus making the modifications reversible).
67 Again this saves constantly re-computing with highly repetitive
68 operations like drawing compared to seldom done operations like
69 figuring out the un-modified version (which at the moment is not
70 possible so it is as seldom done as can be imagined.
73 proposal: store the 'newlib' name for the footprint (note that we
74 plan on adding a step to the build system which extracts a newlib
75 style library from the m4 libraries so that the core of pcb will
76 only deal in newlib libraries).
78 This should allow the implementation of a feature which reports all
79 elements whose unmodified definitions do not match the library. In
80 addition it should allow the implementation of the following
81 footprint update options:
83 - update selected instance
84 - update all instances of the same master
85 - update all instances of any master
87 - preserve user changes when doing the update
88 - clear user changes when doing the update
89 - preserve a selected set of user changes (like maybe keep the silk
90 changes but not the square flag change)
92 - provide a "dry run" report of what would change if the selected
93 updates actually were applied
96 - the issue of updating footprints brings up a few other considerations.
98 When refering to the library search path to see if any footprints are
99 out of date, how does one deal with multiple footprints with the same
100 name in different directories? One thought, based on an idea by
101 Ales, is to locate all footprints in the library with the same name
102 and compute a hash on a canonicalized version of the footprint. This
103 hash could be compared to a hash for the footprint in question in the
104 layout. If none match, the user would probably need to be prompted to
105 pick which one he/she wants to update to. If a match is found, then
106 we know which footprint the master was.