I went through the whole thread again, in chronological order, and
tried to maintain a "current opinion" for each of the participants as
ideas were tossed around and people changed their minds or
agreed/disagreed with others' proposals. Then I collected the results
and tried to distill the essenc
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
Cool,
Got photos?
Steve
On May 22, 2011, at 6:57 PM, John Doty wrote:
> Well, here I am in Osaka. It's Monday morning, and I just saw the prototype
> Soft X-ray Imager (SXI) for the ASTRO-H space mission under test. Much of the
> electronics, a large, complex circuit board and some mixed-
On 05/22/2011 08:57 PM, John Doty wrote:
I've been working on this for six years, now, and it's wonderful to see it all
built and plugged together.
Congrats John.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailm
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
Stephen Trier wrote:
> Kai, try (component-library-search"/home/..snip../symbols"
>
Unfortunately, it works only for the first layer. Symbols in
../symbols/analog/diode are still ignored. In other words: gschem
does not descend recursively into sub dirs.
---<)kaimartin(>---
--
Kai-Martin Kna
Well, here I am in Osaka. It's Monday morning, and I just saw the prototype
Soft X-ray Imager (SXI) for the ASTRO-H space mission under test. Much of the
electronics, a large, complex circuit board and some mixed-signal ASICs, is of
my design, using gEDA. I've been working on this for six years,
On May 23, 2011, at 7:30 AM, Kai-Martin Knaak wrote:
>> (component-library-search "Components")
>>
>
> Just tried again and it didn't work on on my box. I tried this
> line:
> (component-library
> "/home/kmk/geda/gedasymbols/www/user/kai_martin_knaak/symbols")
^
Should be:
Stephen Trier wrote:
> Kai, try (component-library-search
Oh, now I see!
Must have been blind before.
I'll add this to the wiki and to the tutorial, too.
---<)kaimartin(>---
--
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
http://pool.sks-keyservers.net:11371/pks/lo
It worked for me in gschem 1.6.1.20100214. Thanks for the tip, John!
Kai, try (component-library-search
"/home/kmk/geda/gedasymbols/www/user/kai_martin_knaak/symbols") instead
of (component-library ...).
Stephen
___
geda-user ma
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
Thanks for taking the time to report the list - status update below.
On Sun, May 22, 2011 at 06:01:49PM +0200, Felix Ruoff wrote:
> Here is the list:
> a) Patches for documentation
> - 699306 elements color in manual
Committed.
> - 699391 refcard updates
Committed.
> - 699476 G-CO
John Doty wrote:
>
> On May 21, 2011, at 8:30 PM, Kai-Martin Knaak wrote:
>
>> Unfortunately, gschem does not descend
>> into subdirectories. So you have to give each and every dir in
>> the config.
>
> Ah, but it can. I've been using lines like:
>
> (component-library-search "Components")
>
[snip]
>Yes, the developers will do whatever they want (regardless of whether you
>think it is flexible or inflexible).
And let me further qualify this statement with this:
John Doty, if you really want to influence the developers, then you
should step up and create something (like a prototyp
[snip]
>The difficulty for me is that when I see potentially flexible changes discusse
>d in inflexible ways by developers, I strongly suspect that the developers wil
>l act as they write: they will actually implement something inflexible.
Yes, the developers will do whatever they want (regardles
Hey all,
I am cleaning up the unit handling for the gerber
exporter, using the guide at
http://www.linux-cae.net/PCB/rs274xrevd_e.pdf
Things are mostly straightforward, but I am lost
as to the /10 factors in
/**/
/* U
On May 21, 2011, at 9:30 PM, DJ Delorie wrote:
>
> 1. Nobody wants to kill support for anyone's personal process
What people want want what they actually do are two different things
> A little trust here is needed to get us past the "what should we do"
> phase and into the "how can we do it" p
On May 21, 2011, at 8:30 PM, Kai-Martin Knaak wrote:
> Unfortunately, gschem does not descend
> into subdirectories. So you have to give each and every dir in
> the config.
Ah, but it can. I've been using lines like:
(component-library-search "Components")
for years in my gafrc files. "Compon
>
> Yes, I think there is supposed to be a TO-92A, TO-92B, and TO-92C (the
> different orders) but nobody paid enough attention, and I'm not sure if this
> is standard, or merely convention. see attached gif that was stolen from
> http://www.kss.sd23.bc.ca/chalmers/robotics10/Labs/ComparePNPNPN/h
On Sun, 22 May 2011 11:27:24 -0500
John Griessen wrote:
> On 05/22/2011 10:37 AM, Kai-Martin Knaak wrote:
> > Next try: "packet"
> > This can also contain all kinds of objects. It closely avoids the
> > clash with the meaning of "package" in data sheets.
>
> Packet is a good one. If someone is
On 05/21/2011 11:35 PM, Steven Michalske wrote:
So that wires that have the same meaning are still hooked up
but new pins are unconnected, or old pins that no longer exist are now
not connected.
The other wish list ideas sound like where we are headed, but this last is
probably beyond coder cap
On 05/22/2011 10:37 AM, Kai-Martin Knaak wrote:
Next try: "packet"
This can also contain all kinds of objects. It closely avoids the
clash with the meaning of "package" in data sheets.
Packet is a good one. If someone is confused they can be told library packet,
or see it is in library contex
Hello,
I spend some time with the pcb-bugtracker on launchpad. So, I made a
list of things, where I think, they can be done without adding new
problems. Perhaps, someone of the developer with commit-access can have
a look for them. There also are several patches which looks fine to me,
but my
John Griessen wrote:
> I think the name package could create confusion
> with layout package used to implement a circuit,
I proposed "package" because eagle uses this term for a very similar
concept. Yes, package already has a distinct meaning in the context
of electronics. I would not be happy
I haven't noticed it in the future-library discussion yet, but one way
or the other, I would like some sort of namespacing or subdirectory
awareness in linked symbols. For example, I have a project with two
symbols named "pad.sym" on the search path. One is from the standard
library
On Sat, May 21, 2011 at 7:53 PM, John Griessen wrote:
> 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
Let's try not to change the subject line too much, I need to be able
to find all these later to summarize :-)
> I was just trying to talk in general words about Kai martin's
> package idea. A package, (or any name for same idea), is a dir with
> footprint, symbol, simulation model, datasheet lin
30 matches
Mail list logo
