2009/7/7 Werner Almesberger <[email protected]>: > 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" ;-)
I don't think exceptions should be excluded altogether, they could be very powerful in allowing a user to get around an exceptional case in the ERC. I think another file extension and file format to support and document could be a pain though, integrating this into the .sch file must be a better place? I have nothing against 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 :) I'm not sure where the extra overhead comes from, there would be a small piece of text in the modules description to represent the allowable pin-types. The additional functionality would allow you to select a pin in your schematic and then assign a different pin-type. >> 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. Yes, there are a lot of combinations, but if you do not explore the possible pin types and combinations you're working blind. However, you are the one writing this patch so please feel free to ignore me completely ;) I am struggling to find the time to contribute, but hopefully I'll have a common object properties patch soon for people to have a look at. Best Regards, Brian.
