gnupic: Thread: Re: [gnupic] re: gpsim - GTK

On Wed, 2006-05-17 at 08:03 -0400, polly wrote:
> Thanks folks, that all does help enormously.
>    I'm trying to setup a working toolset for someone,
> working  off the packages available via
> Fedora-CCRMA .. the GTK/GTK+/extra/2 selections
> are a bit confusing.
>    Right now I can stop on a breakpoint but I must close
> the RAM window in order for 'step' to work; I'd try
> alternative GTK packages if I knew what to look for.

Hi Polly,

I haven't seen this bug where you must close the RAM window before single
step will work. As you know, gpsim's UI is quite quirky and sensitive to
deviations from what it expects. Can you tell me how you're loading the
simulation environment? For example, are you invoking gpsim from a command
line and supplying arguments there, or are you issuing commands from
gpsim's prompt, or are you trying to use the gui menus? Do you have a
gpsim configuration script? And finally which processor are you attempting
to simulate?


>  It's the ability to connect the PIC's gpsim'ed
> USART to, say, minicom during the simulation session
> I was hoping for, Manuel Bouyer put up a ptyusart
> routine in September,  doesn't Linux ( FC4) have
> pseudo terminals ?

Yes, Robert recently pointed this out to me. So as it stands, gpsim now
has three USART modules: Manuel's, the one in gpsim_modules, and the
gui-less one in gpsim/extras. Manuel's is derived from the one in
gpsim_modules. I'll take a look at rolling his extensions back into
gpsim_modules and making them work on Linux. Maybe I can convince Borut to
extend the pty to a Windows too.

Scott

On Wed, 2006-05-17 at 08:03 -0400, polly wrote:
> Thanks folks, that all does help enormously.
>    I'm trying to setup a working toolset for someone,
> working  off the packages available via
> Fedora-CCRMA .. the GTK/GTK+/extra/2 selections
> are a bit confusing.
>    Right now I can stop on a breakpoint but I must close
> the RAM window in order for 'step' to work; I'd try
> alternative GTK packages if I knew what to look for.

Hi Polly,

I haven't seen this bug where you must close the RAM window before single
step will work. As you know, gpsim's UI is quite quirky and sensitive to
deviations from what it expects. Can you tell me how you're loading the
simulation environment? For example, are you invoking gpsim from a command
line and supplying arguments there, or are you issuing commands from
gpsim's prompt, or are you trying to use the gui menus? Do you have a
gpsim configuration script? And finally which processor are you attempting
to simulate?


>  It's the ability to connect the PIC's gpsim'ed
> USART to, say, minicom during the simulation session
> I was hoping for, Manuel Bouyer put up a ptyusart
> routine in September,  doesn't Linux ( FC4) have
> pseudo terminals ?

Yes, Robert recently pointed this out to me. So as it stands, gpsim now
has three USART modules: Manuel's, the one in gpsim_modules, and the
gui-less one in gpsim/extras. Manuel's is derived from the one in
gpsim_modules. I'll take a look at rolling his extensions back into
gpsim_modules and making them work on Linux. Maybe I can convince Borut to
extend the pty to a Windows too.

Scott

On Wed, 17 May 2006 08:03:01 -0400
"polly " ####@####.#### wrote:

> Manuel Bouyer put up a ptyusart
> routine in September,  doesn't Linux ( FC4) have
> pseudo terminals ?

Linux has PTYs but the implementation is different from BSD. In particular, BSD has a natty little mechanism for passing IOCTL messages across a PTY, so Manuel's module could set the simulated baud rate according to instructions from the other end (minicom or whatever). This facility does not exist on Linux, and Manuel's code does not option it out so the build falls over.

The other problem is that the last version I saw pre-dates some stimulus changes that Scott made, so even with the BSD-isms removed it won't build with the latest GPSim from SVN.

On Wed, 17 May 2006 10:20:56 -0400
"polly " ####@####.#### wrote:

>    I'm using gtk+extra2-1.1.0-1.i386.rpm and   
> gtk+extra2-devel-1.1.0-1.i386.rpm
> and gpsim's SVN from yesterday. 

That sounds like a possible problem. I'm using gtk+extra-2.1.1, I think 1.1.0 became incompatible with GPSim some time at the tail end of last year.

I'm using GTK+ 2.8.8 as I had some weird text positioning bugs with 2.8.12 (the source browser was unusable). I didn't look into that too deeply because it happened to coincide with my getting horribly confused by a bug assigning integer values to float attributes (since fixed) so I've just lived with the work-around.

polly wrote:
> Scott,
>   Thanks again for your help, gpsim is my only protection
> against my own bone-headed PIC coding efforts.

Mine too sometimes.

>   I'm using gtk+extra2-1.1.0-1.i386.rpm and   
> gtk+extra2-devel-1.1.0-1.i386.rpm
> and gpsim's SVN from yesterday.

And Rob's comment about the version is definitely valid!

>                Here's the source:
> 
> // a-252-sim.c
> #pragma stack 0x200 256
> #define __18f252
> #include "pic18fregs.h"
> #include "stdio.h"
> 
> void main() {
> TRISB = 0x00;
> PORTB = 0xFF;
> //  dflt: T0CON == 0xFF
> //  clear 8~16 bit mode bit
> T0CONbits.T08BIT = 0;
> // clear extn~intn clock source bit
> T0CONbits.T0CS = 0;
> // Write timer
> TMR0L = 0xFF;
> TMR0H = 0xFA;
> }
> 
>   .. which I compiled using: sdcc -V  -mpic16 -p18f252

I tried it out too.

> 
>  I normally run gpsim from within emelfm file manager using:
>       gpsim -pp18f252  -s ${tDir1}/${tNam1}.cod
>  I''ve just verified the behaviour using root's xterm doing this:
>   </opt/src/18f>   gpsim -s ./a252-sim.cod
> 
>   get the main gpsim window,  Window Open Source Window
>   in Source broswer, a252-sim.asm shows fine, right click line 180, 
> line  following
>   MOVWF PORTB, press "run" sim halts correctly at that line.
>   Open Ram window, verify TRISB and PORTB ram contents correct.
>   Leave Ram window open, press "Step" nothing happens.
>   Close Ram window, PC Caret advances by itself.

I can almost guarantee that this is a gtkextra issue. There was a bug 
with gtkextra getting in an infinite loop updating the contents of a 
gtksheet cell.

> 
>   If I alternately close and open the ram window I can step through. 
> The  T0CON reg in the
>   ram window is not updating, which is the bit of code I was trying to 
> fix  in the first place.

I stepped through your code and verified that the registers are all 
getting updated and TMR1 is ticking. BTW, I think you may wish to write 
to the TMR1L and TMR1H registers *before* turning on the timer. 
Otherwise you run into the problem with TMR1L rolling over before TMR1H 
gets updated. (And this *is* happening in your code!)

Scott