Subject:
Re: gpsim
From:
Scott Dattalo ####@####.####
Date:
26 Jan 2002 16:47:31 -0000
Message-Id: <Pine.LNX.4.33.0201260811410.25900-100000@ruckus.brouhaha.com>
John,
You've brought up some interesting points. I hope you don't mind that I've
cc'd my response to the gnupic mailing list (see http://www.gnupic.org/
for info on how to join the list).
On Sat, 26 Jan 2002, John Sheahan wrote:
> Hi Scott
>
> been playing with gpsim a bit for a couple of pic projects I have.
> under linux of course.
>
> definitely a step up on the cook - 16f84 - try - think - fix - reburn loop
> I like it. but I'm too anti-windows to use mplab
>
> found a few minor issues, wondering which way to proceed.
>
> Are you currently maintaining the code?
>
Absolutely.
> would you prefer bug descriptions or patches?
Patches are preferred. However, if you see a bug, don't feel obligated to
create a patch.
>
>
> I'm more a perl / script / assembler person (really a hardware
> designer) but I have to finish learning c one day :)
>
>
> things I have noticed so far:
>
> I'm using gpsim-0.20.12.tar.gz (whoops, thats old I now notice, you
> must be workng on same)
>
> o eerom window stays blank if it comes up before the pic type is defined and
> code loaded.
I haven't seen this because I invoke gpsim different than you.
From the command line:
gpsim -s file.cod
This loads the .cod file when gpsim is invoked.
>
> o stimulus, pullup on a dedicated input port not obvious to model.
> I ended up just modifying the reg contents
I'm not sure what you mean here. It is possible to attach a pull up (or
pull down) resitor to an I/O pin. This is done via an external module.
>
> o setting a symbolic register seems to be two step
> ie first find the address, then set it.
From the command line you can use the 'x' command. E.g. here is a
cut-n-paste session illustrating the 'x' command.
gpsim> x temp
temp [0x34] = 0x0
gpsim> x temp 4
gpsim> x 0x34
temp(34) is 4
gpsim> x 0x34 5
temp(34) was 4 now is 5
In the gui, you can click on a cell in the register window and directly
edit a register. (Unlike MPLAB where you have to bring up a dialog window
to edit a register).
>
> o register viewer window seems not to always reflect reg contents, but
> watch window is good. And I'm not sure how to repeat this.
Hmm. Are you sure? I suspect that a few of the special function registers
may not get updated, but they should! If you can repeat this, let me know.
> o doing a table string lookup with
> GetInitChar
> addwf PCL,F ; Jump table
> the pc address seems to be calculated as (pcl) & 0xff
> ie high byte is set to 0 instead of unchanged.
> So this works in the first 256 bytes, then clags out.
This is the way PICs work. You need to set the PCLATH register too and be
aware when your table spans the 256 byte boundary.
>
> o cannot figure out how to load a cod file from the cmd line.
> works from the gui.
See above.
> o reset appears to leave enough states unreset its better to quit and restart.
This is true. In CVS, I've changed the way reset is implement so that this
issue can be addressed. Before, a reset would basically zero the program
counter and set a few status bits. However, Peter Onion reported a bug
with Reset/WDT/Sleep that led me to redo the reset logic. I added a new
member function to the register base class that gets invoked when a reset
occurs. All I have to do now is go through each register type and write
the reset logic code. Simple, but tedious. For the moment, the
quit/restart approach is the best way.
>
> o doc/feature related, is there a way to step through a subroutine call?
> ie, tracing at higher level, is there a 'next' button that does a
> step for an instruction, and sets a temporary breakpoint on the next
> code address for a call?
at the command line
gpsim> step over
In the source browser,
right click to bring up a window and select the step over option
OR
press the letter 'o' while the source browser window has focus
OR
press 'F8' while the source browser has focus
>
> o doc/feature related
> when single stepping, is save_state and restore_state practical, so
> that a backup button could be implemented?
> I get a bit carried away stepping, particularly is I want to fudge
> registers and test a routine
That's interesting you mention this. This was one of the original design
goals of gpsim. (In fact, I think it's still buried in the TODO). I
desired this feature because of my experience with MPLAB. MPLAB was so
slow that it took a long time to reach a state in the simulated program.
So I wanted to step forward across a crucial state, see what happens, step
backwards, change a condition, and step forward again. While writing
gpsim, I found this very difficult to implement. One of the problems with
it is that all state machines need to run forwards AND backwards in time.
In many cases it's hard enough to get them to just run forwards properly!
After using gpsim as a development tool, I found the running backwards
feature was not really needed. gpsim is so fast that for most cases it's
easy to just let the code loop and set a break at the point of interest.
-----
These are all very good suggestions and observations, John. I'm currently
in SDCC mode and will not be working on gpsim for the next few weeks. The
next items I plan to address with gpsim are:
* Fix the readline install problem
* Document the module interface
I'm also falling behind on Craig's work and suspect that I'll need to
address the new features of gpasm/gputils too.
Scott
