kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 3/25/2011 4:33 PM, Dick Hollenbeck wrote:
> 
>> Agreed.  If memory serves, this change requires moving to an S-expression
>> schematic file format.  I should be able to start working on the new schematic
>> file format in the next week or so.  If there is no objection, I will use the
>> same format as I did for the part file (Sweet) format document.  I'll need your
>> input on embedding the parts into the schematic to provide access to external
>> projects when I get to that point.
>>
>> Wayne
> 
> I am at a loss to name a better format, even though this one (*.odt) comes
> with the disadvantage that it does not "diff" at all.
> 
> Docbook or something like it would not be unreasonable, but I don't think it
> is as easy to work with as OpenOffice/Libre.  Ease of working with it trumps
> lack of diff, by a wide margin.

If I had the spare time to learn Docbook might be more inclined to use
it.  For now, ODT will have to do given my time constraints.

> 
> Thanks for your help.
> 
> 
> There are several tricky parts to the new schematic format:
> 
> 1) sheets
> 
> which have been separate, are now combined into one big ass file.  To be
> able to support the sheet instantiation concept, which we have now where the
> same sheet can be embedded more than once in a schematic, we could need to
> do something like what is done in verilog, where you have an external
> interface to a sheet.  We need something like describe the external
> interface of a sheet, and then there are instantiations with specific
> bindings for each instance.  This is not too dissimilar to the new pin
> signals, which get bound to nets, for each instantiated part.  But I think
> we already have a term for this: pin sheets, or something like that, which
> are two words that seem backwards to me.

The current class name is SCH_SHEET_PIN.  I cleaned up the old pin sheet
class naming and comments which were confusing.  There may still be some
references in the comments and some of the UI stings that use sheet pin
that I missed.  If I run across any, I'll update them to sheet pin.

> 
> In summary, there are sheet declarations, and sheet instantiations.

I think the sheet instantiations will be doable similar to the way
schematic components are instantiations of a library component in the
current design.  Hopefully we can come up with an elegant format that
leads to a cleaner code implementation.

> 
> 
> 2) parts list
> 
> This needs to be up front near the beginning of the schematic file.  It
> needs to be early so we can load it quickly from the PARTS_LIST_LIB_SOURCE
> class for re-use on other projects.  It also needs to have enough fields in
> it to achieve a spreadsheet UI.  This means the properties in here "trump"
> any properties which may come in as part of the parts which are nested
> within the parts list.  This is because all parts in the parts list have the
> same properties, and those properties are established by the spreadsheet
> UI.  A spreadsheet row is part, a spreadsheet column is a property. 
> Spreadsheet values at each cell position represent a property on a given
> part, and this needs to go into the file, bound to the part within the
> parts_list within the file.

Since you obviously have some concrete ideas how you want to implement
this, I'll just leave a place holder in the document for you to document
the parts list.

> 
> 
> 
> 3) components
> 
> These can supply property text "effects", but not properties per se, other
> than reference designator, instantiated part name, position/orientation, and
> stuff.  Storing components in the file should be easy.
> 
> Finding old emails could be helpful also, since this has all been mentioned
> before in old emails.
> 
> 
> -------------------------
> 
> When it comes to coding, we should be careful not to allow the schematic
> editor to go beyond the bounds of the public Sweet API.  This should be
> possible to enforce by keeping the sweet stuff as a separate DLL.

Agreed, the schematic parser should not do any parsing of it's own
internal parts list.  It should hand that off to the Sweet parser and
access the parts through the public Sweet API just like it would access
parts from an external library.

Things should certainly get interesting once we start merging all this
into EESchema.

Wayne

> 
> 
> Again, thanks for your help.
> 
> Dick
> 
> 
> 
> _______________________________________________
> 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
>