2009/7/3 Andy Eskelson <[email protected]>: > Agreed that's the problem with warnings... as you say it's the same with > the compiler errors some systems generate. I must admit that once or > twice I've given up on some software due to it generating so many > warnings that I simply could not be bother to sift through the error file > to find the real problem. > > > The visual indication of a user pin is a good idea, I suppose the obvious > choice would be colour and / or shape. Colour is not over used in > eeschema so I think I would lean more to than than shape. > > Andy > > > > On Fri, 3 Jul 2009 08:51:34 -0700 > Werner Almesberger <[email protected]> wrote: > >> 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
I think the DRC needs a rethink. Exceptions seems like using a hammer to crack an egg. In the situation provided by having multiple voltage output pins which is quite common, it's like you are trying to kick the DRC to ignore this error, even though it is a valid error according to the DRC rules. I think it would be better to be able to generate the rules necessary to allow the DRC to correctly distinguish between errors, warnings and passes. In the example given where there are multiple output power pins connected together, it would seem that an output pin type could do with other attributes to give the DRC enough information. For example being able to flag an output pin as parallel capable, either globally or within it's own symbol would get us a step closer and give us finer control over the DRC. A valid situation for example is being able to parallel two DC-DC converters *if* they are capable of being paralleled, the further complication is correctly flagging and error where two DC-DC converters which are capable of being paralleled are paralleled but their output voltages differ! e.g. a 12V DC-DC paralleled with a 5V DC-DC. In the case of FPGA's and Micro's, we could possibly do with being able to define a set of pin types for a single pin. When the schematic symbol is placed, we should perhaps be able to click on a pin and change the pin type from an enum of pin types allowed for that pin. We could probably do with a list of situations/rules that cannot currently be defined with the DRC, and then we can start tackling a way of being able to define the appropriate rules. Does this sound reasonable, or a nightmare? Best Regards, Brian.
