kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 9/17/2017 2:59 AM, Oliver Walters wrote:
> Hi Wayne, others,
> 
> It has been a while since I have heard anything on here regarding the
> .sweet format for schematic symbols. 
> 
> I remember reading that Wayne was not wanting extra input on this, but
> this was a very long time ago!
> 
> With my current effort to consolidate the libraries before v5 release,
> it has again brought into focus the areas in which the current symbol
> file formats are lacking.
> 
> For reference, the most recent version of the .sweet proposal I have
> been able to find is here -
> https://lists.launchpad.net/kicad-developers/binDp0KdUNMWc.bin (perhaps
> there is a newer one Wayne?)

I have not updated it with the last round of proposals but it will not
be much different.  Once the stable 5 release is out, I will update the
file format doc and open the discussion one last time before I start
working on it.

> 
> Following is a short list of question:
> 
> *1.  Specify multiple functions for a single pin*
> 
> I have asked this before here
> - https://lists.launchpad.net/kicad-developers/msg27071.html - however I
> did not really get much of a response.
> 
> It would be great to be able to assign multiple functions to a given
> pin, and users can select a pin func (drop-down-box) which then enforces
> ERC accordingly)

This was already approved for the new file format and will be included.

> 
> *2. Symbol Variants*
> *
> *
> One of the pressing shortfalls in the current library scheme is that the
> footprint field is common to all aliases. Thus, if a symbol is made for
> e.g. a SOIC-8 there cannot be an alias for a DIP-8 version of the
> symbol. Many components have pin-compatible footprints.
> 
> In this case, is it as simple as doing the following:
> 
> (part "MYPART_DIP-8" inherets "MYPART_SOIC-8"
>   (footprint "DIPS:DIP-8"> )
> 
> That's how I read the specification document. If my reading is correct,
> then I think that's great.

That is exactly how it's supposed to work.  The "inherits" token is very
powerful.

> 
> *3. Token Default Values*
> *
> *
> The spec. doc. does not indicate what default values will be inferred
> from a file that is missing particular tokens. e.g. does a text field
> missing the "visible" tag default to YES or NO?

It implies the text field is visible.  No token, implies not visible.
I'm not opposed to using show/hide.  I would rather a single token than
a token with a state (visible yes/no) which is more verbose with no
improvement in readability.

> 
> Thanks,
> 
> Oliver
> 
> 
> 
> 
> _______________________________________________
> 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
>