gnupic: Trouble with gpsim, WDT, and TMR1H
Subject:
Re: Trouble with gpsim, WDT, and TMR1H
From:
Jeff Jackowski ####@####.####
Date:
30 Nov 2004 07:41:37 +0000
Message-Id: <Pine.OSF.4.44.0411300020410.971458-100000@ant.hiwaay.net>
On Mon, 29 Nov 2004, Scott Dattalo wrote:
>The RPMs are really old. I'm pretty sure the config bug has been fixed,
>but I don't about the TMR1H one.
>
>Here are a couple of suggestions:
>
>1) Uninstall the RPM and install a more recent tar ball.
>2) Check the code out from CVS and install that.
>3) Try gpsim out on Windows. Borut has been creating up-to-date snap
>shots, so all the recent fixes will be there. Installing is really
>painless since all of the dependencies have been packaged into the
>installer.
>
>Scott
I managed to build gpsim from the tar ball. When I tried it again, I
noticed that gpsim printed out a line indicating the correct config word,
0x3F41, but still claims the WDT is enabled.
The timer 1 problem seems to be solved. My code does set the value for the
timer and then enable it, which caused the value in gpsim to change to 1.
Is this how the hardware works? I can't find mention of resting the timer
1 value when it is enabled in the documentation from Microchip.
As I followed along in gpsim, I saw a conditional produce what appears to
be incorrect results. The intent was to check the status of the timer 1
interrupt enable bit. The code, both the C source I wrote and the assembly
output, look correct. Bits 5 & 6 at address 3 are already clear. Set bit 5
at address 3, test bit 0 at address C (8C). gpsim claims the tested bit is
in the byte file_register and reads a value of 0 when the RAM window shows
1 for address 8C.
With all this scrutiny, I spotted the bug I was tracking down in my code.
I tested on the test hardware and got results closer to what I want. I'm
fairly sure that means the conditional I mentioned above is being run as
intended on the hardware.
--
Jeff Jackowski
http://ro.com/~jeffj/
