-
Logged In: YES
user_id=884387
Patch 1451520 (for gpsim 0.21.11) should fix this..
2006-03-16 18:24:54 UTC in gpsim - The gnupic Simulator
-
This patch is against the source for GPSIM 0.21.11.
It fixes the issue where only 7 of the 8 register file
address bits were being passed to the GUI, resulting
in incorrect display of instructions (TRISB as PORTB),
and incorrect execution of instructions (values being
placed in PORTB (0x06) instead of in TRISB (0x86).
The patch is against gpsim 0.21.11
To apply the patch, do the...
2006-03-16 18:22:31 UTC in gpsim - The gnupic Simulator
-
Logged In: YES
user_id=884387
Note: this only seems to be an issue when I "step" through
the code, but if I "run", the tmr0 field does indeed get
incremented.
2006-03-16 12:50:09 UTC in gpsim - The gnupic Simulator
-
An facility on the gui to see / set the external
clock frequency would be good. This would help with
debugging / viewing timing applications (for which
the frequency is probably the first thing that needs
to be verified)
Maybe this could be set up as a stimulus, in which
case, a lot of control would be offered.
2006-03-16 12:47:54 UTC in gpsim - The gnupic Simulator
-
The option to clear the "Simulation Time" field would
be good, especially when a "Reset" is done. This
would be particularly of interest when dealing with
counters, or "sleeping" for specific periods of time,
for example.
2006-03-16 12:44:21 UTC in gpsim - The gnupic Simulator
-
Logged In: YES
user_id=884387
How about one of the following:
1) Disable the "Over" command for "goto" (force the user
to use "step" in its place)
2) Add the breakpoint based on the target of the goto,
rather than just PC+1. This way we would get the expected
logical behaviour (go to the statement logically after
this one, but not necessarily contiguously after it).
2006-03-13 13:46:12 UTC in gpsim - The gnupic Simulator
-
I'm attempting to simulate an example from "PIC In
Practice" (new edition). This is a straightforward
example that uses TMR0 to implement a 1 second delay,
by setting the prescaler to 256 (with a 32KHz
crystal), and waiting for TMR0 to reach 32. This
doesn't work in GPSIM, because TMR0 does not seem to
increment with each instruction, so the code gets
stuck in the timer loop..
2006-03-13 11:04:06 UTC in gpsim - The gnupic Simulator
-
Logged In: YES
user_id=884387
I have a fix for this (14 bit processors). The basic issue
is that the 7 bit register file address was being passed
around as if it were the full reg file address, when in
fact its not (its an 8 bit reg file address). I have code
changes that do the following:
A - pass around the full 8 bit register file address,
allowing the GUI to correctly map the...
2006-03-12 11:14:32 UTC in gpsim - The gnupic Simulator
-
Logged In: YES
user_id=884387
It seems that in reg-instructions.c, the register address
is being decoded as a 7 bit address, and this works fine
for PORTB (0x06, 0b00000110) but in the case of TRISB
(0x86, 0b10000110), the leading bit of the ergister
address gets lost, resulting in the same address as
PORTB!! The core part of the fix seems to be to set
REG_MASK_14BIT to 0xFF, to...
2006-03-10 08:51:37 UTC in gpsim - The gnupic Simulator
-
Logged In: YES
user_id=884387
I've noticed almost the same thing: GPSIM version 0.21.11,
using 16F84. It manifests itself slightly differently for
me. I have some code that looks like this:
MOVLW 0xFE ;1111-1110
BSF STATUS, 5 ; move to bank 1, where TRISB resides
MOVWF _TRISB ; _TRISB EQU 0x0086
Now, in the program memory view, it displays the middle
instruction as "MOVWF...
2006-03-09 12:59:00 UTC in gpsim - The gnupic Simulator
