This post kind of blew out a bit - TLDR version - I have a database
idea that may be helpful in the pin swapping under discussion. The
database would provide a device representation that captures
*everything*. The database would help inform the pin swapping decision
process rather th
> Otherwise my head starts to twirl in confusion over how to support
> it or maintain the tool that does it.
True. Please re-read my pin mapping doc, and see if your swirling
head can come up with a solution ;-)
http://www.delorie.com/pcb/pin-mapping.html
Maybe the solution for FPGAs and the l
On 05/24/2011 07:22 AM, DJ Delorie wrote:
if it's layout-specific data, the copy in the layout is correct.
Perhaps we need to keep track of whether the data in the layout and
schematic originated in that file, or is the result of user changes
elsewhere being imported.
But any solution depends on
David C. Kerber wrote:
> The easy answer to this is to do what Cisco does with their ASDM
> software: you can set an option that tells it to present to the
> user the exact text of every command it is sending to the router.
I have seen some CAD suites do this. IIRC, these were MicroStation,
va
> The easy answer to this is to do what Cisco does with their ASDM
> software: you can set an option that tells it to present to the user
> the exact text of every command it is sending to the router.
PCB is close to this - many of the things it does already go through
the action (scripting) laye
> -Original Message-
> From: geda-user-boun...@moria.seul.org
> [mailto:geda-user-boun...@moria.seul.org] On Behalf Of John Doty
> Sent: Tuesday, May 24, 2011 3:05 PM
> To: gEDA user mailing list
> Subject: Re: gEDA-user: Solving the light/heavy symbol problem
>
On May 24, 2011, at 10:30 PM, Peter Clifton wrote:
> the fact that actions are made from
> shell script fragments is somewhat irrelevant.
I think it's highly relevant, because it means that anyone familiar with shell
commands has a head start understanding what's going on.
John Doty
On May 25, 2011, at 5:58 AM, DJ Delorie wrote:
>
> I think what a GUI does is no different than what Make does - it lets
> you encapsulate complex operations into simpler ones. When a user
> clicks on "run simulation", they don't care how many steps it takes to
> do that, they just want their s
On May 24, 2011, at 9:37 PM, DJ Delorie wrote:
> I did think about where the *metadata* would come from, and some API
> to hide all that behind. I'm waffling between something like HTTP/CGI
> (automatic integration with any web server) or SQL (powerful query
> language)
I think if we continue t
I think what a GUI does is no different than what Make does - it lets
you encapsulate complex operations into simpler ones. When a user
clicks on "run simulation", they don't care how many steps it takes to
do that, they just want their simulation. When you run "make sim" to
run your simulation,
> What about packages with duplicate pins, e.g. both 2 and 4 are drain?
PCB already handles this by just treating them as one pin with two
copper bits, but you could use D1/D2 if you wanted to make them
separate.
But I did cover this in my pin mapping doc:
Here's the 8-SOIC case, showing how
On May 24, 2011, at 9:43 PM, DJ Delorie wrote:
> My flows are also heavily scripted, so yes, I'll remember. The
> underlying data and low-level tools follow the scripting paradigm -
> stepwise progress from A to Z via simple apps that interact with
> simple data. The GUI needs to *hide* that, n
On May 24, 2011, at 9:37 PM, DJ Delorie wrote:
> I had proposed using the pin *label* as the identifier, not the
> pin *number*. The label is "owned" by the schematic, but the number
> is "owned" by the partdb or layout. That lets you, for example,
> change the package in layout without having
Lot of good discussion here. Keep it up.
I work in the asic/fpga arena and I am building a tool flow based on
the ip-xact standard (IEEE-1685). It has a lot in it that solves many
of the problems in this discussion and I would suggest that gEDA might
want to borrow a few tips from t
What I think users want is to have the underlying tools be more aware
of the other sources of data in the design, and each other, so that
the GUIs appear to be more integrated despite being individual tools
and datasets underneath. This may require some high-level "these are
the files in your d
On Tue, 2011-05-24 at 16:56 +0900, John Doty wrote:
> Well, the classic TLP is "make", and gEDA works pretty well with it.
> Of course, "make" is old-fashioned and rather crude. It's easy to
> create something prettier, but it's very hard to create something that
> works better.
"make" is a cleve
On Tue, 2011-05-24 at 15:24 +0900, John Doty wrote:
> On May 24, 2011, at 2:43 PM, DJ Delorie wrote:
> I also use pins2gsch a lot for connector maps: maintaining connectors
> as drawings is a pain, and not very illuminating, I think. In this
> case, the master is the .tsv that defines the map, not
> Please remember that what interacts with the data may not be a human
> "user", but a script. The user behind the script must find the the
> organization sufficiently comprehensible that the script can be
> constructed to penetrate it without human help. This is exactly why
> GUI so commonly pois
> Pin numbers are a bit harder than most other attributes in the
> present state of gnetlist, because the front end employs pin numbers
> internally to track pin identity.
Yup. I had proposed using the pin *label* as the identifier, not the
pin *number*. The label is "owned" by the schematic, b
> It is not just "us". it is the traditional way to look at an
> electronics project. Schematic, layout and BOM contain all the
> information needed to reproduce.
We currently derive the BOM from other sources (well, from the
schematics). PCB can derive its own BOM as well.
The metadata idea
> I really don't want any *major* changes to the core workflow and UI TBH.
Understood.
> The changes that would make this a more complete tool (for me anyway) are:
Yup, all discussed before. One impossible task at a time please :-)
> (can you even edit text from the gui once placed?)
the 'n'
On May 24, 2011, at 4:31 PM, myken wrote:
>
>> How we organize the data, and how the user interacts with it, need not
>> be the same :-)
> I didn't read the complete threat so if I miss the point or if I repeat
> anyone I'm sorry.
>
> Is it not possible to make a top level program that launche
On May 24, 2011, at 3:33 PM, DJ Delorie wrote:
> How we organize the data, and how the user interacts with it, need not
> be the same :-)
Please remember that what interacts with the data may not be a human "user",
but a script. The user behind the script must find the the organization
suffici
On May 24, 2011, at 2:43 PM, DJ Delorie wrote:
>
> Up to now, we've been using the schematic as the "master" files for
> the design. Perhaps this is a bad idiom? Perhaps "the design" should
> be some other data, which uses the schematic as but one of its inputs?
If you have a hierarchical des
On May 24, 2011, at 2:29 PM, DJ Delorie wrote:
>
>> I'd like to note that we have a serious power tool in gnetlist,
>
> Yup. I had hoped to move some of the "heavyifying" data into a
> database or the layout (or whatever), and have gnetlist gather all the
> attribute data from the schematic, t
DJ Delorie wrote:
> Up to now, we've been using the schematic as the "master" files for
> the design. Perhaps this is a bad idiom?
It is not just "us". it is the traditional way to look at an
electronics project. Schematic, layout and BOM contain all the
information needed to reproduce. Of cou
I really don't want any *major* changes to the core workflow and UI
TBH.
The changes that would make this a more complete tool (for me anyway)
are:
PCB:
- better control over polygons. Ie better awareness/ability to tie to
nets, built in crosshatching (intstead of solid), and a
> Is it not possible to make a top level program that launches the
> different programs (gschem, pcb, simtools, .)?
Yes. In fact, this has been done. However, it serves to collect the
various files that make up a design, not the information *in* the
design. The underlying tools still deal
How we organize the data, and how the user interacts with it, need not
be the same :-)
I didn't read the complete threat so if I miss the point or if I repeat
anyone I'm sorry.
Is it not possible to make a top level program that launches the
different programs (gschem, pcb, simtools, .)?
> Maybe in the backend it is a bad idiom (that is, gschem should be
> saving the schematic and "design" as separate beasts, maybe in a
> gzipped collection or something). But from the user's perspective it
> makes sense.
How we organize the data, and how the user interacts with it, need not
be th
On Tue, May 24, 2011 at 01:43:08AM -0400, DJ Delorie wrote:
>
> > Hierarchy isn't the only reuse scenario. Consider transition from
> > breadboard to prototype to production. A top-level schematic might
> > not change, even though attributes of parts might change (different
> > packages, tighter s
> Hierarchy isn't the only reuse scenario. Consider transition from
> breadboard to prototype to production. A top-level schematic might
> not change, even though attributes of parts might change (different
> packages, tighter specs, ...). In that case, the instance-specific
> data can't be in *an
> I'd like to note that we have a serious power tool in gnetlist,
Yup. I had hoped to move some of the "heavyifying" data into a
database or the layout (or whatever), and have gnetlist gather all the
attribute data from the schematic, the database, and the layout. It
can then combine the data i
On May 23, 2011, at 1:40 PM, DJ Delorie wrote:
> In a heirarchy, only the "higher" level schematics know what
> the heirarchy is, the sub-schematics don't, so the higher ones need to
> retain the instance-specific data.
Hierarchy isn't the only reuse scenario. Consider transition from breadboard
I'd like to note that we have a serious power tool in gnetlist, and it's not
too hard to get it to translate attributes. Here's an example:
gnetplug-metadata.scm
Description: Binary data
project_metadata.scm
Description: Binary data
metademo.sch
Description: Binary data
Usage:
gnetlist -
On 05/22/2011 11:40 PM, DJ Delorie wrote:
And if you gate-swap between packages, you then need to know which two
subcircuits get their gates swapped.
That might become an instance label like:
I1.1 for slot 1
I1.2 for slot 2
And since I don't use heirarchy, I can only assume it's even more
> Yes, any annotation to just one instance of a package in a layout
> would back annotate to an instance attrib attached to a symbol
> instance in a schematic,
Or to an instance attrib on the *parent* schematic, that says "when
you descend here, use these attributes"
IMHO this goes back to my ob
On 05/22/2011 10:02 PM, DJ Delorie wrote:
Only if you view the *.sch by
navigating the heirarchy could gschem even hope to juggle all the
annotations enough to show you the "as-built".
Yes, any annotation to just one instance of a package in a layout
would back annotate to an instance attrib at
> But a database of packets might look different from a database
> that does the assignment of footprints, data sheets and meta
> data by some other means.
Yes, but that's for the "how do we do it" phase. At this point, if we
can agree that "hiearchical storage is good" and that we'd like to be
DJ Delorie wrote:
>> These would be data structures that can contain all information
>> relevant to an entity us humans like to build electronics from.
>
> I don't think this conflicts with any of the other ideas we've
> proposed.
I don't think so, too. :-)
But a database of packets might look
Hi Everyone,
I'm a new gEDA user and someone who's just learning electronics design
and basically everything that comes with it. I started using Eagle
(since that's what most people in the Arduino community use), but the
limitations of the free/non-profit versions + the cost of moving to a
profes
> I like adding the meta-data to a separate file, even if it
> associated with a footprint first. For example: SOIC-8.fp along with
> SOIC-8.fp.meta, which contains attribs
> symbolname="FET_dual_11234.sym" footprintname="SOIC-8.fp" could be
> created first, and a symbol for FET_dual_11234.sym def
On 05/20/2011 04:09 PM, DJ Delorie wrote:
hmmm... think about how a simplehttp:// changed the way we share
information across the Internet. Think of how Facebook changed the
way people manage their social lives. Are we prepared to put the
effort into making something of*that* scale, for EDA?
On Sat, May 21, 2011 at 09:19:21AM -0400, Bob Paddock wrote:
> On Sat, May 21, 2011 at 9:09 AM, Kai-Martin Knaak wrote:
> > My proposal to tackle many of the library related issues is the notion
> > of packages. These would be data structures that can contain all information
> > relevant to an ent
> Talk is cheap, but buy-in is very expensive.
And, of course, I expect those who are contributing to the "talk" part
to buy-in to actually *doing* their part of it, too.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/
> We have been in the "what do we want to do" phase for many many years.
> Talk is cheap.
Agreed, but we still need to get everyone on the same page, or at
least in the same book, so we can actually *do* it this time, and stop
rehashing the same old problems.
Talk is cheap, but buy-in is very ex
[snip]
>I think we're still in the "what do we want to do" phase :-)
We have been in the "what do we want to do" phase for many many years.
Talk is cheap.
-Ales
"less talk, more code"
___
geda-user mailing list
geda-user@moria.seul.org
http://www.se
> It would be great if you could now implement this approach as a
> prototype for everybody to evaluate.
I think we're still in the "what do we want to do" phase :-)
Some time this weekend, I'll re-read the thread and see which ideas we
seem to have come to a consensus on, and see what if any pa
> These would be data structures that can contain all information
> relevant to an entity us humans like to build electronics from.
I don't think this conflicts with any of the other ideas we've
proposed. It's almost like each component would be a micro-library of
its own.
> Note, the plural. S
Kai-Martin Knaak,
[snip]
> My proposal to tackle many of the library related issues is the notion
> of packages.
Great, thank you for posting these details. You seem to have an approach
on how to fix the library issues. It would be great if you could now
implement this approach as a prototype
On Sat, May 21, 2011 at 9:09 AM, Kai-Martin Knaak wrote:
> My proposal to tackle many of the library related issues is the notion
> of packages. These would be data structures that can contain all information
> relevant to an entity us humans like to build electronics from. Specifically,
> they ma
Cullen Newsom wrote:
> Couldn't you consider
> maintaining some backwards-compatibility by having the metadata file simply
> contain references to the symbol files (plus other garbage, spice, kitchen
> sinks, etc), and footprint files? That should only require a minimal effort
> on the part of gSc
DJ Delorie wrote:
> IIRC there are a few proposals and/or active solutions in play:
>
> * Standard library is light, users heavyify them (we need a better
> verb for that ;) into a project-specific (or even site-global) heavy
> symbol library.
>
> * Standard library is heavy, users either us
> > However, we could collect stats
> > about things downloaded from, say, gedasymbols. Perhaps we could have
> > a small number of "starter" libraries on gedasymbols, and the geda
> > installer prompts you to pick one to download. We track how many
> > downloads of each, and use that to decide
On Fri, 20 May 2011 22:37:58 -0400
DJ Delorie wrote:
>
> > > Ok, then how do we generate the thousands, if not millions, of symbols
> > > we'll need?
> >
> > I've been thinking about that, and to be blunt, I have no frickin'
> > clue. ;-)
> >
> > Maybe some clever scripting against a set of
> I'm hoping for "a better way for them to do the work" or even, "machine
> does most of the work" Teach them to fish and all that.
Teach them to fish, yes, but make them figure out how to make a
fishing pole from scratch? *I* might like that, but most users
wouldn't.
Hence the "it should be e
> > Ok, then how do we generate the thousands, if not millions, of symbols
> > we'll need?
>
> I've been thinking about that, and to be blunt, I have no frickin'
> clue. ;-)
>
> Maybe some clever scripting against a set of "generic" parts
> (similar to what I did with those footprints I just s
Metadata can be a parallel task.
In gschem you pick your resistor.
You have two buttons, place lite, place heavy. Place heavy brings up a second
wizard to populate the heavy symbol, probably from your database.
Then place your symbol.
In pcb, when you import a schematic.
Any parts without
> Couldn't you consider maintaining some backwards-compatibility by
> having the metadata file simply contain references to the symbol
> files (plus other garbage, spice, kitchen sinks, etc), and footprint
> files? That should only require a minimal effort on the part of
> gSchem to read the new m
On Fri, May 20, 2011 at 4:09 PM, DJ Delorie <[1]d...@delorie.com> wrote:
> I would love an easier way to generate footprints.
Now that we're pre-parsing all the M4 footprints anyway, perhaps we
could allow for a range of scripting options in the Makefiles that
generate the li
On Fri, 20 May 2011 16:54:20 -0400
DJ Delorie wrote:
>
> > I say go with this - because users already have to modify nearly all
> > the symbols they use in a schematic when using the existing library.
> > This way, most of the symbols will have default footprints and other
> > attributes that wi
Chris Malton wrote:
> On 20/05/11 17:01, DJ Delorie wrote:
>> * Standard library is light, users heavyify them (we need a better
>>verb for that ;) into a project-specific (or even site-global) heavy
>>symbol library.
> Personally, I'd say that this is a sensible way to go.
>
This is the w
On Fri, May 20, 2011 at 4:14 PM, DJ Delorie <[1]d...@delorie.com> wrote:
> Yes users must be able to add metadata, ie: company internal part
> numbers, document numbers, etc.
Do they add meta-data to the symbol, the footprint, or store it
elsewhere?
Well, as an example, I i
> It would let us ship, say, a sqlite database with a bunch
or OOo spreadsheet, or CSV text file, or even a web server CGI.
See also: http://www.gedasymbols.org/csv.html
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/
On Fri, May 20, 2011 at 12:01:59PM -0400, DJ Delorie wrote:
>
> My own proposal (posted in the past) is here:
>
>http://www.delorie.com/pcb/component-dbs.html
>
I like this idea a lot. Allowing pcb and gschem to use different
(multiple) databases with different backends gives us a lot of
fre
On 20/05/11 17:01, DJ Delorie wrote:
* Standard library is light, users heavyify them (we need a better
verb for that ;) into a project-specific (or even site-global) heavy
symbol library.
Personally, I'd say that this is a sensible way to go.
I'd then suggest having an extra set of optio
I'm have no a lot of expirience in PCB creation, so may be I don't know
something, but I have following suggestions:
Just now my workflow is the next:
1. I draw scheme in gschem.
2. I run gsch2pcb and look for errors like this:
WARNING: C5 has no footprint attribute so won't be in
> Yes users must be able to add metadata, ie: company internal part
> numbers, document numbers, etc.
Do they add meta-data to the symbol, the footprint, or store it
elsewhere?
We *do* have the option of changing our symbol-footprint library into
a symbol-metadata-footprint scheme. Maybe gnetli
> I would love an easier way to generate footprints.
Now that we're pre-parsing all the M4 footprints anyway, perhaps we
could allow for a range of scripting options in the Makefiles that
generate the library? There have been a few footprint-specific
languages developed over the years.
> > In a
And consider that, no matter how heavy a symbol is, you can always
make it heavier. Let's say we ship a symbol for a 4.7k 0603
resistor.
Does it include manufacter's part numbers? Vendor name? Tolerance?
These are additional data the user could add. Where does it come
> I say go with this - because users already have to modify nearly all
> the symbols they use in a schematic when using the existing library.
> This way, most of the symbols will have default footprints and other
> attributes that will do just fine.
Ok, then how do we generate the thousands, if n
Oh boy am I glad y'all are having this conversation, and I hope you
don't mind some comments from the peanut gallery.
On Fri, May 20, 2011 at 11:01 AM, DJ Delorie <[1]d...@delorie.com> wrote:
[Subject changed to start new thread]
> When I first read geda documentation, there we
On Fri, 20 May 2011 12:01:59 -0400
DJ Delorie wrote:
> [Subject changed to start new thread]
>
> [...]
>
> > When I first read geda documentation, there were already references
> > that this had been discussed ad nauseam.
> > If the default lib is to be changed now, then there should be some ki
[Subject changed to start new thread]
> When I first read geda documentation, there were already references
> that this had been discussed ad nauseam.
Sigh, yes. It's not an easy problem to solve, and I would consider
any solution a "major effort" because it touches everything from
gschem to pc
74 matches
Mail list logo
