On Wed, 01 Jul 2009 00:22:08 -0400, evan foss wrote:
>> And then offer a GUI to select from the list of footprints within
>> gschem.
>
> It would be so cool if you could call pcb to render the footprint in a
> little window as a part of that GUI. This might make dependencies a mess
> though.
It
On Tue, Jun 30, 2009 at 2:54 AM, Stephan
Boettcher wrote:
>
> Steven Michalske writes:
>
>> pick a small set of some chips you care about. lets say a large
>> family of the AVR series.
>>
>> To the symbol:
>> Add a virtual pin attribute
>> Add the pin map file attribute.
>
>> pinmap=A
Steven Michalske writes:
> pick a small set of some chips you care about. lets say a large
> family of the AVR series.
>
> To the symbol:
> Add a virtual pin attribute
> Add the pin map file attribute.
> pinmap=ATmega16.fpm
> device=ATmega16
> footprint=TQFP44_10
> {
And then o
Hi Michael,
On Mon, 2009-06-29 at 06:23 +, Michael Sokolov wrote:
> Bert Timmerman wrote:
>
> > got cvs co working
> > Simply typing make barfs the following:
> > [snipped]
>
>
> Your OS is too modern. Install something that is at least 25 years
> obsolete and try again.
>
>
> Seriously
Dan McMahill wrote:
>
> for things like transistors and IC's, I have already implemented exactly
> this for my own use. I have an ASCII file that associates a complete
> vendor part number (including package code) with a symbol template, a
> footprint, and a mapping from symbol pin to footprint
On Sun, Jun 28, 2009 at 9:46 PM, Dan McMahill <[1]...@mcmahill.net>
wrote:
For transistors and IC's, I have no problems with the "enumerate
them
all" approach I've taken.
This is what I been doing too. All semiconductors are enumerated.
Since
all of the graphics are
Bert Timmerman wrote:
> got cvs co working
> Simply typing make barfs the following:
> [snipped]
Your OS is too modern. Install something that is at least 25 years
obsolete and try again.
Seriously though, Ineiev has already told me that ultra-modern versions
of gcc refuse to compile uEDA as
Hi Michael,
On Mon, 2009-06-29 at 05:44 +, Michael Sokolov wrote:
> Bert Timmerman wrote:
>
> > > cvs -d anon...@ifctfvax.harhan.org:/fs1/IFCTF-cvs co ueda
> >
> > [...]
> >
> > copy-pasting the cvs command to a Bourne shell on my workstation gives
> > that a password other than is required
Bert Timmerman wrote:
> > cvs -d anon...@ifctfvax.harhan.org:/fs1/IFCTF-cvs co ueda
>
> [...]
>
> copy-pasting the cvs command to a Bourne shell on my workstation gives
> that a password other than is required.
Oops, forgot the :pserver: part; try the following:
cvs -d :pserver:anon...@ifctfva
Hi Michael,
On Mon, 2009-06-29 at 03:20 +, Michael Sokolov wrote:
> Bill Gatliff wrote:
>
> Is someone reimplementing uEDA here? How about the other way around?
> Anyone feel like porting the gschem GUI to operate on the uschem file
> format? That's the only remaining piece that's missing
Bill Gatliff wrote:
> At the risk of going OT, I'll add that as I get better at following the
> above strategy--- which is particularly helpful with more complex parts
> like microcontrollers--- I get really frustrated at gschem's strong
> association between pin numbers on the symbol, and pin nu
Bill Gatliff wrote:
> At the risk of going OT, I'll add that as I get better at following the
> above strategy--- which is particularly helpful with more complex parts
> like microcontrollers--- I get really frustrated at gschem's strong
> association between pin numbers on the symbol, and pin numb
John Doty wrote:
> Why are you hung up on the form the container of the information
> takes? If the symbol file contains the same graphics, isn't that the
> same symbol from a graphical point of view? Why do you consider it
> different?
>
I guess it's because I'm a control freak. :) I w
On Jun 28, 2009, at 3:11 PM, Stefan Salewski wrote:
> Currently we (may) have different symbol files for the the same device
> with different footprints.
Not a lot, I think. It's easier to find examples of the same device
with different graphics.
> So we have the same graphics elements
> mult
On Jun 28, 2009, at 3:23 PM, Bill Gatliff wrote:
> Stefan Salewski wrote:
>>
>> Currently we (may) have different symbol files for the the same
>> device
>> with different footprints. So we have the same graphics elements
>> multiple times. This is redundancy, wast of storage area, and it
>>
On Jun 28, 2009, at 3:36 PM, Steven Michalske wrote:
>
> On Jun 28, 2009, at 2:58 PM, John Doty wrote:
>
>>
>> On Jun 28, 2009, at 2:43 PM, Steven Michalske wrote:
>>
>>> The power of text based file formats :-)
>>
>> The way I do connectors these days is that I have a "connector"
>> symbol that'
On Jun 28, 2009, at 2:58 PM, John Doty wrote:
>
> On Jun 28, 2009, at 2:43 PM, Steven Michalske wrote:
>
>> The power of text based file formats :-)
>
> The way I do connectors these days is that I have a "connector"
> symbol that's just a box with refes=, device=, and footprint=. I'll
> place th
Stefan Salewski wrote:
>
> Currently we (may) have different symbol files for the the same device
> with different footprints. So we have the same graphics elements
> multiple times. This is redundancy, wast of storage area, and it makes
> it more work to modify the graphics. So it is not a perfect
On Jun 28, 2009, at 3:00 PM, Steven Michalske wrote:
> This is an age old debate in EDA software. Where is the symbol weight
> stored? In each symbol, or in a database.
> ( Note when I say database, it can be a flat file or full blown
> relational SQL )
>
> The Heavy vs. Light symbol debate.
On Sun, 2009-06-28 at 15:38 -0600, John Doty wrote:
> > How many NAND symbols do we need? Right now, it's one for each
> > different footprint that the symbol relates to. I think that's
> > unacceptable.
>
> How does your plan differ, except by making the process more
> complicated? You have
On Jun 28, 2009, at 2:53 PM, Bill Gatliff wrote:
> John Doty wrote:
>>
>> How does your plan differ, except by making the process more
>> complicated? You have to put the information *somewhere*. For maximum
>> ease and flexibility, put it in your project's copy of the relevant
>> symbol. You don
This is an age old debate in EDA software. Where is the symbol weight
stored? In each symbol, or in a database.
( Note when I say database, it can be a flat file or full blown
relational SQL )
The Heavy vs. Light symbol debate. both answers are correct. let's
build infrastructure for bo
On Jun 28, 2009, at 2:43 PM, Steven Michalske wrote:
> The power of text based file formats :-)
The way I do connectors these days is that I have a "connector"
symbol that's just a box with refes=, device=, and footprint=. I'll
place that and draw a bus to it. Make the appropriate connection
John Doty wrote:
>
> How does your plan differ, except by making the process more
> complicated? You have to put the information *somewhere*. For maximum
> ease and flexibility, put it in your project's copy of the relevant
> symbol. You don't need to implement or learn *any* additional
> c
On Jun 28, 2009, at 2:30 PM, Bill Gatliff wrote:
> Steven Michalske wrote:
>>
>> Taking this as you can code some scripts up..
>> Here is one approach for you to try.
>>
>>
>>
> Aah, I hadn't even considered that possibility--- do it outside of
> gEDA
> instead of within it... D'oh! :)
T
On Jun 28, 2009, at 3:24 PM, Bill Gatliff wrote:
> John Doty wrote:
>>
>> Repeat after me:
>>
>> "There are very few symbols distributed with gEDA that are perfectly
>> suited to my project and my design flow."
>>
>
> Agreed!
>
>> I understand you want to patch over this somehow.
>
> Not so much
Steven Michalske wrote:
>
> Taking this as you can code some scripts up..
> Here is one approach for you to try.
>
>
>
Aah, I hadn't even considered that possibility--- do it outside of gEDA
instead of within it... D'oh! :)
> Now with this groundwork you can run a script that will update
On Jun 28, 2009, at 10:26 AM, Bill Gatliff wrote:
> As a "mostly software" guy,
Taking this as you can code some scripts up..
Here is one approach for you to try.
pick a small set of some chips you care about. lets say a large
family of the AVR series.
To the symbol:
Add a vir
John Doty wrote:
>
> Repeat after me:
>
> "There are very few symbols distributed with gEDA that are perfectly
> suited to my project and my design flow."
>
Agreed!
> I understand you want to patch over this somehow.
Not so much "patch over" as to prevent duplication of work by every gEDA
u
On Jun 28, 2009, at 2:59 PM, Bill Gatliff wrote:
> Dave N6NZ wrote:
>>
>> Agreed. I've felt that way since the beginning -- for the same
>> reason
>> that you mentioned: changing package. For me, it's pretty
>> annoying to
>> have to replace the schematic symbol to go from through-hole to
On Jun 28, 2009, at 2:49 PM, Bill Gatliff wrote:
> John Doty wrote:
>> When first drawing the circuit that needs a low noise opamp, copy one
>> of the opamp symbol files into your project symbol directory under
>> the name "low_noise_opamp.sym". Place that. As its pin numbers,
>> attributes, etc.
Dave N6NZ wrote:
>
> Agreed. I've felt that way since the beginning -- for the same reason
> that you mentioned: changing package. For me, it's pretty annoying to
> have to replace the schematic symbol to go from through-hole to surface
> mount just because the pin numbers are different.
>
>
John Doty wrote:
> When first drawing the circuit that needs a low noise opamp, copy one
> of the opamp symbol files into your project symbol directory under
> the name "low_noise_opamp.sym". Place that. As its pin numbers,
> attributes, etc. become clear, edit it ("Hs") to suit. Or replace t
John Doty wrote:
> On Jun 28, 2009, at 11:26 AM, Bill Gatliff wrote:
>
>
>> At the risk of going OT, I'll add that as I get better at following
>> the
>> above strategy--- which is particularly helpful with more complex
>> parts
>> like microcontrollers--- I get really frustrated at gschem's
On Jun 28, 2009, at 11:26 AM, Bill Gatliff wrote:
> At the risk of going OT, I'll add that as I get better at following
> the
> above strategy--- which is particularly helpful with more complex
> parts
> like microcontrollers--- I get really frustrated at gschem's strong
> association between
Dave N6NZ wrote:
> Bill Gatliff wrote:
>
>> Dave N6NZ wrote:
>>
>>
>>> I believe this style leads to the most readable schematics, and scales
>>> up well to larger designs.
>>>
>>>
>> Agreed. At least until you do like me, and forget to put down the power
>> symbol once (or twic
Bill Gatliff wrote:
> Dave N6NZ wrote:
>
>> I believe this style leads to the most readable schematics, and scales
>> up well to larger designs.
>>
>
> Agreed. At least until you do like me, and forget to put down the power
> symbol once (or twice). :)
Well, the netlist checker or some oth
Larry Doolittle wrote:
>
> I basically agree with the argument. The final trick that would
> make a larger audience happy is the ability to back-annotate
> the schematic with the physical pins -- and presumably a switch
> for whether to display the physical or virtual pin IDs -- so that
> the engi
Bill -
On Sun, Jun 28, 2009 at 12:26:10PM -0500, Bill Gatliff wrote:
> [greatly trimmed]
> It would be nice if there was an
> additional "layer of abstraction" somewhere between the symbol and
> footprint, such that actual pin assignments weren't made until the
> footprint (and slot, if necessary)
Dave N6NZ wrote:
> I believe this style leads to the most readable schematics, and scales
> up well to larger designs.
>
Agreed. At least until you do like me, and forget to put down the power
symbol once (or twice). :)
At the risk of going OT, I'll add that as I get better at following th
40 matches
Mail list logo