gnupic: Thread: gpsim-0.20.9b

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

This version supports the PCON register (among other things).

I was unable to create an rpm, or at least an rpm that worked.

Other features recently added:

-  break on bit(s)

break [c e | w | r | wv | rv | so | su | wdt [location] [value [mask]]
]

now you can do something like:

break wv PORTA 0x80 0xc0

Which will break when 10b are written to the upper 2 bits of Port A.
This is useful if you want to catch something happening there, but
don't care about the other bits.

- usart module reliably decodes, but still isn't really useful.

Scott

> Other features recently added:
>
> -  break on bit(s)
>
> break [c e | w | r | wv | rv | so | su | wdt [location] [value [mask]]
> ]
>
> now you can do something like:
>
> break wv PORTA 0x80 0xc0
>

This sounds like y kind of feature!!
can we get some details on what the other bits do.

other bits meaning -> c e w | r | wv | etc...

> Which will break when 10b are written to the upper 2 bits of Port A.
> This is useful if you want to catch something happening there, but
> don't care about the other bits.
>
> - usart module reliably decodes, but still isn't really useful.
>
that is one section I should look at one day.. I've written a software USART 
in parts here and there.

> Scott
>
>

matt
[ 2001 ]

On Mon, 23 Jul 2001, Matt Bowles wrote:

>
> This sounds like y kind of feature!!
> can we get some details on what the other bits do.
>
> other bits meaning -> c e w | r | wv | etc...

They're defined in help:

gpsim> help break
break [c e | w | r | wv | rv | so | su | wdt [location] [value [mask]] ]

        options:
                c   - cycle
                e   - execution
                w   - write
                r   - read
                wv  - write value
                rv  - read value
                so  - stack over flow
                su  - stack under flow
                wdt - wdt timeout
                    - no argument, display the break points that are
set.
   examples:
       break e 0x20       // set an execution break point at address 0x20
       break wv 0x30 0    // break if a zero is written to register 0x30
       break wv 0x40 0xf0 // break if all ones are written to the upper nibble
       break c 1000000    // break on the one million'th cycle
       break              // display all of the break points

HI Gnupic

I try to compiling gpsim 0.20.9b and not get nothing errors, but when run the gpsim
get this error.

Gdk-ERROR **: file gdkfont.c: line 504 (gdk_car_width_wc): as assertion failed: (w
ctomb(&c,character) == 1)
aborting...
Aborted (core dumped)

I understanding what is a problem with the fonts in GUI, but...what is I should to install
or reinstall?

greeting... :)

Nestor A. Marchesini
Chajari-Entre Rios-Argentina
ICQ # 50983752 nick colo
####@####.####

 

----- Original Message ----- 
From: Scott Dattalo ####@####.####
To: ####@####.####
Sent: Sunday, July 22, 2001 6:48 PM
Subject: gpsim-0.20.9b


> 
> http://www.dattalo.com/gnupic/gpsim-0.20.9b.tar.gz
> 
> This version supports the PCON register (among other things).
> 
> I was unable to create an rpm, or at least an rpm that worked.
> 
> Other features recently added:
> 
> -  break on bit(s)
> 
> break [c e | w | r | wv | rv | so | su | wdt [location] [value [mask]]
> ]
> 
> now you can do something like:
> 
> break wv PORTA 0x80 0xc0
> 
> Which will break when 10b are written to the upper 2 bits of Port A.
> This is useful if you want to catch something happening there, but
> don't care about the other bits.
> 
> - usart module reliably decodes, but still isn't really useful.
> 
> Scott

On Wed, 25 Jul 2001, Nestor A. Marchesini wrote:

> HI Gnupic
>
> I try to compiling gpsim 0.20.9b and not get nothing errors, but when run the gpsim
> get this error.
>
> Gdk-ERROR **: file gdkfont.c: line 504 (gdk_car_width_wc): as assertion failed: (w
> ctomb(&c,character) == 1)
> aborting...
> Aborted (core dumped)
>
> I understanding what is a problem with the fonts in GUI, but...what is I should to install
> or reinstall?
>
> greeting... :)

Nestor,

The fix is probably within gpsim and not your system. Can you give me
a back trace of the crash:

1) Start gpsim in gdb (the GNU debugger).

$ gdb /usr/local/bin/gpsim

Your path to the gpsim executable may be different than this. However
by default the executable gets stored here. After entering this
command you'll have the gdb command line prompt.


2) Invoke gpsim from within the debugger. The options are the same as
those you would have typed had you invoked gpsim at the command line
prompt

(gdb) run -s yourcode.cod

gpsim should now be running.  You should see the gpsim command line
prompt. So go ahead and run gpsim and do whatever it takes to crash
it! If there's a crash, gdb will take control and allow you to inspect
things.

gpsim> run

( crash )

When gpsim crashes you'll get the gdb command line prompt. Even if you
crashed in the bowels of some system library, it's possible to tell
where you last were inside gpsim by looking at the "backtrace" or bt:

(gdb) bt


This will printout something like this:
#0  0x00000072 in __strtol_internal (nptr=0x80cfb20 "E~\t@\210\004\b",
endptr=0x80d0430, base=0, group=0)
    at eval.c:60
#1  0x400753db in P17C75x::create_sfr_map (this=0x80cfb20) at
p17c75x.cc:350
#2  0x40074d68 in P17C75x::create (this=0x80cfb20, ram_top=8191) at
p17c75x.cc:300
#3  0x40074c99 in P17C75x::construct () at p17c75x.cc:276
#4  0x4007b7d6 in add_processor (processor_type=0x80ad4a8 "p17c75x",
processor_new_name=0x0)
    at pic-processor.cc:397
#5  0x40371a9e in cmd_processor::processor (this=0x40385c68,
processor_type=0x80ad4a8 "p17c75x",
    processor_new_name=0x0) at cmd_processor.cc:167
<snip>

If you send me this printout, Ralf or I can pinpoint exactly where
gpsim made the erroneous call.


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

If gpsim is crashing before the command line prompt even shows, then
you can try this:

$ rm ~/.gpsim

This will remove the configuration file that gpsim creates. It
essentially records where all of the windows were the last time gpsim
ran. You can erase this history if it turns out that only one of the
gui windows is causing problems.

Regards,
Scott