gnupic: Re: [gnupic] re: gpsim - GTK
Subject:
Re: [gnupic] re: gpsim-GTK
From:
Scott Dattalo ####@####.####
Date:
18 May 2006 16:49:28 +0100
Message-Id: <446C9782.4040108@dattalo.com>
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
