gnupic: Thread: schematic capture for gpsim

Ralf has gotten my module changes to work for him. All that it's done though is
filled is head with all kinds of good, but ambitious, ideas! Hear is an edited
transcript of some of the stuff we've been sending back and forth. If anyone
cares to comment, please jump in.

------------------


Ralf, you bring up some really interesting points. So, I've gone ahead and moved
the discussion onto the list. (I hope you don't mind)

On Sun, 9 Jul 2000, Ralf Forsberg wrote:

[discussion about how CVS was foo-barred snipped]

> Well, it is ok now. Weird. :-).

Yeah, weird.

> I got it working anyway, it's really neat! 

Thanks. I put a lot of work into it and knew that it would be more popular if it
was graphically appealing. But there's a bunch of stuff under the hood, so to
speak. I've made the interface flexible which is good and bad. It's good in that
it potentially gives more control over the interaction between gpsim and the
modules, but bad in that it will be more difficult for the module programmer to
come up to speed. The api is only documented by the examples...

> 
> The thing missing is a way to create/access the netlist from the gui.
> This would be a nice project to work on during these rainy days of the
> summer. I'm not saying that I'll actually code this, but it does
> seem like a fun project.

True. There are many ways to do this.

> 
> First, am I right when I'm saying that:
> 
>  * 'node' in gpsim is the copper wire.
>  * 'stimuli' in gpsim are attachment points where nodes can connect.
>    - A stimuli is a signal.
>    - pins are stimuli
>    - special stimuli can be created using the 'stimulus' command.

Correct. A node is like a node in circuit analysis or a net in a schematic or a
copper wire in a real circuit. A stimulus is something that can connect to a
node. Initially, I intended a stimulus to be like a signal generator. But as I
went on, I found that I had a need for things like pullup resistors (to emulate
portb). So the definition of a stimulus expanded into what it is now.

 
> I'm asking because my brain has decided that a node is a pin :-). It
> gets confusing fast.
> 
> Then, what I'm pondering:
> Feel free to comment, these are some first thoughts. I looked at the
> screenshots of 'virtual breadboard' for input. Do you know of other
> similar programs?

I had forgotten about 'virtual breadboard'. The 7-segment display almost looks
as good as the one I copied from dclock :). Their LCD display really sucks
though.

It's been a while since I've looked, but there's UMPS too. 

> 
>  * if a node is connected to a pin then the node name is
>    displayed next to the 'wire'. Possibly, future/past states can be
>    displayed from here some day.             


>  * position data for pins and packages need to be stored somewhere
> related to the source, I wonder where. We have ~/.gpsim for
> configuration, but we would need another database for this kind of
> thing. Breakpoints could be saved to this file too.
>    - What should happen when loading a .stc file with nodes and
>       stuff  but without any shape or position information. I don't
> want to      implement autoplace and autoroute for this :-). 

It sounds like your talking about some kind of schematic/layout program.
Essentially, users would create the schematic they wish to simulate, write the
pic program for it, and then run it. Creating a program such as this would be
very challenging indeed! Perhaps we could leverage off some of the wonderful
work Ales Hvezda and etc. all have done with gEDA: http://geda.seul.org/ . If it
would be possible to somehow link gpsim and gEDA through some kind of IPC that
would be great! But a lot of work would be required in both gpsim and gEDA to
make this happen.

>  * pin
> state indicators are moved to above the pins so the wire fits 
>  * modules are represented how?                                 
>    - Do
> we want the modules to define the package (pin positions and size)   
>       or should that be done in gpsim. 

I've thought about this a little. It would be best if we could come up with a
way to allow the graphical portion of modules (which a pic is now, btw) be
defined outside of gpsim and the module code. In other words, ideally it would
be more useful to create a part editor. Parts could be created or built. If you
wanted to add pin numbers, or H/L indicators, or direction indicators, or
whatever, you could build it into the part. Then gpsim could parse the part
files and dynamically create the internal links (between the registers and I/O
pins for example). Unfortunately, this is a LOT of work. 

>  * The names of packages are
> drawn above the packages 
>  * The pins are either to the left or right
> of the packages. Never    above or below. 
>  * There will be only
> straight wire between two connector points. 
>  * There can be any
> number of shape points. Shape points are used to route    wire to the
> destination. 
>  * In addition to packages, pins (stimuli) and wire
> (nodes), there    needs to be 'shape nodes' that shapes the wire.

By 'shape points', are you referring to the way the virtual breadboard handles
corners? It seems unnecessary. Or am I missing something?


------------------------------------

Here are a couple projects that we've looked at as possible schematic
entry/editors for gpsim:

http://geda.seul.org/
http://gossip.sourceforge.net/
http://www.dtek.chalmers.se/~d4hult/oregano/

about oregano, I wrote:

It has a much nicer look and feel than gschem. It's written on top of gnome.
I've been hesitant to introduce gnome to gpsim, but I'm not absolutely against
it. My beef with gnome is that it has a huge foot print. Perhaps now that gpsim
is built as a shared library this doesn't matter much anymore.

then about gossip, Ralf wrote:

