OK, so where did my runtime memory go...

CannibalRobotics · 2008-10-15 20:54

If I 'view info' on a set of compiled objects I'm told I have 6,169 longs free.
When I add this piece of code to the top object:

if LatchData & %0000_0000_1000_0000_0000_0000_0000_0000· > 0
·· repeat i from 0 to 7
···· ADMin[noparse][[/noparse]i] :=255
···· ADMax[noparse][[/noparse]i] :=0

I get a the error "Object exceeds runtime memory by 9 longs." and the compiler stops.
Go figure...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A wise man told me; "All electronics are made to work by magic smoke.

Don't ever let it out as it's·very difficult·to get it back in."

StefanL38 · 2008-10-15 20:58

It's hard to reproduce this error without having the complete code

CannibalRobotics · 2008-10-15 21:01

That would be allot of code.
I guess the question is why would such a small addition have such impact?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A wise man told me; "All electronics are made to work by magic smoke.

Don't ever let it out as it's·very difficult·to get it back in."

StefanL38 · 2008-10-15 21:15

Again how should I try to analyze it without having the code ?

use the archive-function of the proptool to zip ALL files that were needed and attach this to a posting using the attachment manager
which will appear after clicking on Post Reply instead of using the quick-reply function

best regards

Stefan

Mike Green · 2008-10-15 21:47

Make sure you have the most recent Propeller Tool. I think it's version 1.2.

schwiegjc · 2008-10-16 15:58

I had a similar problem. The size of the program was well below the 32K RAM, but reported the same problem. I tried the Version 1.2 and problem was not resolved. My main program had a couple of local functions that I moved into an object instead which resolved the problem. It might just be that the structure of the program needs to changed. Reducing the size of the main program and calling objects might be the fix.

CannibalRobotics · 2008-10-16 16:47

OK, I'm using version 1.2 of the compiler. I had tried the cross object fix to some success before.
I am using the Graphics object but none of the sprite management or fancy text so I've pulled out a few of those unused calls; textarc, pix and pixarc it will compile fine.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A wise man told me; "All electronics are made to work by magic smoke.

Don't ever let it out as it's·very difficult·to get it back in."

CannibalRobotics · 2008-10-16 17:09

As a follow up, I moved about 50% of the code in the Top object off to another cog.
The problem got worse. Now I'm like 187 longs over the limit.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A wise man told me; "All electronics are made to work by magic smoke.

Don't ever let it out as it's·very difficult·to get it back in."

Mike Green · 2008-10-16 18:52

If you're using graphics, the bitmaps for this are allocated in the upper end of main memory and they're quite large. The space is reserved by using the _free= constant declaration. Look at the source code for the graphics and display drivers.

Ariba · 2008-10-16 19:07

Your problem is the graphics object. If you use it with double buffering, like in the graphics demo, then you need 2x12kByte for two screenbuffers. The Spin compiler shows this video memory as stack/free, because the graphics object reserve the memory as stack.

