gnupic: Re: [gnupic] Remarks to gpsim of 05/12/2006
Subject:
Re: [gnupic] Remarks to gpsim of 05/12/2006
From:
"Scott Dattalo" ####@####.####
Date:
19 May 2006 13:30:42 +0100
Message-Id: <60018.71.139.30.42.1148041389.squirrel@ruckus.brouhaha.com>
On Fri, 2006-05-19 at 14:01 +0200, Tobias Schlottke wrote:
> I downloaded the top svn version at 05/12/2006 and
> tested with the following small program:
<snip>
> It sets bit 0 of PortA as input,
> sets bit 0 of PortA to 1 and
> checks the state of bit 0.
>
> Right now its evaluated to 1, so movlw 53 is executed.
> That is not what I've expected. By default all inputs
> are read as 0, so even if I try to overwrite the value
> it should not change.
>
> But:
> ====
> If I connect a stimulus to the port gpsim behaves as
> expected, the bit is sampled as 0. Unfortunally the
> change of the state of the port is not visible in the
> breadboard window. So gpsim behaves like the real
> world: undefined pins are evil....
Hi Toby,
gpsim makes an attempt to accurately model I/O pin states: even the
unknown ones. The simulation engine (which is separate from the gui)
contains a "bit state" for I/O pins. You can examine the state with the
stimulus command at the command line. Currently these are the bit states
supported:
H - High
L - Low
W - Weak pullup
w - Weak pulldown
Z - High impedance
X - unknown
Part of the confusion I think is that the gui really only conveys the 'H'
and 'L' states and not the others. In your particular case, the I/O pin
for porta 0 is in the Z state. The gui (apparently) interprets this as a
low. When your program reads the I/O port it interprets this as a high.
Which is right? I don't know, but I do know that the lack of consistency
between the two cannot be correct!
Of course, when you connect a stimulus to the I/O pin the ambiguity is
resolved.
BTW, gpsim can even model an unknown bit state. However this is not fully
supported for the PIC processors.
Scott
