Re: gEDA-user: Power (and other non-graphical) pins

[John Doty <jpd@xxxxxxxxx>]

On Jan 12, 2009, at 2:36 PM, Joerg wrote:

> John Doty wrote:
>> On Jan 12, 2009, at 1:50 PM, Joerg wrote:
>>
>>> John Doty wrote:
>>>> On Jan 12, 2009, at 12:36 PM, Joerg wrote:
>>>>
>>>>> When you place the first instantation it'll be pins 1,2,3, the  
>>>>> next
>>>>> one
>>>>> 5,6,7 and so on. But all are supplied via the common supply pins
>>>>> 4 and
>>>>> 11. In gschem you only have two choices. Either you create a  
>>>>> library
>>>>> model that repeats those pins 4 and 11 visibly for all four
>>>>> instantations or you create the library part with the power pins
>>>>> detached where none of the instantations show power pins. This
>>>>> can be
>>>>> practical for auto-connecting digital stuff to a VCC rail but it
>>>>> doesn't
>>>>> work well in the analog world. Now you could also have pins 11 and
>>>>> 4 as
>>>>> a separate "fifth" device. Anyhow, neither method looks
>>>>> professional,
>>>>> neither is industry practice, and all make schematics more
>>>>> difficult to
>>>>> understand for others. Especially for non-analog guys.
>>>> Joerg,
>>>>
>>>> What do you think of the approach in:
>>>>
>>>> http://archives.seul.org/geda/dev/Nov-2008/msg00069.html
>>>>
>>> Thanks, but it says "useless with gschem", whatever that means.
>>
>> It means you're just supposed to netlist it, not look at it.
>>
>>> In the
>>> telephone.sch file I could only see a mike and a speaker with coil,
>>> but
>>> no power pins.
>>
>> Where did you expect to see the power pins? You don't want them on
>> the main symbol, but you also don't want them on a separate symbol.
>> This approach puts them in a text file, and gives you a way to merge
>> such files into the net list.
>>
>> You've told us what you don't want. That doesn't tell us what you  
>> want.
>>
>
> Ok, here's what I (and lots of other) would like:
>
> Take a device with multiple parts in there such as the 74HC14 and  
> handle
> it like Eagle and Orcad do: None of them has power symbols. Then if  
> you
> must connect it to some special power net you can "invoke" the power
> symbols along with correct pin numbers on only the first instantation.
> So U1A then has power symbols but U1B, U1C and so forth don't. The  
> power
> pins absolutely must show up in the schematic where you want them and
> not show up at the instantation where you don't want them.

Sounds miserably complex and inflexible. While with gEDA, you break  
the physical device up however you choose, into as many symbols as  
you want, and there's nothing magical about power pins.

> If they only
> show up in the netlist that doesn't work because the schematic will be
> hard to understand.

The pinlists for power and connectors show up in the documentation. I  
think that's *easier* to understand than graphics.

>
>
>>> In the end it's important that a decent power pin handling is
>>> inside the
>>> program itself,
>>
>> Why?
>>
>
> Because IMHO it's basic schematic capture functionality, used all the
> time.

Yes, and I do it all the time. But I use the toolkit's flexibility  
rather than fighting against it.

> It's not something that is rarely used and where a patch file may
> work.
>
>
>>> not something that must be handled by letting a command
>>> line routine run over some files.
>>
>> Monolithic programs are inflexible. gEDA's strength is radical
>> flexibility.
>>
>
> Well, true, but having to remember which patch files must be run to
> massage a certain schematic and which don't is a serious source of  
> error
> for the user.

My memory is a makefile ;-). These are no more "patches" than the C  
compiler is. The "source" to a design should be the cleanest  
representation: sometimes that's graphical, sometimes that's text.  
gEDA's modularity and flexibility make it easy to script the whole  
process of assembling the design documents from a variety of sources.

> Radical flexibility can be achieved differently. For
> example, Eagle has tons of scripts that can be run from within the
> application, you never need to leave it to call up the command line.

In other words, you can't leverage the power of all of the tools that  
are *outside* Eagle. But you can script gEDA internally, too, in Scheme.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user