You can switch to a single video buffer, if you can live with some flickering. Search in the forum for this, we had it many times...
(use http://search.parallax.com, not the forum search).

Andy

CannibalRobotics · 2008-10-16 19:17

Can I reduce the size of the buffer by going to 4 or 16 colors. The graphics demo specifies 64?
Mike, I did a search on _free= in Graphics, TV and the top module, no hits.
Any other names?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A wise man told me; "All electronics are made to work by magic smoke.

Don't ever let it out as it's·very difficult·to get it back in."

Ariba · 2008-10-16 19:26

It's not the graphics object, but the graphics_demo that define this:

...
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000
  _stack = ($3000 + $3000 + 100) >> 2   'accomodate display memory and stack

  x_tiles = 16
...

the _stack defines two buffers with $3000 = 12kByte, + 100 bytes stack
I think you have just copied that.

Edit: reducing color memory dont brings a lot of memory back (1 long per color)

Edit2: look also for stevenmess' XOR graphic object, this can help to work with a single video buffer: SDM_graphics_XOR in the obex.

Post Edited (Ariba) : 10/16/2008 7:37:21 PM GMT

Mike Green · 2008-10-16 19:35

One of the reasons to post (as attachments) your source code including any modified library objects is to be able to answer questions like this. I'm not sure whether the graphics object or the video driver uses the _free= declaration or whether the included demo programs use it. Regardless, how can I tell from your posted fragment in your first message that you even use graphics or what version (VGA / TV / what?). Problems like those you've uncovered are affected by other things in your program including the standard library objects that you use. StefanL38 already asked you to post your source code. We're all guessing mostly blindly what happened to your program, just based on general principles. We're all doing the "maybe it could be this" or "maybe it could be that" thing and you're mostly saying "no, that wasn't it".

CannibalRobotics · 2008-10-17 13:30

OK, here tiz. In this version there is a serialPWM object that is disconnected so I can continue the other work.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A wise man told me; "All electronics are made to work by magic smoke.

Don't ever let it out as it's·very difficult·to get it back in."

StefanL38 · 2008-10-17 18:47

hello,

OK first of all a short message to demonstrate how quick posts result in a slow solution proecess

quick version: " I added your lines of code and it compiles with no error and still 6293 longs free

from this quick post you know almost nothing.
quick as that questions stay open:

wich code added ?
code where added?
which proptool-version?

now if we would go on in this style we would have to start a ping-pong game
of asking short questions asking back get short answers short questions again and again etc. etc.

that's not effective!

so here a version that provides DETAILED information:

I downloaded your project and added the codelines from your first posting
in file HumanInterface_v1.4.SPIN inside the PUB main
the compiler reported two errors because of two array-variables missing

I added these two arrays to the VAR-section of HumanInterface_v1.4.SPIN

VAR
  long ADMin[noparse][[/noparse]8] 'added vars
  long ADMax[noparse][[/noparse]8]

....
Pub Main

  repeat
    LatchData :=Lt.GetLatch
    '################################
    'code is inserted here
    if LatchData & %0000_0000_1000_0000_0000_0000_0000_0000  > 0
       repeat i from 0 to 7
         ADMin[i] :=255
         ADMax[i] :=0
     
    LoadADData                  ' Get data from A to D's       
                  

    repeat i from 0 to 7
      ADDefl[i] := AnalogData[i] 
.....
[/i][/i][/i][/i]

after that everything compiles with Key F8 with no errors and 6293 longs still free

my environment: Proptool V1.2 under windows vista home premium

So from this version of your code we have only the information it compiles when

object

'    Ser   : "PWMSerial"

is commented out.

I guess to go ahead to FIND a solution next step is that you archive EXACTLY that code
that creates the error. No more quick and dirty cut & paste or archiving your current code
you are working on where things are commented out

regards

Stefan

CannibalRobotics · 2008-10-17 20:16

OK,

I've archived the code per your comments. I programmed around the old loop but the memory problem is still there. It should compile fine in it's archived state with 6169 Longs free.

To reproduce the problem, uncomment the line:

PUB TransmitData·· '' Transmits one data package form 255,0,d,d,d,d,checksum
··· 'ser.tx(Temp, 2)· ' <<<<<<<<<<<<<

Try this line

In HumanInterface_v1.4.

This causes it to go over by 2 longs on my attempts.

Jim-

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A wise man told me; "All electronics are made to work by magic smoke.

Don't ever let it out as it's·very difficult·to get it back in."

rjo_ · 2008-10-17 20:44

there was a thread which I archived... named "Why does the tv_terminal take so much room" on 5/13/07

cj asked "while the graphics demo takes so little graphics demo 1500 longs of code and 226 longs of variables vs. terminal 1200 of code and 3500 for variables

just wondering why."

here is Chip's answer.. which is not at all as I remembered it[noparse]:)[/noparse]

"The graphics_demo actually took a lot more, but you didn't see it in the compiler's bar graph because it was not reserved using VAR statements. Instead, it used a _stack directive to reserve a big chunk of RAM biased from the end of memory ($7FFF downward):

CON

_stack = ($3000 + $3000 + 100) >> 2 'accomodate display memory and stack

The $3000's are for the display buffers (in bytes). One of the $3000's is for the working bitmap, and the other $3000 is for the display bitmap, so the image is double-buffered, making it flicker-free. The $100 is for the initial COG's stack space. These all get shifted right by 2 (>>2) to get the equivalent long count."

Ariba · 2008-10-17 20:57

I try it again:
You are out of memory!
With 2 image buffers you have only 8 kByte left for all your objects.
The only way around this is to use a single image buffer.
See this thread for an example: http://forums.parallax.com/showthread.php?p=673946

Andy

CannibalRobotics · 2008-10-17 21:13

OK, I had sort of come to the same conclusion but I appreciate the verification.
cheers!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A wise man told me; "All electronics are made to work by magic smoke.

Don't ever let it out as it's·very difficult·to get it back in."

StefanL38 · 2008-10-17 22:26

OK. N.O.K.
I quit this threat.
For me there is too less cooperation from cannibal.

To me it seems he did the last posting in a hurry up and forgot to attach the new and COMPLETELY archived code
including the file PWMSerial.SPIN

If somebody else has more patience - try it

Stefan

Post Edited (StefanL38) : 10/17/2008 10:39:23 PM GMT

rjo_ · 2008-10-17 22:44

Stefan

I remember running into exactly the same problem... and accidentally stumbled across the right answer the first time.
But when you get multiple answers... and you have already formed an idea about it ... it isn't so easy sometimes.

I don't see much difference between this thread and a hundred others... when you don't get something ... you don't get it.
And when you get multiple answers, you might not see the right one... English might not be your first language... there might be kids screaming
in the next room... etc. etc. etc

Rich

rjo_ · 2008-10-17 22:50

cannibal... if you want to have some fun and get some perspective... go all the way to the beginning of the forum and notice the questions and the nicks of the people asking them. The nice thing about the Prop is that you can become a relative expert in heart beat(a year or two)

It is amazing to see how quickly guys go from where they are to where they want to go. Many of the questions you see posted have been discussed many times... that alone frustrates many of the guys.

rich

CannibalRobotics · 2008-10-20 17:45

I let it roll off, it actually made me laugh. In a forum somebody somewhere is having a bad day and somebody else will benefit from it.
In any case, thanks for all of the help.
Jim-

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A wise man told me; "All electronics are made to work by magic smoke.

Don't ever let it out as it's·very difficult·to get it back in."

OK, so where did my runtime memory go...

Comments