BS2p24's 16KB EEPROM and Memory Map

Pascal P

Hello,

I recently·bought a BS2p24 to replace the·BS2 I had·because my code filled up all of the BS2's 2KB memory.
However, when I open the Memory Map in the BASIC Stamp Editor, it looks like·it's still only showing 2 KB of memory·(largest address is still $7FF) instead of the expected 16 KB and my code is still filliing it up.
I checked the EEPROM on the IC and it is·a 24FC128 which I think is a 16 KB so I'm confused.
Does the Memory Map only shows the first 2KB of the EEPROM regardless of its size?
or·am·I doing something wrong?
Any help on how I could use the full 16 KB memory of the BS2p24 would be greatly appreciated.
Thank you very much,
Pascal

TinkersALot

the memory is divided into pages. You will need to locate some of your code into other "memory segments" (called slots in pbasic parlance) if memory serves. See :

http://forums.parallax.com/forums/default.aspx?f=21&m=350949

or

http://www.emesystems.com/BS2SX.htm

for some background information on this topic. Hope this helps.

iDave

Yes, there 8 slots of program memory...2k each. So when your checking the memory map it's just showing u slot 0. ( goes to slot 7) Each slot can call up any other slot on demand, so it can act as one cohesive prog.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"THE ONLY TRUE WISDOM IS IN KNOWING YOU KNOW NOTHING." - SOCRATES

Pascal P

Thank you both. That's very helpful. I've downloaded the·MultiSlotProgramming.zip file and I'm going through it.

One question I have after looking at the slot0.bpe part of the program is about variables.

I noticed on the Memory map that there are some Defined Data at the top (5 light blue rows).

Are those variables that didn't fit in the RAM? If not, what are they?

I am asking because variable space is something I am struggling with. I try to limit my number of variables to whatever can fit in the RAM and it's pretty tight.

Any advice would be helpful.

Thank you very much,

Pascal

TinkersALot

Hi Pascal,

If you are referring to this section of the program code:

'

---

[noparse][[/noparse] Variables ]
'
' NOTE: These variables are assigned like this to give a
' good mix of different variable types in the global
' space. With this mix, the entire ram is allocated
' However, each slot may want to have local names
' for these variables so that the code in those
' slots is more readable. This is supported SO LONG AS
' the ordering of these variable allocations IS CONSISTENT
' across all slots
'
ExecutiveControl VAR Byte

CurrentTaskSet VAR Word ' CurrentTaskSet is "local name" for GlobalWord01
GlobalWord02 VAR Word
GlobalWord03 VAR Word
GlobalWord04 VAR Word

NextSlotToRun VAR Byte ' NextSlotToRun is "local name" for GlobalByte01
ExecutivePrioritySet VAR Byte ' ExecutivePrioritySet is "local name" for GlobalByte02
ExecutiveSetIndex VAR Byte ' ExecutiveSetIndex is "local name" for GlobalByte03
GlobalByte04 VAR Byte
GlobalByte05 VAR Byte

GlobalNib01 VAR Nib
GlobalNib02 VAR Nib
GlobalNib03 VAR Nib
GlobalNib04 VAR Nib
GlobalNib05 VAR Nib

GlobalBit01 VAR Bit
GlobalBit02 VAR Bit
GlobalBit03 VAR Bit
GlobalBit04 VAR Bit
GlobalBit05 VAR Bit
GlobalBit06 VAR Bit
GlobalBit07 VAR Bit
GlobalBit08 VAR Bit

' The following are reserved for use with
' the message queue
'
MsgQueueRouteInfo VAR Byte
MsgQueueMessage VAR Byte
Counter VAR Byte
MsgQueueCount VAR Byte
MsgQueueTarget VAR Nib
MsgQueueSender VAR Nib

' The following are reserved for use with
' data reads
'
DataPage VAR Nib
Offset VAR Byte
DataLength VAR Byte
DataByte VAR Byte


As I describe in the comment block, I simply carved the entire shared RAM memory space into some kind of arrangement. Then I "pasted this arrangement" into all slot programs such that they "started with this same footprint" .