Last night I thought about module representation in the breadboard
window. Since the modules run in the same process as gpsim, shouldn't
the modules be able to give gpsim a pointer to its main widget so
that gpsim display the actual module window inside the breadboard
(like in virtual breadboard). Modules still can have its own
popupmenus/buttons/whatever.

gossip-ed seems to not exist today and they mention writing it in
scheme. I don't know how that would work when interfacing C/C++
and gpsim, but I suppose it would work (guile is designed for this).
We want the editor to be in gpsim's address space, somehow (this is if
we want the module widgets to be displayed inside the schematic).
There are lots of code that could be shared, if designed well.

gschem is another option. But it uses a GtkDrawingArea as its base
widget, which means you can't put widgets inside the schematic.

I wish there was a schematic entry program using a gtklayout as its
base widget, since that enables you to put actual widgets inside the
schematic (as opposed to more or less static images).

Perhaps it's inpractical to use a gtklayout this way?

 / Ralf
---------------------------------

Back to scott:

I recall something about gnome having I believe what it calls a 'canvas' which
I believe is a container for any kind of gnome widget. It's been over a year
since I looked at it, but I recall several people on the gtk list desiring a gtk
widget with similar functionality.

----------------------------------


If you have comments or suggestions about marrying gpsim with a schematic
editor, let us know. If you care to jump in as a developer and make things
happen, then I'll give you developer access to gpsim's CVS.


Scott

On Sun, 09 Jul 2000, Scott wrote:
>> number of shape points. Shape points are used to route    wire to the
>> destination. 
>>  * In addition to packages, pins (stimuli) and wire
>> (nodes), there    needs to be 'shape nodes' that shapes the wire.
>
>By 'shape points', are you referring to the way the virtual breadboard handles
>corners? It seems unnecessary. Or am I missing something?

There are shape points for corners. They doesn't nessessarily have
to show up on the screen, but they need to be stored somewhere.


>I recall something about gnome having I believe what it calls a 'canvas' which
>I believe is a container for any kind of gnome widget. It's been over a year
>since I looked at it, but I recall several people on the gtk list desiring a gtk
>widget with similar functionality.

Yes gnomecanvas allows for both widgets and drawing primitives. This
is what Oregano uses.

 / Ralf

> If you have comments or suggestions about marrying gpsim with a schematic
> editor, let us know. If you care to jump in as a developer and make things
> happen, then I'll give you developer access to gpsim's CVS.

xcircuit is a decent schematic editor and the author plans on turning it into a
schematic capture program that produces SPICE output.


xcircuit web page:
 http://bach.ece.jhu.edu/~tim/programs/xcircuit/


schematic capture beta code:
 http://bach.ece.jhu.edu/~tim/programs/xcircuit/archive/xcircuit-2.0b4.tar.gz


-- 
Anthony

I agree with Anthony.  I use xcircuit now for most of my work, but not
yet for producing the output for PCB production or simulation with
SPICE.  I couldn't find anything else that was simple enough to use.
Give it a try before you eliminate it; the interface is simple.

It could do with being encapsulated within GTK, in my opinion.

-- 
James Cameron    ####@####.####     http://quozl.netrek.org/

On Mon, 10 Jul 2000, James wrote:
>I agree with Anthony.  I use xcircuit now for most of my work, but not
>yet for producing the output for PCB production or simulation with
>SPICE.  I couldn't find anything else that was simple enough to use.
>Give it a try before you eliminate it; the interface is simple.
>
>It could do with being encapsulated within GTK, in my opinion.

What do you mean with encapsulate? Make a widget of it? 
How do you do that? 

It's also not GPL. It has the artistic license.

 / Ralf

On Tue, Jul 11, 2000 at 02:38:38AM +0200, Ralf Forsberg wrote:
> What do you mean with encapsulate? Make a widget of it? 
> How do you do that? 

No, not make a widget of it, but replace the menu and outer window with
a GTK implementation instead of the odd widget library being used.

> It's also not GPL. It has the artistic license.

If your plans conflict with the license, ask the license owner to make
an exception for you or a specific project.

-- 
James Cameron    ####@####.####     http://quozl.netrek.org/

On Tue, 11 Jul 2000, James Cameron wrote:

> On Tue, Jul 11, 2000 at 02:38:38AM +0200, Ralf Forsberg wrote:
> > What do you mean with encapsulate? Make a widget of it? 
> > How do you do that? 
> 
> No, not make a widget of it, but replace the menu and outer window with
> a GTK implementation instead of the odd widget library being used.

I suspect that it'd have to be an all or nothing deal. The Xcircuit drawing
window is an Xt thing. The schematic capture logic is deeply entrenched with Xt
calls. Perhaps these could co-exist with gtk. I don't know...

> 
> > It's also not GPL. It has the artistic license.
> 
> If your plans conflict with the license, ask the license owner to make
> an exception for you or a specific project.


I contacted Tim Edwards (the author of Xcircuit) and am awaiting his answer. I
basically asked about gtk, the Xcircuit license and about how hard it would be
to support something like `dynamic symbols' (i.e. encapsulations of the modules
I've created).

I also have joined the gEDA mailing list and will try to solicit opinions from
there too. 

Scott