kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 01/03/2011 03:59 PM, Wayne Stambaugh wrote:
> On 1/3/2011 3:36 PM, Dick Hollenbeck wrote:
>> On 01/03/2011 01:58 PM, Dick Hollenbeck wrote:
>>> Wayne,
>>>
>>> I just made a commit that fixes some minor issues to a commit I made last
>>> night, and I can now see the inheritance mechanism working really pretty well.
>>>
> Dick,
>
> I've attached the changes I made to the library part file specification last
> night.  I updated all of the coordinates for dimensionless units.  All I did
> was divide all of the coordinates by 50 (mils). 

Beautiful.

>    I added a short blurb about
> logical coordinates. 

"pin cell" is another name that came to mind, again like drawing pins on
graph paper.  Logical coordinates are fine too, but requires more
intellectual energy to understand IMO.

Having more than one way to describe the concept is good, whatever we can
can stack up to convey the concept, and it may require a couple of different
approaches for folks to understand.  Logical coordinates are a fine
approach.  I just wouldn't start there with my Mom.  I would start with
graph paper and the notion of a pin cell, which is the same as what she sees
on the graph paper.



>  I also renamed route_pin_swap and route_alt_swap to
> hint_pin_swap and hint_alt_swap.  I think route is too tool specific.  A
> hinting system that is tool agnostic makes more sense to me.
>
>>> Today is a company holiday I was not aware of, so that gives me another day
>>> to work on this stuff in an active mode.  My normal mode would be more
>>> intermittent, or weekend centric, than what I can spend on it today.
> Always a nice surprise.
>
>>> I will make another commit very late this evening, and then take a less
>>> active role for the remainder of the week, which could give you some time on it.
> I'll start messing around with it tonight as I have some to kill tonight.
>
>>> =================
>>>
>>> Units:
>>>
>>> My thinking is that we do not have units, but if you wanted to name them
>>> they might be:
>>>
>>> "pin intervals", "pin spaces", or "pin deltas", which means of course, the
>>> standard minimum distance between two pins in the new EESCEMA.
>>>
>>> A value of 1 pin delta is what you'd often see in the Sweet strings,
>>> *between* pins, in either X or Y axes.
> I was thinking more in terms of logical units.  All items that are connectible
> (pins, wires, labels, etc.) must have integer units to guarantee connectivity.

Well "must have" may be too strong.  But we agree on the concept.  The only
reason to stray from this is to handle the case where an old part was just
so poorly designed, and it needs to be converted, just to get it into a new
editor environment.   The coordinates may not be on a pin cell boundary.  We
can support fractional pin cells, but don't want to as a rule.

>  All non-connectible items (lines, text, etc.) can have non-integer units as
> well. 

Any can have any.  But on the assumption that everyone wants to conform, and
create a maximally re-useable part, then everything should be on a pin cell
boundary, including text.  We can flash a red box on screen if someone
doesn't want to wear the school uniform.


>  This way it doesn't matter internally what EESchema uses as it's
> coordinate scalar other than making sure you don't overflow or underflow the
> integer.


Yes, the accumulation of Intellectual Property, is in the growing body of
Sweet specs.

This is our goal, and I think it has the potential to transcend Kicad.  If
we do this right, then this thing will be adopted outside Kicad, no
question.  We will take a bow when some part vendor provides a Kicad library
in Sweet form, and puts it up using HTTP_LIB_SOURCE.


Dick