gnupic: asM files
Subject:
Re: asM files
From:
Scott Dattalo ####@####.####
Date:
8 Feb 2000 12:05:45 -0000
Message-Id: <Pine.LNX.4.05.10002080522410.8026-100000@tempest.blackhat.net>
On Tue, 8 Feb 2000, Matthew Bowles wrote:
> O.k
> Dumb question No. 1...
>
> how do I load asm files. Does gpsim work seperately to the compiler, or
> can I load .asm files... I mean.. there is an asm browser with gpsim..
> but ' load blah_blah.asm' does nothing.
This is by no means a 'dumb' question. Most people who use gpsim have had
prior experience with MPLAB. However, as Linux gets more and more popular,
I can see gpsim becoming the first PIC simulator to which beginners will
be exposed. I've made no effort so far addressing this up and coming group
of users. So perhaps a tutorial explanation of a few different debug
sessions is in need...
To get you going for now though,
The .asm file contains the pic source code. gpsim doesn't know how to read
this directly. It's first necessary to 'assemble' the .asm file with
gpasm:
$ gpasm my_file.asm
gpasm will read your .asm file, check its syntax, and if everything is
okay will produce three new files:
$ ls my_file*
my_file.asm my_file.cod my_file.hex my_file.lst
The .hex file is an ASCII file that's commonly used by device programmers.
In other words, when you down load your code to a real pic, this is the
file you'll be sending. It looks something like:
:10000000D89B096B100E076F086B006B016B12EC2D
:1000100000F0000007510127D8B0002B085100273D
:1000200007EF00F000510F0B00B90F085E0FF66EDE
:100030000935000FF76EF86A0900F550026F0800E5
:10004000F55C066FF00E01150603F450F3BEF428BC
:1000500000A9022500B9F55C00BB00081200000CE5
:100060001925313C47515A626A70757A7D7E7F004E
:00000001FF
Without going into detail, suffice it to say that this describes what
opcodes go at which addresses.
Now gpsim can read a '.hex' file. But in most cases you don't want to do
this because there is no symbolic information. Here are the steps to load
a hex file in gpsim:
gpsim> processor p16c84
gpsim> load h my_file.hex
Basically, you need to specify a processor then load the source.
The .lst file is also an ASCII file. However, it cannot be (directly)
loaded by gpsim. Its purpose is to display all of the information that the
assembler has produced in a form that's human readable.
The .cod file is a binary file that contains both the opcodes of your pic
source and the symbolic infomation. This is the one that you'll mostly
likely want to use. The syntax for loading .cod files into gpsim is:
gpsim> load s my_file.cod
or at invocation:
$ gpsim -s my_file.cod
Notice that you don't need to specify the processor. That information is
already contained the .cod file. Also contained in .cod file are the names
of all of your symbols (e.g. EQU's, CBLOCK's, address labels, ...) and
cross references between the pic opcodes and the source file line numbers.
Ralf and I have attempted to provide complete access to this symbolic
information. For example, the 'source browser' window is your source file
along with links to the pic opcodes that gpsim is simulating. Double-click
in the 'break column' (the far left column of the window) and you'll set a
break at that instruction. Or from command line you could do this:
gpsim> break e start
break at address: 10 break #: 1
and that will set an execution break point at the address associated with
the label start. (The second line is what gpsim prints.) If you want to
know this address (it will get displayed when you set the break, but..)
you can type:
gpsim> symbol start
start at address 0x10
Is this clearer?
Scott
