BS2 RAM allocation
Very new to the field. I would like for some one to assist me in understanding the memory registers. I have downloaded the free book, "Basic Stamp 2p" from Parallax. On page 22, it shows memory registers. On the left had side, you have 2 KByte detailed EEPROM map. The top row is 0-F ((I guess the 16 bits)). On the leftmost column are numbers like 7E0 etc. How does the row and column relationship work? The shaded area of course means the EEPROM has a program. Can you tell how much space in the EPROM has been used by looking at the shaded area.
In contrast, the right hand side shows a 32 byte RAM map. The top row is 15-0 (I guess the 16 bits). On the leftmost column are name of the registers, like INS:, OUTS: etc. The legend shows what portion is the loaded program and Undefined data. My question is, what is the relationship between the 16 bits and each of the registers? How do I convert the program shaded area into how much RAM is been used.
Then memory map discussion leads into an example of a debug code, "The following example demonstrates bi-directional communication on a
BASIC Stamp Activity Board:"
'{$STAMP BS2p}
serstring var byte(3)
loop:
DEBUG CLS,"D: Waiting for 3 chars from Debug Window..."
and so on....
After the start of the program the DEBUG command sends the string D: Waiting for 3 chars from Debug Window and the SERIN statement waits for exactly three characters.
What relationship the aforesaid has with the 32 byte RAM map?
Guys, I know I have asked a lot. I know that understanding this information is valuable, but I do not know how. Thanks
Regards,
NewStamper
In contrast, the right hand side shows a 32 byte RAM map. The top row is 15-0 (I guess the 16 bits). On the leftmost column are name of the registers, like INS:, OUTS: etc. The legend shows what portion is the loaded program and Undefined data. My question is, what is the relationship between the 16 bits and each of the registers? How do I convert the program shaded area into how much RAM is been used.
Then memory map discussion leads into an example of a debug code, "The following example demonstrates bi-directional communication on a
BASIC Stamp Activity Board:"
'{$STAMP BS2p}
serstring var byte(3)
loop:
DEBUG CLS,"D: Waiting for 3 chars from Debug Window..."
and so on....
After the start of the program the DEBUG command sends the string D: Waiting for 3 chars from Debug Window and the SERIN statement waits for exactly three characters.
What relationship the aforesaid has with the 32 byte RAM map?
Guys, I know I have asked a lot. I know that understanding this information is valuable, but I do not know how. Thanks
Regards,
NewStamper
Comments
The BS2 PBasic language lets you allocate those registers as any combination of bits, Nibbles (4-bits), Bytes(8 bits), and Words (16-bits) variables. The PBasic calls this "RAM", but really it's internal registers of the PIC chip.
Now, the PIC chip has programmed into it the PBasic run-time engine. This is Parallax proprietary -- one of the few Parallax proprietary things about Parallax. The Run-Time engine knows to take 'tokens' from the IDE when you press "Program", and store them in an on-module 2K eeprom. Once stored, they're 'non-volatile', they stay stored until reprogrammed.
The run-time engine also knows how to read tokens from the on-module eeprom, and use those tokens to select "run-time routines" from the on-PIC run-time engine.
So -- when you "Compile" a program on the IDE, the IDE tells you its prediction of how much eeprom will be used by that program -- it doesn't actually READ the eeprom. It also shows you how much register space will be used by your program.
The "INS" are a series of latches on the input side of the I/O pins. the "OUTS" are a series of output latches, and the "DIR" determines which set of latches the I/O pin is actually connected to. Usually you don't need to worry about these -- the INPUT and OUTPUT keywords, and HIGH and LOW keywords, will set the DIR to the desired state.
Oh, and the IDE assigns eeprom memory from the "top-down", meaning the largest address ($7FF) down toward zero.· Each 'box' on the memory map represents 8 bits, each 'line' on the memory map represents 16 bytes.· You can use the "WRITE" and "READ" and "DATA" keywords to store data starting from location zero up.· Note only "DATA" will show up on the memory map -- if you use "WRITE", you could be writing to anywhere, so the memory map predictor can't predict that.· And yes, you CAN over-write your program tokens if you're not careful, but don't do that.
One more thing -- "CON" constant assignments are the equivalent of a "#define" from C.· In other words, they don't take up any register space, anywhere a "CON" name appears in the code it is simply 'replaced' with the equivalent value.· So you can use "CON" names to make the purpose of your code clear (and make future edits easier) without using up precious register space.
Post Edited (allanlane5) : 2/19/2008 3:09:38 PM GMT
The memory map is simply a way to show how your program is stored in the EEPROM and what locations in RAM are used. Remember that RAM can be used as 16 bit words, 8 bit bytes, 4 bit nibbles, and individual bits and the first 3 words of RAM are also used as I/O registers with the bits corresponding to I/O pins. In the case of the EEPROM map, it's simply shown in rows of 16 bytes, and the column on the left gives the hexadecimal address of the start of the row displayed. The top row gives the address within the row.
To answer your 2nd question, the variable "serstring" is assigned a location in RAM by the Basic compiler. It is declared as a 3 byte array which occupies 3 consecutive bytes in RAM. I believe the compiler will first assign locations to variables declared as words, then those declared as bytes (or byte arrays), then nibbles, then bits. This is to avoid wasting space. If "serstring" is the only variable, it will be placed starting in the first byte after the I/O registers. The RAM map would show this after the program is compiled.
Very nicely written replies. Tonight, I will read it in detail and make some sense of all of this. Thanks