PICAXE 8M memory allocation, confusion

[gbrusseau]

After writing the code for a program, the PICAXE 8M compiler says there is still 96 bytes available for use, but if I try to fill those 96 bytes with the DATA directive, the compiler error message says “memory location already used” before I have filled up all 96 bytes with data. I get to where there is 37 bytes left, but adding one more byte in the DATA directive, produces the error. Whats up with that?

“With the PICAXE-08, 08M, 14M and 18 the data memory is shared with program
memory. Therefore only unused bytes may be used within a program. To
establish the length of the program use ‘Check Syntax’ from the PICAXE menu.
This will report the length of program.”

 

[manuka]

Suspect you're up against von Neumann architecture- the computer design model that uses a processing unit and a single separate storage structure to hold BOTH instructions and data. (08/14/20M PICAXEs all share their 256 byte RAM this way)

It's thus possibly a PICAXE case of EEPROM DATA storage "eating" into memory locations that are already used for the program. If you're really short of 08M storage, suitable POKE/PEEKing may help, but please list your program for our insights first, as it may well be a different woe entirely.

 

[gbrusseau]

The part I don't understand is that if the compiler says there is still 37 bytes free for program use or data storage, why does one more byte used, result in the error message. Shouldn't the compiler then say I still have 36 bytes free.

Could this have something to do with oil futures.

 

[BCJKiwi]

As suggested, post your code.

Only then do we have a chance to determine what may be happening.

When you say "data directive" do you mean the command eeprom (also known as data) Manual2 page39?

 

[hippy]

I concur; post the code.

This problem doesn't usually occur so it could be down to something you're doing in this specific case. In particular if you have placed DATA at a specific address in memory that can subtly reduce the amount of memory available. For example this one line program on an 08M ...

- DATA 252,("A")

Reports it has only used 4 bytes, but you won't be able to add any executable statements to that program without getting an "Eeprom location already used" error.

 

[Dave E]

Hippy,
Please explain.

Dave

 

[BCJKiwi]

I guess the answer is that the program loads from the top down, leaving space for data from the bottom up.

e.g.

#PICAXE 08M
DATA 212,("A")
main:
let b1 = 1
goto main

is accepted by the syntax checker whereas

#PICAXE 08M
 
DATA 252,("A")
main:
let b1 = 1
goto main

fails

If you extend the test by lengthening the program in the first snippet, you will find you will need to keep reducing the "212" to make room for it.

Have attached a spreadsheet giving all the relevant memory info for the PICAXE chips as per the Manuals. Trust it is correct but would welcome any constructive comment/additions etc.

 

[212]

I can confirm 212 takes up a lot of space

Sorry, couldn't resist

 

[moxhamj]

What a crack up! ROTFLOL

 

[BCJKiwi]

Perhaps we should just keep reducing '212' to zero?

 

[Dippy]

Well, if he continues flashing and exposing in the Texas wilderness then sooner or later he'll get arrested.

 

[hippy]

To expand on BCJKiwi's answer; code and data share the 256 byte Eeprom space but to make it simple to use for the programmer, data locations are numbered in reverse order to the code locations, so DATA and EEPROM commands fill the area in reverse from the bottom up. READ and WRITE commands automatically handle this so it looks like both code and data is stored in ascending order 0 to 255 ...

          Code              Data
        .---.---.         .-------.
      0 |   |   |     255 |       |
        |  \|/  |         |       |
        |       |         |       |
        |       |         |  /|\  |
    255 |       |       0 |   |   |
        `-------'         `---^---'

If DATA 128,("A") is used, that uses location 128 in the data area which is also location 127 in the dode area. As code can only be held in contiguous locations code can only then be in locations 0 to 126, so this has reduced the code space available. The "Eeprom location already used" error is when the Programming Editor tries to add the 127th byte of code.

          Code              Data
        .---.---.         .-------.
      0 |   |   |     255 |       |
        |__\|/__|         |_______|
    127 |       |     128 |  /|\  |
        |       |         |   |   |
    255 |       |       0 |   |   |
        `-------'         `---^---'

Although only one byte has been used in the data area it marks all data area from 0 to that location as data and becomes unavailable for use as code.

 

[gbrusseau]

Everything you all are saying is as I believed how the world turns, but my program is haunted. Take a look at it and please exorsize for me.

Thanks

 

[BCJKiwi]

OK, I'm confused.

Copied the posted program into the Programming Editor.

It simulates fine and if you turn on the memory panel in the simulator you can see the memory allocation as discussed. However there are only 4 bytes free between the data and program areas.

this may be a bit tight as the simulator memory size estimate is not necessarily exactly the same as the size when loaded into the chip (page boundaries etc etc).

When exactly does the compiler show the error?

Have you tried (as a test) reducing the data size slightly to see how many bytes the data needs to be reduced to make it all fit?

 

[hippy]

There are 144 bytes of data used, 108 bytes of code used and 4 bytes left spare.

The problem / confusion seems to be that the Programming Editor reports 218 bytes used rather than 252 bytes used which is the real score, a discrepancy of 34 bytes.

I recall there's been some discussion on this before and, if I remember right, it comes down to data bytes which are zero not be counted as used even when they are. Looking at the program there seems to be about 32 bytes of data which are zero ( plus two bytes of hidden code which will be zero at the end of code ), so that would make everything add up.

Put it down to the Programming Editor not being able to count and giving inaccurate information.

 

[gbrusseau]

I knew this had something to do with oil futures! Those on-line oil speculators have programmed the compilers to lie about the real numbers.

I ran the simulator, for the first time, and its as plain as the nose on my face. I'm indepted to all simulator pros out there. I didn't even know there was a memory panel.

I am a little disappointed the program isn't haunted though. What a wierd thread that would be.

Thanks all of you