gnupic: Re: [gnupic] gpsim weirdness
Subject:
Re: [gnupic] gpsim weirdness
From:
John De Villiers ####@####.####
Date:
30 Dec 2005 08:25:34 +0000
Message-Id: <1135931078.4886.181.camel@bbj.inet>
On Thu, 2005-12-29 at 02:21, Scott Dattalo wrote:
> > On Wed, 2005-12-28 at 23:25, John De Villiers wrote:
> >> Im having a terrible time getting a program to simulate correctly.
> > And here comes the file - at last
> I tried your modified LCD driver with the latest version of gpsim and the
> LCD module. I can also confirm that this code is failing. It's not obvious
> to me if the problem is with gpsim (and the LCD module) or with your code.
> What I can say is that the unmodified version of the LCD driver (the one
> that is part of gpsim's LCD examples) works correctly. It appears that
> your version fails during the LCD initialization at the point where ASCII
> spaces are written to the display. For some reason the LCD ready bit is
> not getting asserted while the 4'th ASCII space is being written.
>
I've cleared all the processor specific settings in then stc file and it
still does the same.
The finding of include files now work fine BTW.
I get a message " List file rctank.lst wasnt in .cod " immeditely after
Added new file named: rctank.lst id = 6
Then is does POR and shows a message "Internal RC oscillator", yet my
config bits are set for HS_OSC. Is this a problem?
Found some more "issues".
The stack window displays the wrong name ( the return address is
correct but the name ( the bit between backets is wrong ). Run the
simulation and see the name it gives when entering the convertbcv
function. On mine it showed LCD_INITIALIZE when it should be showing
convertbcv ?
When the RAM window is open all other windows stop updating until the
RAM window is closed again. If gpsim is exited with the RAM window open,
and then restarted, the other windows all freeze as soon as the RAM
window starts. Closing it allows the other windows to complete their
initialise. The RAM window does not show any updates when stepping
through the code.
> BTW, I did find a new gpsim segv while debugging your code. A recent
> change to the break point code makes the assumption that all ram data has
> an associated symbol table entry. However, gpasm's local symbols do not
> get put into gpsim's symbol table. Consequently those registers *do not*
> have symbols. If you attempt to set a break on one of these gpsim would
> crash. Any way, I fixed this and will check it into CVS shortly.
>
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
