kicad-developers team mailing list archive

[Thomas Pointhuber <thomas.pointhuber@xxxxxx>]

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.vandoesburg@xxxxxxxxx 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 <stambaughw@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>> 	Unsubscribe : https://launchpad.net/~kicad-developers
>> 	More help   : https://help.launchpad.net/ListHelp
>>
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

Attachment: signature.asc
Description: OpenPGP digital signature