Some of the variables became common across all slots, while other variables were "slot private" variables. If you look at the various slot programs you will see that some of these "standard variables" were given "slot local names" but the "overall mix of variable type/locations does not change. This is one attempt to maximize the use of the very limited amount of RAM where I knew which of these shared/common locations I could hijack for the use of the program in the active slot.

You will also notice that each slot uses GET PUT calls as a means to store "slot private context values". This may be a means to "expand your memory" as well. Define standard locations where you will put values to "pass and share between slots" into memory at a specific location. Then as each slot runs it can GET PUT values as another way to pass/share these values without using up the very limited 128 bytes of main RAM area.

I hope this help -- but it not, just ask and I'll try my best to answer your questions.

Pascal P

Hello,

Yes, that was the area I was refering to.
And it does help but I'm wondering if I might be a bit in·over my head here.
It looks there are two separate things I am trying to understand.

The first one·is the carving of the 128 bytes of RAM as described in your program.
This·is·where the variables declared using VAR are stored and these are accessible from any slot program as long as the same number and type of variables have been declared in each program. Is that correct? And these, we only have the 128 bytes of RAM to declare them and that's it.

The second·part is about the use of GET,PUT & STORE·to access the Scratch Pad RAM (SPRAM).
That gives you up to another 127 bytes of room (for the BS2p, pe, px) where you can store variables although you can't really declare them as is. Instead you have to refer to them by their physical address in the SPRAM. Is that correct? and now, are those the ones we·see in·light blue at the top·of the slot0·EEPROM Map in the Memory Map window? Or is the SPRAM not visible via the Memory Map window?

Please don't hesitate to tell me if these·are stupid questions.
Cheers,
Pascal

Mike Green

You don't get 128 bytes of RAM. You get 26 bytes just like all the other Stamps. The scratchpad RAM gives you another 127 bytes that you can access with the GET and PUT statements (only). The scratchpad RAM doesn't appear in the Memory Map window and there's no way to use the Stamp Editor to allocate scratchpad RAM space. You can define named constants with the CON statement and use those with the GET and PUT statements as a way to associate names with scratchpad RAM locations.

TinkersALot

Thank you Mike Green for clarifying my mis-statements about memory space. I am sorry that I mis-quoted the values--especially if that has confused the discussion any. Now, for Pascal, let me see if I can answer your questions and hopefully provide more clarity.

Regarding: "This is where the variables declared using VAR are stored and these are accessible from any slot program as long as the same number and type of variables have been declared in each program. Is that correct?" Yes. Further, each slot has access to the same set of shared register area (look at as global memory that can be read/written by all slots). That being the case, if you don't want one slot to "walk on the values" of the registers in another slot in strange and unpredictable ways, then I think it would be best to have all slots have the same "view" of these registers.

Consider the following:

slot 0 carves up the registers as bytes, but slot 1 carves up the same registers as words. When slot 0 runs and modifies any of these variables (as bytes) then the "word values" that "overlay the same location" could get some strange values when slot 1 runs. Does that make sense?

That being said, when I conceived of the sample, I thought it "best" to carve up the space in a way that provided me with a "mix" of different types of variables in the register set. There is no reason that you need to retain this same layout and/or carving up of the register space. It was only here for my sample. I am sorry if that decision has caused any confusion toward your own application.

Your statements about GET/PUT are correct. The scratchpad allows you more space to store values that aren't declared. This is another way that you can "stretch" the registers. In that, you can GET them as needed into a register work with them, and then when you are "done" you can PUT the modified values back into the scratchpad. If you have a "memory intensive" program, then this technique can allow your application to not "get cramped" by the much limited register space.

Using DATA for all of your "static data" can be a useful technique to·make your program code smaller. However, if you have large amounts of data you should consider putting that data into a "data only" slot if your program and its data cannot fit in the same slot.

I hope the attached image also clarifies some of your questions as well.



I have attached an image with some comments that I hope will be useful

Post Edited (TinkersALot) : 8/27/2009 5:23:01 AM GMT

Pascal P

Hi ThinkersAlot & Mike,

Thank you very much for taking the time to answer my questions and even make a graph for it.
It's much clearer now and I think·I·know what goes where.

And·I did write it wrong, I realize the·RAM has 26 bytes, not 128.

Thanks again for your help.
Take care,
Pascal·