Brian Sidebotham wrote: > I think the DRC needs a rethink. Exceptions seems like using a hammer > to crack an egg.
I would view exceptions as a way to include some of that part of reality in the ERC that the underlying model doesn't accurately represent. The exception mechanism I proposed filters the results of the model check. It's about as good or evil as using "grep" ;-) > 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. That seems to be a special case of being able to override pin types in general on a component and project basis. You probably don't need the extra overhead of constraining that choice - there aren't so many choices to start with, and the one used to deal with the exceptional case will likely be a fairly permissive one anyway. By the way, the commits from the last days show that Jean-Pierre is busy rearranging the ERC. Maybe he's got a plan already :) > 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. Hmm, there should be quite a lot of them :-) A more practical question may be to determine where to draw the line between making KiCad's ERC more powerful but also more complex, and delegating more sophisticated checking to external programs. Maintaining more complex models in KiCad has its cost. Already now, the pin type definitions are probably the most time-consuming part of making new circuit symbols. - Werner
