My ERC Proposal was more like a: we should at least think about it a bit instead of writing the pin type near style and number/name. We can specify ERC hints in a future-proof way without extending the current implementation. Like:
(erc_hints (pin_type power_in)) This would allow us to specify new erc hints in the future without splitting them up at different places in KiCad 7. I'm in favor of pin properties. In fact I would like to have the ability to specify properties for all important items. (Pin, Symbol, Net, Sub-schematic, Label,...). Those can be used by users and 3rd-party programs, as well as to quickly prototype new stuff like ERC rules. Regards, Thomas Am 04.01.19 um 19:55 schrieb Wayne Stambaugh: > I'm willing to add properties which are already defined to pins. There > has been talk about adding about adding electrical constraints for > advance ERC testing to symbols but that will not be part of the v6 > implementation of the new file format. It's going to be a lot of work > to implement the features we've added to v6 so this would be outside the > scope of the first version of the new file format. I'm certainly open > to discussing this as part of a later version of kicad. > > On 1/2/19 3:52 PM, mark.vandoesb...@hetnet.nl wrote: >> One thing I would like to have is user defined pin properties, just like >> the part properties. Currently I use the BOM generator to generate a >> software header file from the netlist. I have to use an additional file >> to store the information I need. It would be nice if this information >> can be stored in the symbol. This could be any kind of information, for >> example bank number or clock region for an FPGA. Or driver strenght/speed >> setting for a microcontroller. >> >> regards, >> >> Mark. >> >> Wayne Stambaugh <stambau...@gmail.com> wrote: >> >> I have updated and published the symbol file format[1] for comment. >> Hopefully there isn't too much to change. The only thing to really >> finalize is the internal units. The initial concept was unitless but >> the more I think about it and discuss with other developers, it makes >> more sense to use units for the following reasons: >> >> 1. It's easier to visualize in your head how the symbols on a given page >> size will layout. >> >> 2. Converting from other file formats (Eagle, Altium, etc) will be >> easier since most if not all of them have a defined unit. >> >> I'm thinking 10u (or possibly 100u) will make a good internal units >> value. Once we nail down the units, I will update the file format >> document accordingly. >> >> Please keep in mind that this is the symbol library file format document >> so things like constraints belong in the schematic file format. I will >> be posting the schematic file format as soon as I finish updating it. >> >> Cheers, >> >> Wayne >> >> [1]: >> >> https://docs.google.com/document/d/1lyL_8FWZRouMkwqLiIt84rd2Htg4v1vz8_2MzRKHRkc/edit >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp