Why do I need to draw the same symbol N times?

On Fri, 23 Sep 2016 08:47:48 +0200

Morten Leikvoll <mleikvol@yahoo.nospam> wrote:

You dont need to redraw the symbol. You just create a new component

and add the symbol + all the packages that work with this symbol at

the same component, then connect them correctly. This works, even if

some packages have more gnd/shield pins, cause every package is

connected separately.

As Rik Steenwinkel pointed out, that doesn't work with very many chips.

Microcontrollers, FPGAs, power supply chips being ominous examples.

Micros more often than not drop/gain a few port pins between package

variants. FPGAs ditto. Power supply chips often drop rarely used

feature pins. SPI FLASH chips tend to have a 'BUSY' signal on the higher

pincount package, which is dropped if you go to the smallest

pincount/footprint one. So the list is quite long.

In my original post I was specifically talking about packages with

different pin counts and signal pins going missing in the smaller

package.

But currently (7.x), if the symbol differs slightly betweeen

packages, you have to copy/make a new symbol, and add/remove pins.

Exactly. As it has always been the case. Hence my request: I'd like to

draw only one symbol and assign a package, even if the symbol has

more pins than the package. Then the schematics could grey out or even

completely hide the pins that are not available on the package.

In the software world copy-paste-massage-ing code is one of the cardinal

sins, and rightly so, why am I forced to do it with my hardware?

--

Zoltán Kócsi

Bendor Research Pty. Ltd.

zoltan wrote on Sun, 25 September 2016 01:53

Hence my request: I'd like to

draw only one symbol and assign a package, even if the symbol has

more pins than the package. Then the schematics could grey out or even

completely hide the pins that are not available on the package.

By the time you specify which pins should be greyed out, you might as well

have made the minor modifications from the symbol with a little more or

little less pins.  If you're only changing a few pins, there isn't really a

problem to solve here.

You don't want Eagle to just assume that you intentionally used a symbol

with too many pins and not show you the remaining ones.  That would

circumvent useful error checking.  Also, if a different chip has fewer

pins, you most likely want to draw the symbol differently.  You may want to

make it a little smaller, change some of the labeling inside the symbol,

etc.

A good example is a voltage regulator.  The simple 3-pin variety can be

drawn more simply and smaller than one with a shutdown input, for example.

I wouldn't want the simple 3-pin version burdened with a greyed out

shutdown input.  I also wouldn't want it drawn bigger with inexplicable

extra space in the 3-pin usage case.

If the symbols are similar except for a few pins, then there isn't really a

problem here.  Copy and edit works fine.  If the symbols are substantially

different, then you're going to have to do some work for each case one way

or the other.

Quote:

In the software world copy-paste-massage-ing code is one of the

cardinal

sins, and rightly so,

Exactly.  This is the same thing.  Just like with software, you copy and

paste, then make a few minor edits to adapt to details of the situation.

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

On Sun, 25 Sep 2016 17:32:32 -0400

Olin Lathrop <eagle9304@embedinc.com> wrote:

By the time you specify which pins should be greyed out, you might as

Um, all of them which I did not assign to a package pin? What else

should I specify in some time-consuming manner?

You don't want Eagle to just assume that you intentionally used a

symbol with too many pins and not show you the remaining ones. That

would circumvent useful error checking.

So, maybe a message box asking me whether I really want to assign this

package to this chip could be a good solution?

Also, if a different chip

has fewer pins, you most likely want to draw the symbol differently.

Most definitely not, especially not for microcontrollers or FPGAs or

anything with 20 or 50 or 100 or 200 or more pins of which a few

percentage may or may not be present on any particular package variant.

It is not a different chip, it is the same chip, except that some of

its pins on the silicon are not connected to package pins.

A good example is a voltage regulator.  The simple 3-pin variety can

be drawn more simply and smaller than one with a shutdown input, for

example. I wouldn't want the simple 3-pin version burdened with a

greyed out shutdown input.  I also wouldn't want it drawn bigger with

inexplicable extra space in the 3-pin usage case.

And how about the 24-pin variety (a switch mode), which is also

