Andy Eskelson wrote: > Warnings are just that, a warning it's up to the user to heed or ignore.
What I mean is that it's easy to miss warnings if your system always generates some. You're much less likely to miss a warning if your system normally doesn't complain. This applies also to compilation, Web browsing, etc. Likewise, if you disable an entire class of diagostics, you may easily miss new problems. > Exception lists... sorry to say this but that's clumsy, long winded, > and not obvious to the untrained eye. It tells you if it has hidden any exceptions. > projects and I can see it's use (I do hope you have suggested that the > error output of the ERC is usable as an input) . The current ERC format would be very hard to use for this, since it doesn't include the full information. Also, you probably don't want to just make all problems disappear too often, but instead examine every one of them carefully. Those warnings are there to help you, not to add more bureaucracy to your life ;-)) > For most uses I think > that the addition of some "user" pin types would solve many of these > problems. Assigned on a per-project basis, and you simply tag an existing > pin with a user type and then specify what it connects to. a user pin > connection would over-rule the standard ERC Yes, pin type overrides could be used to solve this problem as well, and they could help with some other issues as well - including making the constraints even tighter. If someone implements pin type overrides, I think there should also be some visual indication that such an override is in effect, or it will get very hard to review such schematics. - Werner
