Built-in constant signifying first program address
Archiver
Posts: 46,084
Is there a constant built into PBASIC 2.5 that holds the first address in
the EEPROM where program data is stored? As is always the case, my program
is stored at the end of the EEPROM, and I have a look-up table stored from
address 0 through some number (which is another constant at compile time). I
would like to use the remaining memory for data logging, and I don't want to
overrun the available space and write over my program. Perhaps the WRITE
command automatically fails when this tries to hapeen, but I want my program
to respond to this condition.
Thanks,
Steve
the EEPROM where program data is stored? As is always the case, my program
is stored at the end of the EEPROM, and I have a look-up table stored from
address 0 through some number (which is another constant at compile time). I
would like to use the remaining memory for data logging, and I don't want to
overrun the available space and write over my program. Perhaps the WRITE
command automatically fails when this tries to hapeen, but I want my program
to respond to this condition.
Thanks,
Steve
Comments
I've been able to get around the (possible) limitation of having no run-time
constant of where the program memory starts. I think it may be simple to
inlude a contant address reference that is updated during a final pass of
the compiler to include a "FirstFreeAddress" type reference that points to
the first byte after pre-defined data, and a "LastFreeAddress" that
references the last byte before the stored program.
Also - For debugging purposes, it would be wonderful if the IDE could read
back the EEPROM into the PC to a file, or even a dialog box that would looks
like the memory map box (CTRL-M), which could then be viewed with a HEX
editor.
My code looks as follows (I update the number of byte reserved by
FirstFreeAddress by running CTRL-M, changing the number, running CTRL-M,
changing the number, etc., until I get the full available free EEPROM for my
program to use):
'The following is my lookup table (well, a representation)
DATA WORD 0
DATA WORD 1
DATA WORD 2
FirstFreeAddress DATA (100)
LastFreeAddress DATA 0
Main:
{do some stuff}
GOSUB WriteData
{do some stuff}
GOTO Main
WriteData:
IF WhereToWrite < LastFreeAddress then WriteIt
HIGH Error_Pin
return
WriteIt:
HIGH Writing_Pin
WRITE WhereToWrite, SomeInfoInByteForm
WhereToWrite = WhereToWrite + 1
PAUSE 10
LOW Writing_Pin
return
Original Message
From: "Steve Ziuchkovski" <zman97211@y...>
To: <basicstamps@yahoogroups.com>
Sent: Tuesday, June 24, 2003 4:08 PM
Subject: [noparse][[/noparse]basicstamps] Built-in constant signifying first program address
> Is there a constant built into PBASIC 2.5 that holds the first address in
> the EEPROM where program data is stored? As is always the case, my program
> is stored at the end of the EEPROM, and I have a look-up table stored from
> address 0 through some number (which is another constant at compile time).
I
> would like to use the remaining memory for data logging, and I don't want
to
> overrun the available space and write over my program. Perhaps the WRITE
> command automatically fails when this tries to hapeen, but I want my
program
> to respond to this condition.
>
> Thanks,
> Steve
>
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>the EEPROM where program data is stored? As is always the case, my program
>is stored at the end of the EEPROM, and I have a look-up table stored from
>address 0 through some number (which is another constant at compile time). I
>would like to use the remaining memory for data logging, and I don't want to
>overrun the available space and write over my program. Perhaps the WRITE
>command automatically fails when this tries to hapeen, but I want my program
>to respond to this condition.
>
>Thanks,
>Steve
I don't think there is a direct documented way to get the last eeprom
address used by the program. You already have a way to do it at
compile time by looking at the CTRL-M screen or by pushing for the
"out of memory" error. The BS2p and BS2pe are nice for this kind of
logging, because there is so much extra memory available, and you can
get at it directly using the STORE command. I'm spoiled!
At run time, there is nothing to prevent you from destroying your
program with a misplaced WRITE!
One thing that would probably work at run time would be to scan the
program memory to find the first occurrence of 16 successive zero
bits. I don't think 16 successive zeros can occur in the program
tokens, unless you string out more than two END instructions in a row.
y var byte
x var byte
read $7ff,x
for adrs=$7fe to $000 ' scan down through program
read adrs, y
if y=0 and x=0 then donetest
x= y ' previous=current
next
donetest:
debug " the first free byte below the program is: ", ihex adrs,cr
Warning--theory!
Another trick method, maybe: The highest addresses in PBASIC tokens
(from $7ff down) consist of the branch table, and each entry in the
branch table is 14 bits. The first entry in the branch table (at
$7ff) refers to the location where the program will start executing.
The execution address will be the first address following the branch
table. The other entries in the branch table are the actual the
return addresses for each and every GOSUB in the program, in the
order that they appear in the program. So, it seems to me, you could
put a dummy GOSUB at the very end of your program, one that will
never be executed. But the compiler will generate an entry in the
branch table for it just the same, and that address (resolved to the
next byte boundary) will point to the first free location after the
program. To retrieve it at run time, you would have to read the
execution address from location $7ff:$7fe, and then read the 14 bits
_prior_ to that execution address to get the location of the dummy
GOSUB return target. It might work. Interesting to think about it.
Again, I haven't tried it. The layout of the Stamp memory is
described in Brian Forbes' book.
-- regards,
Tracy