Just a simple question that I can’t seem to find the answer to in the documentation or online.
Is there a way to “bridge” power connections? For example, if I have a part that has PWR pins named AGND, AVCC, etc, but I connect them to VCC, GND, etc, I get ERC warnings.
Now, there are few, and I know I can safely ignore them in my case, but is there a way to bridge those connections to get rid of the warning? Just some sort of annotation on the schematic that lets Eagle know that I know about the connection and I’m fine with it?
elabudde:
Eagle version 5 allows you to accept errors like that. Ed.
Right. I can "approve" them. But I was thinking of being pro-active. Something that tells Eagle "I know they names don't match, so don't bug me about it." It is self-documenting as well, letting people who view the schematic know that you have intentionally connected two different supply names.
For example, in the C world (at least with GCC), you can tell the compiler “I know this argument is unused, so don’t give me a warning” when using the “unused” attribute.
Suudy:
Is there a way to “bridge” power connections? For example, if I have a part that has PWR pins named AGND, AVCC, etc, but I connect them to VCC, GND, etc, I get ERC warnings.
bigglez:
You proably don’t want to disable this feature (if you could, which you can’t).
Just to be clear, I do not want to disable this feature. But I do want to mask certain incidences of warnings when I know them them to be fine. Sure, I can "approve" the warnings, but they still show up in the ERC.
bigglez:
EAGLE does not allow masking of warnings and
errors for this reason. In version 5 (and later) you can accept and dismiss them manually.
Again, not a global mask. Just an individual mask. I thought of creating a part that has VCC on one end and AVCC on the other to bridge, but then it requires a footprint, which won't work.
It is more of an annotation than anything else. The point is just to prevent warnings from occurring and producing a clean ERC report.
What’s wrong with letting the error appear in ERC? Approving the error allows exactly what you’re trying to do here, connect different power nets. And ERC doesn’t actually force you to do anything, you can send a faulty board out and have it produced if you want. It’s just an extra check in case you don’t catch something obvious.
I mean if you’re obsessive-compulsive and can’t stand the fact that a program thinks you’re doing something wrong…then I can understand.
You COULD edit the part and set those pins as I/O type instead of power.
macegr:
What’s wrong with letting the error appear in ERC? Approving the error allows exactly what you’re trying to do here, connect different power nets. And ERC doesn’t actually force you to do anything, you can send a faulty board out and have it produced if you want. It’s just an extra check in case you don’t catch something obvious.
That is in fact exactly what I did. I sent out the gerbers knowing quite well that the ERC reported the warning.
I started in the ASIC world doing design using VHDL. We had strict rules on warnings. None could exist. Nada. Zilch. End of story. If warnings did exist, it indicated that there might be something wrong. And if you didn’t make the warning go away, then you either overlooked something or something is broken. A common example in this case is a warning about latches being inferred. Sure, the tools doesn’t force you to fix it, but a latch is a bad thing unless you mean it.
Once I progressed to the embedded world, we followed the same procedure. When compiling code, there can be no warnings. Nada. Zilch. Again, warnings mean there might be something wrong. There is no choice but to fix it. In fact, we always turned on ‘-Werror’ when using GNU based compilers to force warnings to become errors. Again, another example is an unused argument to a function or a variable shadowing another. They might not be problems.
So, getting an ERC report that has no errors or warnings serves two purposes:
It makes it more unlikely that there are uncaught potential problems. If the tool doesn’t warn you (and the tool does a good job), then you have a warm fuzzy that things are correct.
It is a documentation feature. When somebody opens that piece of VHDL or C/C++ code or the schematic, they can look at the schematic and see that you did something to specifically handle an anomalous case (such as VCC and AVCC being connected). So years later when looking at this schematic, I don’t have to go through the thought exercise of wondering why I have VCC and AVCC connected.
macegr:
You COULD edit the part and set those pins as I/O type instead of power.
That defeats the purpose of the PWR pins.
I posted this just to find out if such a feature existed. It apparently doesn’t. So until it does (if it ever does), I’ll have to put notes in my schematic indicating that certain ERC warnings are acceptable.
The Pulsonix software I use allows two or more different nets to be connected without warnings, but it must be done with a “star point” symbol. Perhaps Eagle has something similar.
I think the “no warnings” approach is a little impractical. I’ve certainly done enough work with gcc to know that there are things it will incorrectly complain about. Just because it’s a warning, doesn’t necessarily mean that something’s wrong or even incorrect.
In my most recent project I couldn’t figure out why I had a left over airwire on the board that didn’t exist in the schematic. It turns out that Eagle will automatically connect PWR pins that have the same name. In my case the data sheet didn’t indicate a needed connection, so I simply left the airwire and didn’t route it. I’m sure it won’t cause a problem for me, so in that case it’s ok to ignore it.
Going back to the OP’s original question, I made a post about it [here quite a while ago.
The short is you need to enable layer 53 and/or 54 for top and/or bottom respectively (or create one of your own). Draw the connecting link on this layer, and include this layer for the relevant gerber when running the CAM job.
e.g. If you you want to link two nets on the top layer, make the link on layer 53. When producing the top copper layer, include layer 53 together with layer 1.](http://forum.sparkfun.com/viewtopic.php?p=39977)
TheDirty:
I would change the library entry for the part and rename the pin to the name you want to use.
So you would have a different library version for each
instance of power supply names? How silly.
CD4013 VDD
CD4013 VCC
CD4013 +5V
CD4013 +V
Are all the same, right?
No. You would have a part that you generally use renamed to the supply name you would generally use. From the original post, he was talking about a specific part and a specific instance. It was just a quick and short term solution.
Maybe you don’t get out much or something, but try not to call people’s ideas silly right off the bat. Maybe it isn’t the best idea, but just pointing out the flaw would be enough.
TheDirty:
Maybe you don’t get out much or something, but try not to call people’s ideas silly right off the bat. Maybe it isn’t the best idea, but just pointing out the flaw would be enough.
How silly of you to point that out, you must be new here....