gnupic: Thread: watch window for gpsim gui

I'm about to implement a <subj>.

Here's what I'll do if nobody says anything:

 - There will be three formats: hex, dec, bin. A right-click menu
   selects witch of the columns to display
 - Each bit in binary-format columns will be easily 
   toggleable (is that a word?) by clicking on it.
 - Adding watches is done by selecting them in the registersheet
   and do right-click->"watch...".
 - "Del" in watch window clears selected watch(es).

I'll use a clist since they are so damn convinient.


How useful would it be to see the names of the bits for registers in
a special "details" window?

How useful would it be to have a graphical representation of the pic
in gpsim.

 / Ralf

Hello Ralf,

>  - There will be three formats: hex, dec, bin. A right-click menu
>    selects witch of the columns to display

Would each watch have selectable formats or would the entire watch window
switch formats? I think it would be useful to select some watch variables to be
displayed in hex, others in dec and others in bin. To make it easier to
program you could have the watch window display all formats in three columns,
that might cut down on the users time to set up the watch window with
the desired formats after the variable has been selected.


>  - Each bit in binary-format columns will be easily 
>    toggleable (is that a word?) by clicking on it.
>  - Adding watches is done by selecting them in the registersheet
>    and do right-click->"watch...".
>  - "Del" in watch window clears selected watch(es).
> 
> I'll use a clist since they are so damn convinient.

Sounds good to me.


> How useful would it be to see the names of the bits for registers in
> a special "details" window?

Would the watch window be able to display single bits from a word (rather than
just the whole word)? If so then the bit name would be displayed already. If you
are only going to display the entire word then maybe a tooltip (with the
bit name) could pop up when an individual bit in that word is pointed at.


> How useful would it be to have a graphical representation of the pic
> in gpsim.

Do you mean a chart of all the memory or a picture of functional blocks?
What features (if any) would it have?
Either type would require a lot of maintenance each time a new processor is
added.


--
Anthony

On Sun, 09 Jan 2000, you wrote:
>
>>  - There will be three formats: hex, dec, bin. A right-click menu
>>    selects witch of the columns to display
>
>Would each watch have selectable formats or would the entire watch window
>switch formats?

