gnupic: Thread: gpsim pinout window

Hello,

I'm starting coding a gui version of "processor pins"

Here's what I have now: http://www.acc.umu.se/~rfg/pinout.gif.

The arrows will indicate input/output, and pins without
arrows are non-io pins.

But the cli command shows pin names also, and that won't fit here,
unless I put them somewhere outside the pic.

Or is it better to turn the pic 90 degrees and put the names inside
the "casing", like it is in the cli output?

Or a statusbar?

Would colors help in some way?

Pins are toggled by doubleclicking on them. Should I limit input so
that only input pins are toggleable?

Is there a point in having clicks on the arrows change the tris
registers?

 / Ralf

On Sun, Jan 23, 2000 at 03:59:56PM +0100, Ralf Forsberg wrote:
> I'm starting coding a gui version of "processor pins"
> Here's what I have now: http://www.acc.umu.se/~rfg/pinout.gif.

At first glance, it should be rotated clockwise by 90 degrees.

> The arrows will indicate input/output, and pins without
> arrows are non-io pins.

Presumably that is current state rather than design state?
Sometimes I make a pin change between input and output low.

> But the cli command shows pin names also, and that won't fit here,
> unless I put them somewhere outside the pic.

Have them appear as tooltips?  The most important legend would be
the pin names (e.g. RA4) rather than the package pin numbers.

> Or is it better to turn the pic 90 degrees and put the names inside
> the "casing", like it is in the cli output?
> Or a statusbar?
> Would colors help in some way?

Yes,
	red = high output
	green = low output
	blue = normal input
	yellow = weak pull-up input

> Pins are toggled by doubleclicking on them. Should I limit input so
> that only input pins are toggleable?

No.  I may need to simulate some situations in which an output pin is
being held high or low despite the driver latch not agreeing.

> Is there a point in having clicks on the arrows change the tris
> registers?

Not sure.

Warning: I'm not really sure what the "processor pins" feature does.

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

On Sun, 23 Jan 2000, you wrote:

I have a new example at www.acc.umu.se/~rfg/pinout2.gif.

It is rotated, has colors and pin names.

>> Or is it better to turn the pic 90 degrees and put the names inside
>> the "casing", like it is in the cli output?
>> Or a statusbar?
>> Would colors help in some way?
>
>Yes,
>	red = high output
>	green = low output

Ok.

>	blue = normal input
>	yellow = weak pull-up input

Why not:
	blue = high input
	green = low input

, I wonder?

 / Ralf

On Mon, 24 Jan 2000, Ralf Forsberg wrote:

> On Sun, 23 Jan 2000, you wrote:
> 
> I have a new example at www.acc.umu.se/~rfg/pinout2.gif.

Cool!

> 
> It is rotated, has colors and pin names.

One issue that I ignore in the cli is the quad package. Rotation is not an
issue, you've got pins on all 4 sides. Also, I assume that the other sized
packages (dips not quads) are being added? Or is the package dynamically
created?

I don't have anything major to add to what you've presented so far.
However, have you considered adding node names to the pins? I have not
done it for the cli, but what I was thinking of here was having the pin
names on the inside of the IC (like in your .gif) and the node names on
the outside. (And I can hear it now... If you show the node names, how
about the stimuli on the other end? :)

