On 05/22/2011 12:33 AM, DJ Delorie wrote:
I like the idea of creating a library group containing all info related
> to a manufactured part or part range.
Library group? Or just a library? (not picking on the name, just
wondering what you think the difference is, or why such a difference
might
> I like the idea of creating a library group containing all info related
> to a manufactured part or part range.
Library group? Or just a library? (not picking on the name, just
wondering what you think the difference is, or why such a difference
might be needed)
Do we need to be able to grou
On 05/21/2011 08:09 AM, Kai-Martin Knaak wrote:
The notion of packages can be seen as a means to isolate dependencies.
Pins in symbols must match pins in footprints. Simulation models are
specific to components. Packages provide a way to keep comments, notes
and all kinds of meta data attached.
On Sat, 21 May 2011 23:23:29 +0200
Kai-Martin Knaak wrote:
> Vanessa Ezekowitz wrote:
>
> > You mean, like THIS? (see attachment)
>
> Ok, this is _all_ permutations of certain three letter combos. May be
> a little bit over the top for general distribution. Many combinations
> do not correspond
> 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
> In the context of packages, the package might indicate, which slot
> to use. As with all attributes, the user could override per
> instance.
I had a similar thought, but wanted to separate slotting from mapping.
Choosing a specific transistor (Fairchild 2N3904 TO92, for example)
triggered a map
Vanessa Ezekowitz wrote:
> You mean, like THIS? (see attachment)
Ok, this is _all_ permutations of certain three letter combos. May be
a little bit over the top for general distribution. Many combinations
do not correspond to any component in the real world. Having them in
the lib just invites e
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?
Hi,
I'm doing some maintenance on the gEDA wiki this weekend, so it is
currently in read-only mode. Let me know if you desperately need to
make an edit. :)
Thanks,
-Ales
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bi
Hi All,
[snip entire message]
I've dealt with this offline and made some changes so it doesn't happen
again.
Sorry for the interruption,
-Ales
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-use
Hi folks,
Effectively immediately, all gEDA mailing lists except geda-dev are
now moderated. As I do not want to moderate every single post, I will
do some sort of a whitelist scheme and I'll find a way of getting a
group of people moderation privileges.
Sorry for the sudden change. Feel free
On Sat, 21 May 2011 20:42:48 +0200
Wojciech Kazubski wrote:
> > Vanessa Ezekowitz
> > [... posted an equivalent replacement footprint ...]
>
> TO-92 transistors use at least four pinouts. The footprint name shall
> indicate this if it has E, B, C instead of pin numbers. I think that plain
> TO
> The discussion about "reinventing the wheel" reminded me:
>
> The TO92 footprint included with PCB does not work with the schematic
> importer therein. Try to reference it and the importer complains about
> missing pins, because it uses numbered pins instead of the B-C-E lettering
> used in
Larry Doolittle wrote:
> I have done that, too, but only rarely. It's a royal PITA.
> Do those guys *cough*Marvell*cough* want us to use their parts,
> or not?
The real problem occurs when a device with the functionality you need is
made *only* by the "shithead" companies like Broadcom, Marvell
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
> How come, this meme of "limiting" appears in about every discussion on
> future developments? Even in those, that are explicitly about broadening
> the scope of the tools.
Because it's a key requirement that we allow a variety of flows to
operate. I think we all agree that this is important
> I am not sure, where the import function of PCB can be configured.
> Last time I checked, it seemed to use the paths given in
> $HOME/.pcb/preferences
It uses PCB's internal paths, yes, so whatever works in the
Window->Library dialog works for import.
> But schematic import did not play nice
Stephen Ecob wrote:
> There will always be a place for both heavy and light. People's work
> flows vary too much to limit gEDA to just one.
How come, this meme of "limiting" appears in about every discussion on
future developments? Even in those, that are explicitly about broadening
the scope
Karl Hammar wrote:
> I already have checked out cvs.gedasymbols.org, how do I integrate
> it withing gschem and pcb?
Let the config files point to where your preferred symbols and
footprints are stored. Unfortunately, gschem does not descend
into subdirectories. So you have to give each and eve
Ales:
> Kai-Martin Knaak,
>
> [snip]
> > No size fits all. That does not preclude improvement over the current
> > situation.
>
> DJ and I are asking you to improve the current situation by creating,
> distributing, and maintaining a better default symbol library than the
> one that is currently
Cullen,
I suspect the TO-92A/B/C notation comes from some layout package, and
that is why other packages use other terminology. It is not in the
original TO-92 spec, which is available free (registration required)
from JEDEC at http://www.jedec.org/standards-documents/focus/register
Tom Pope wrote:
> Is there any chance of tarring up -all- of the the symbols and
> footprints on gedasymbols.org?
You can do a wholesale anonymous cvs download. While this is
technically not a tar ball, it serves the same purpose to create
copy of the repository on the local hard disk. As an add
> Feel free to post a tarball or other installer, so that the users can
> replace geda's library with yours. John Luciani did that on his site,
> you can do it on gedasymbols if you want. Make it a copy of the
> library you actually use, doesn't require much work, just make it
> available to othe
32 matches
Mail list logo