available in a 21 pin variety, being exactly the same except that a

normally left open pin, only used for synchronising multiple chips, is

not available (the other 3 missing pins are the ground pins, which are

now all on the central tab under the chip)?

Quote:

In the software world copy-paste-massage-ing code is one of the

cardinal

sins, and rightly so,

 

Exactly.  This is the same thing.  Just like with software, you copy

and paste, then make a few minor edits to adapt to details of the

situation.

I don't think you understood what you quoted and said 'Exactly' to.

Cardinal sin means something that one should never, ever do. It has

religious origins, the 'cardinal sins' are the '7 deadly sins' of

Christianity, like murder. Copy-paste-massage is known to be the source

of bugs too numerous to mention and is generally considered a very bad

way of doing software.

--

Zoltán Kócsi

Bendor Research Pty. Ltd.

On 09/25/2016 05:32 PM, Olin Lathrop wrote:

zoltan wrote on Sun, 25 September 2016 01:53

Hence my request: I'd like to

draw only one symbol and assign a package, even if the symbol has

more pins than the package. Then the schematics could grey out or even

completely hide the pins that are not available on the package.

 

By the time you specify which pins should be greyed out, you might as well

have made the minor modifications from the symbol with a little more or

little less pins.  If you're only changing a few pins, there isn't really a

problem to solve here.

Olin,

The implication of extra work is not entirely accurate.  This has

already been discussed in at least one thread that I started titled

"Allow and Hide Unconnected Pins." in this newsgroup on December 20th of

2014

In my case, I was dealing with the MSP430 family of microcontrollers.

Others have run into this problem on Xylinx, Atmel, and others.  This

addresses instances where everything on the glass is the same.  The

difference is that on smaller packages with fewer pins, some pads on the

die are not wired to pins on the package.