Having the ability to single click on the arrows would be a really neat
way to change the tris bits. One caveat that we'll need to keep in mind
while this is being done is that this could initiate a cascading change
(if for example, a stimulus is attached to the pin you're changing).

This new feature reminds me of that old 16c84 only simulator that runs
directly on top of X.

Scott

On Sun, Jan 23, 2000 at 03:59:56PM +0100, Ralf Forsberg wrote:
> I'm starting coding a gui version of "processor pins"
> Here's what I have now: http://www.acc.umu.se/~rfg/pinout.gif.

At first glance, it should be rotated clockwise by 90 degrees.

> The arrows will indicate input/output, and pins without
> arrows are non-io pins.

Presumably that is current state rather than design state?
Sometimes I make a pin change between input and output low.

> But the cli command shows pin names also, and that won't fit here,
> unless I put them somewhere outside the pic.

Have them appear as tooltips?  The most important legend would be
the pin names (e.g. RA4) rather than the package pin numbers.

> Or is it better to turn the pic 90 degrees and put the names inside
> the "casing", like it is in the cli output?
> Or a statusbar?
> Would colors help in some way?

Yes,
        red = high output
        green = low output
        blue = normal input
        yellow = weak pull-up input

> Pins are toggled by doubleclicking on them. Should I limit input so
> that only input pins are toggleable?

No.  I may need to simulate some situations in which an output pin is
being held high or low despite the driver latch not agreeing.

> Is there a point in having clicks on the arrows change the tris
> registers?

Not sure.

Warning: I'm not really sure what the "processor pins" feature does.

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

On Mon, 24 Jan 2000, you wrote:
>> 
>> I have a new example at www.acc.umu.se/~rfg/pinout2.gif.
>
>One issue that I ignore in the cli is the quad package. Rotation is
>not an issue, you've got pins on all 4 sides. Also, I assume that
>the other sized packages (dips not quads) are being added? Or is the
>package dynamically created?

Where would I put the pin names on a quad? There is not a simple way
to draw tilted text. I think you have to draw to a pixmap, rotate the
pixmap and draw it. But you only have to do it at startup, though.

And yes, it's dynamically created.

>
>I don't have anything major to add to what you've presented so far.
>However, have you considered adding node names to the pins? I have not
>done it for the cli, but what I was thinking of here was having the pin
>names on the inside of the IC (like in your .gif) and the node names on
>the outside. 

That implies doing better code structure than what I have now (I
have a single function doing all drawing).

Presently I'm using a gtk_drawing_area and draw with gdk_draw*(). It
gets a bit complicated, lots of calcluation and stuff.

>(And I can hear it now... If you show the node names, how
>about the stimuli on the other end? :)

Don't forget support for loadable modules (or corba) for implementing
a RS232 I/O terminal, PC parallel port interfacing, logic components,
LCDs and stuff. :)

 / Ralf

On Tue, 25 Jan 2000, Ralf Forsberg wrote:

> On Mon, 24 Jan 2000, you wrote:
> >> 
> >> I have a new example at www.acc.umu.se/~rfg/pinout2.gif.
> >
> >One issue that I ignore in the cli is the quad package. Rotation is
> >not an issue, you've got pins on all 4 sides. Also, I assume that
> >the other sized packages (dips not quads) are being added? Or is the
> >package dynamically created?
> 
> Where would I put the pin names on a quad? There is not a simple way
> to draw tilted text. I think you have to draw to a pixmap, rotate the
> pixmap and draw it. But you only have to do it at startup, though.

That is one of gtk's short comings. Motif, for example, allows more
control in this area. Maybe we can pimp Adrian into creating rotatable
widgets! 

> 
> And yes, it's dynamically created.

Another possibility is to begin with hardcoded pixmaps and define 'hot'
areas. These hot areas could define where, for example, the pin direction
indicators need to be drawn, the color coded pin-state information needs
to be drawn, etc. I'm not sure how winamp or pose does it, but they create
and support 'skins' which is a fancy name for these background pixmaps. If
we did this, perhaps we can motivate the artists to create some beautiful
back drops :). 

Here are a couple of other ideas. You could try just providing the extra
space for the names. But then the graphic will not have the same
proportions as the real part. Another alternative is to place the names
outside and the numbers inside. Or you could use James' suggestion and
make the names be part of a tooltip.

> >
> >I don't have anything major to add to what you've presented so far.
> >However, have you considered adding node names to the pins? I have not
> >done it for the cli, but what I was thinking of here was having the pin
> >names on the inside of the IC (like in your .gif) and the node names on
> >the outside. 
> 
> That implies doing better code structure than what I have now (I
> have a single function doing all drawing).

That's totally okay for now. It may have to change later on -- but that's
true of all of gpsim.