(I mean't "which", up there :-)

I'll use three columns and hide/show columns as the user requests.
The right-click menu would use toggle menu items with hex, dec and
bin labels.


>> How useful would it be to see the names of the bits for registers in
>> a special "details" window?
>
>Would the watch window be able to display single bits from a word (rather than
>just the whole word)?

No, whole words.

BUT. Are there pics with registers that are larger than eight bits?

How does the 16bit pics work?


> If so then the bit name would be displayed already. If you
>are only going to display the entire word then maybe a tooltip (with the
>bit name) could pop up when an individual bit in that word is pointed at.

Yes, there's an idea.

>
>
>> How useful would it be to have a graphical representation of the pic
>> in gpsim.
>
>Do you mean a chart of all the memory or a picture of functional blocks?
>What features (if any) would it have?
>Either type would require a lot of maintenance each time a new processor is
>added.

No, I was thinking about pinout. The picture can be automatically
genereated when you know pin numbers and type of casing.

I don't know how useful it would be but some other uP simulators have
it. I wouldn't use it myself.


 / Ralf

On Sun, 09 Jan 2000, you wrote:
> >> How useful would it be to have a graphical representation of the pic
> >> in gpsim.
> >
> >Do you mean a chart of all the memory or a picture of functional blocks?
> >What features (if any) would it have?
> >Either type would require a lot of maintenance each time a new processor is
> >added.
> 
> No, I was thinking about pinout. The picture can be automatically
> genereated when you know pin numbers and type of casing.
> 
> I don't know how useful it would be but some other uP simulators have
> it. I wouldn't use it myself.

I might find that useful.  I do a lot of sequential things and it might be
convenient to have something that shows the pins one color for high, another
color for low, and another color if set as an input.  I really don't know how
much I would use it w/out having one to play with, but if you do add it in, I'll
make sure to tell you what I think then.

-- 
-Sam

On Sun, 9 Jan 2000, Ralf Forsberg wrote:

> 
> I'm about to implement a <subj>.
> 
> Here's what I'll do if nobody says anything:
> 
>  - There will be three formats: hex, dec, bin. A right-click menu
>    selects witch of the columns to display
>  - Each bit in binary-format columns will be easily 
>    toggleable (is that a word?) by clicking on it.
>  - Adding watches is done by selecting them in the registersheet
>    and do right-click->"watch...".
>  - "Del" in watch window clears selected watch(es).

Sounds great!

> 
> I'll use a clist since they are so damn convinient.
> 
> 
> How useful would it be to see the names of the bits for registers in
> a special "details" window?

I think this would be somewhat difficult to do in an arbitrary way. Right
now, the bit names - if they're defined at all - come to gpsim as constant
defined in the .cod file. There is no type information associated with
them. So somehow you would have to know what the bit names are. This
information is present in the form of enumerated constants throughout the
files supporting the various pic subsystems. Unfortunately, the ascii
names for these constants aren't avaliable. How were you thinking about
implementing this?

> How useful would it be to have a graphical representation of the pic
> in gpsim.

Version 0.17.1 (which only one other person besides me has seen) contains
a new cli option for the processor command. "processor pins" will display
a tabulated/quasi graphical, ASCII representation of a pic processor and
show pin names, pin numbers, and the pin states (only H and L for high and
low - analog states are not shown yet). 

Here's an example dump for the c84:

  +--+---------\/---------+--+
L | 1| porta2      porta1 |18| L
L | 2| porta3      porta0 |17| L
L | 3| porta4             |16|
  | 4|                    |15|
  | 5|                    |14|
H | 6| portb0      portb7 |13| H
H | 7| portb1      portb6 |12| H
H | 8| portb2      portb5 |11| H
H | 9| portb3      portb4 |10| H
  +--+--------------------+--+

The new code is cmd_processor.cc in the function dump_pins(). I added a
couple of new base class functions to the pic_processor class that will
support access to the pin names, pin states, and to package stuff in
general. We'll want to place wrappers around these in interface.cc . (At
some point, interface.cc is going to have to be split...)

At some point I'd like to also show the stimuli attached to the pins.


(Ralf knows most of what I'm going to say next). The gui version should be
able to easily duplicate this basic functionality. However, to make it
useful, cross references such as those that are present between the file
registers and the register_window(s) will also be needed. This will allow
the window to be dynamically updated. An added bonus would be to toggle a
pin state by simple clicking on the state indicator.

When we get to the point where stimuli are an integral part of the gui it
would be nice to be able to edit the stimuli that attached to the pins.


BTW, the latest development version of gpsim can be obtained from:

http://www.dattalo.com/gnupic/gpsim-0.17.1.tar.gz

Scott

> BUT. Are there pics with registers that are larger than eight bits?
> 
> How does the 16bit pics work?

The 16bit PICs (PIC174x) still have an 8 bit data path, only the instructions
are 16 bit.

--
Anthony

>> How useful would it be to see the names of the bits for registers in
>> a special "details" window?
>
>I think this would be somewhat difficult to do in an arbitrary way. Right
>now, the bit names - if they're defined at all - come to gpsim as constant
>defined in the .cod file. There is no type information associated with
>them. So somehow you would have to know what the bit names are. This
>information is present in the form of enumerated constants throughout the
>files supporting the various pic subsystems. Unfortunately, the ascii
>names for these constants aren't avaliable. How were you thinking about
>implementing this?

(I don't know if I will)

We would have to add these names somewhere.
If we add a:
file_register->add_bit_names(char **names) 
and a char *file_register->get_bit_name(int bit)
and add s call to add_bit_names() for every add_name() that currently
are in the code.

Another thing somewhat related to this problem is that symbols
"status", "pcl", "indf", ... are recognized as of type
SYMBOL_CONSTANT instead of SYMBOL_REGISTER. We want a way to match
symbols to SFR names.

Having the SFRs of type SYMBOL_REGISTER would allow the register
viewer to distinguish between SFR's and other registers (perhaps with
another color). (it would help in other ways too)

 / Ralf