(back to Eagle's definition of pads and pins...)

It is a reasonable request to create one device, draw one set of symbols

for the most extensive package, and on smaller packages either grey out

the pin on the symbol, or put an "x" at the connect point for those pins

that have not been connected to a pad.

At this time, Eagle does not permit one to choose a package that has

fewer pads than the device's symbols have pins.

There is no extra work involved - the relationship between pads on the

package and pins on the symbol established in the library editor must be

done regardless of whether are more pins than pads, more pads than pins,

or an equal number of each.

Jorge,  Is there any chance of refreshing this request?

 

You don't want Eagle to just assume that you intentionally used a symbol

with too many pins and not show you the remaining ones.  That would

circumvent useful error checking.

I also don't want Eagle to assume that using a package without enough

pads is prohibited.

An alert box in the library editor can verify the choice.

  Also, if a different chip has fewer

pins, you most likely want to draw the symbol differently.  You may want to

make it a little smaller, change some of the labeling inside the symbol,

etc.

You actually make a good argument for having the choice available to

reuse a larger symbol, or design separate symbols.  It would be nice to

have the ability to use a smaller package.  Whether one chooses to use

that feature is up to the designer.

There are many cases where one might start out a uC design with a

smaller package, and promote to a larger package as the design

develops.  Feature creep can cause this.

On more than one occasion I have designed embedded systems to accept

multiple packages of the same IC.  This allows the same design to

survive unavailability of parts.  i.e. If I can get by with a QFP48,

I'll also overlay the same package with a QFP64, or QFP80.  If the

optimal 48-pin package is out of stock, production can drop in a 64 and

keep rolling.

Sure, it takes up a bit more real estate, but it beats having to spin

another board and qualify it while production is waiting.

A good example is a voltage regulator.  The simple 3-pin variety can be

drawn more simply and smaller than one with a shutdown input, for example.

I wouldn't want the simple 3-pin version burdened with a greyed out

shutdown input.  I also wouldn't want it drawn bigger with inexplicable

extra space in the 3-pin usage case.

 

If the symbols are similar except for a few pins, then there isn't really a

problem here.  Copy and edit works fine.  If the symbols are substantially

different, then you're going to have to do some work for each case one way

or the other.

I think you're overestimating the work involved.  The proposed feature

reduces work - one does not have to create a separate device for each of

the very similar symbols that also have to be created.  The idea is one

device, one set of symbols, and variations in package connections.

In my suggestion in December of 2014, I stated that the unused pins (on

the symbol) should not be shown.  I later refined this to state that

these pins should either be greyed, or have an "x" at the connection

point, or both.  As you pointed out, it can introduce errors if the pins

are simply not shown.

Regards,

    - Chuck

On 09/25/2016 05:32 PM, Olin Lathrop wrote:

zoltan wrote on Sun, 25 September 2016 01:53

Hence my request: I'd like to

draw only one symbol and assign a package, even if the symbol has

more pins than the package. Then the schematics could grey out or even

completely hide the pins that are not available on the package.

 

By the time you specify which pins should be greyed out, you might as well

have made the minor modifications from the symbol with a little more or

little less pins.  If you're only changing a few pins, there isn't really a

problem to solve here.

Olin,

The implication of extra work is not entirely accurate.  This has

already been discussed in at least one thread that I started titled

"Allow and Hide Unconnected Pins." in this newsgroup on December 20th of

2014

In my case, I was dealing with the MSP430 family of microcontrollers.

Others have run into this problem on Xylinx, Atmel, and others.  This

addresses instances where everything on the glass is the same.  The

difference is that on smaller packages with fewer pins, some pads on the

die are not wired to pins on the package.

(back to Eagle's definition of pads and pins...)

It is a reasonable request to create one device, draw one set of symbols

for the most extensive package, and on smaller packages either grey out

the pin on the symbol, or put an "x" at the connect point for those pins

that have not been connected to a pad.

At this time, Eagle does not permit one to choose a package that has

fewer pads than the device's symbols have pins.

There is no extra work involved - the relationship between pads on the

package and pins on the symbol established in the library editor must be

done regardless of whether are more pins than pads, more pads than pins,

or an equal number of each.

Jorge,  Is there any chance of refreshing this request?

 

You don't want Eagle to just assume that you intentionally used a symbol

with too many pins and not show you the remaining ones.  That would

circumvent useful error checking.

I also don't want Eagle to assume that using a package without enough

pads is prohibited.

An alert box in the library editor can verify the choice.

  Also, if a different chip has fewer

pins, you most likely want to draw the symbol differently.  You may want to

make it a little smaller, change some of the labeling inside the symbol,

etc.

You actually make a good argument for having the choice available to

reuse a larger symbol, or design separate symbols.  It would be nice to

have the ability to use a smaller package.  Whether one chooses to use

that feature is up to the designer.

There are many cases where one might start out a uC design with a

smaller package, and promote to a larger package as the design

develops.  Feature creep can cause this.

On more than one occasion I have designed embedded systems to accept

multiple packages of the same IC.  This allows the same design to

survive unavailability of parts.  i.e. If I can get by with a QFP48,

I'll also overlay the same package with a QFP64, or QFP80.  If the

optimal 48-pin package is out of stock, production can drop in a 64 and

keep rolling.

Sure, it takes up a bit more real estate, but it beats having to spin

another board and qualify it while production is waiting.

A good example is a voltage regulator.  The simple 3-pin variety can be

drawn more simply and smaller than one with a shutdown input, for example.

I wouldn't want the simple 3-pin version burdened with a greyed out

shutdown input.  I also wouldn't want it drawn bigger with inexplicable

extra space in the 3-pin usage case.

 

If the symbols are similar except for a few pins, then there isn't really a

problem here.  Copy and edit works fine.  If the symbols are substantially

different, then you're going to have to do some work for each case one way

or the other.

I think you're overestimating the work involved.  The proposed feature

reduces work - one does not have to create a separate device for each of

the very similar symbols that also have to be created.  The idea is one

device, one set of symbols, and variations in package connections.

In my suggestion in December of 2014, I stated that the unused pins (on

the symbol) should not be shown.  I later refined this to state that

these pins should either be greyed, or have an "x" at the connection

point, or both.  As you pointed out, it can introduce errors if the pins

are simply not shown.

Regards,

    - Chuck