> Presently I'm using a gtk_drawing_area and draw with gdk_draw*(). It
> gets a bit complicated, lots of calcluation and stuff.
> 
> >(And I can hear it now... If you show the node names, how
> >about the stimuli on the other end? :)
> 
> Don't forget support for loadable modules (or corba) for implementing
> a RS232 I/O terminal, PC parallel port interfacing, logic components,
> LCDs and stuff. :)

Last weekend, i spent a couple of hours hacking grpn (an rpn calculator)  
to get the damn ui to allow me to easily switch from hex to decimal
(something I spend way too much time doing). To make a long story short,
it got me thinking about how to go about and creating an LCD. As soon as
18.0 is out, I might begin doing this. The goal would be to create a
'module' separate from gpsim. I'm hoping to design an interface which may
serve as a template upon which others may build. 

Scott

>> >> I have a new example at www.acc.umu.se/~rfg/pinout2.gif.
>> >One issue that I ignore in the cli is the quad package. 
>> Where would I put the pin names on a quad? 
>Here are a couple of other ideas. You could try just providing the extra
>space for the names. But then the graphic will not have the same
>proportions as the real part. Another alternative is to place the names
>outside and the numbers inside. Or you could use James' suggestion and
>make the names be part of a tooltip.

Is is possible to have tooltips for non-widget things like drawables
and clists? Is it possible to force tooltips to appear when you want
them to?

>Last weekend, i spent a couple of hours hacking grpn (an rpn calculator)  
>to get the damn ui to allow me to easily switch from hex to decimal
>(something I spend way too much time doing). To make a long story short,
>it got me thinking about how to go about and creating an LCD. As soon as
>18.0 is out, I might begin doing this. The goal would be to create a
>'module' separate from gpsim.

Are you going to have seperate processes or use dlopen and friends,
or some other way?

 / Ralf
 

On Wed, 26 Jan 2000, Ralf Forsberg wrote:

> Is is possible to have tooltips for non-widget things like drawables
> and clists? Is it possible to force tooltips to appear when you want
> them to?

Don't know...

> 
> >Last weekend, i spent a couple of hours hacking grpn (an rpn calculator)  
> >to get the damn ui to allow me to easily switch from hex to decimal
> >(something I spend way too much time doing). To make a long story short,
> >it got me thinking about how to go about and creating an LCD. As soon as
> >18.0 is out, I might begin doing this. The goal would be to create a
> >'module' separate from gpsim.
> 
> Are you going to have seperate processes or use dlopen and friends,
> or some other way?

The part I've only thought about was how to create the LCD background, map
characters to the display, define the display attributes, and interfacing
to an LCD header.

The LCD header will be a bitmap of the LCD header's I/O pins. In
other words, one pin on the header will correspond to one bit. Data is
written into the module much the same as it is in a real device: data
placed onto the data bus and is clocked in. 

I do not yet know how to make this data port interface to other modules,
such as gpsim. Alternatives that I've though about:

1) Link directly in with gpsim's gui.
   - Perhaps the module could be a subdirectory off of gpsim/gui/ 

2) A separate application that's placed into a library and linked with
gpsim. Essentially the module would be developed and maintained separate
from gpsim. However, when gpsim is compiled, the module would be linked in
much the same way that gtk+-extra is now.

3) A separate application that interfaces to gpsim through a formal IPC
interface. A simple socket interface should be sufficient. But if there's
a corba expert among us willing to donate their services, well please step
forward and give us some guidance here. 


Initially I'll do step (1). Ultimately I'd like to implement (3). 

--------------
But I'm getting way ahead of my self. I definitely want to focus on
gpsim-0.18.0. I'd like to get a release out asap. If you want to add the
pins stuff that would be great. I'm right now in the middle of
implementing the config word for the 18cxxx devices. I found a deficiency
in gpasm's .cod file logic that prohibits the config word from being at an
address above 64k. (Actually, the .cod logic prohibits anything from being
at 64k. I've gpasm torn to pieces right now and am slowly putting it back
together. New versions of gpasm and vc should be coming out shortly.)

Scott