large temperary storage [SOLVED]

Bobb Fwed · 2009-08-20 23:59

Is it OK to place large string (or array or stack) somewhere in the empty/stack space? I have the program reading a large (indeterminably large at compile time) amount of information from the EEPROM and want to put it somewhere so it can be accessed by address (in the near future -- not long term storage). I can't just make a massive variable stack because it can't be used later (or for other objects). Is there any way to know where there is inactive empty/stack space in RAM? How does the Prop know where to put stack information? Does it continually just use the lowest possible memory?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

Post Edited (Bobb Fwed) : 8/21/2009 5:37:29 PM GMT

CounterRotatingProps · 2009-08-21 00:03

Hi Bob,

The prop hardware architecture doesn't use stacks.

How big is this string?

- Howard

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

jazzed · 2009-08-21 00:17

Howard, Spin uses stacks ... PASM doesn't of course.

Bobb, one thing you do is can use one of the memory managers from the OBEX. Look for Peter's HEAP.spin for example. You declare a an array big enough for your application and give it to HEAP.spin for management. If you are looking for a more generic top-down heap manager, this can be done, but unless you run a spin interpreter cog that emits the stack pointer, there is no way other than a crash with this method to tell when the stack and heap overlap. If you use spud, you can see the stack pointer or dump the stack at any time during debug. Spud is relatively new though.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Mike Green · 2009-08-21 00:25

It's a bit confusing when you ask a general question like that. Spin has a default stack that starts at the end of the program and extends upward in memory towards the end of the 32K of hub ram. If you start up any other cogs with Spin, you have to supply a stack area for each of them. If you start up an assembly cog, there is no stack, so it's not an issue. If you want to dynamically allocate storage, it's best to start at the end of hub ram and work downwards towards the stack. You can get an estimate of how much memory is available by calling a dummy routine that uses the address of a local variable to get the address of the top of the stack (at that time) like this

PUB stackRoom | dummy
   return $8000 - @dummy

This returns roughly the amount of space between the top of the stack and the end of memory. Keep in mind that there'll still be more calls and some additional stack may be used. You usually want to allow a "fudge" factor of at least a couple of hundred bytes.

CounterRotatingProps · 2009-08-21 00:33

Steve, Mike --- right, sorry I just assumed he was using PASM by the nature of the question.

> If you use spud, you can see the stack pointer or dump the stack at any time during debug. Spud is relatively new though.

But it's really cool so far...

... And yes, Steve, I caught that SneakySpudPlug :-P

say, when the debugger (?) is done, can you please call it the Spud Gun ?! <G>

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

jazzed · 2009-08-21 01:25

Nice trick Mike. Yes, the stack grows up from the end of VAR space.
Wasn't there a "malloc" implemented last year that used all left-over memory?

Just an FYI Howard [noparse]:)[/noparse] I need user feedback. Spud gun ... is that like a Pumpkin catapult ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Bobb Fwed · 2009-08-21 17:00

OK...well I just went with shoving the information all the way to the highest bytes of the RAM. And let the programmer be resposible (there is a current maximum limit of 256 bytes...so it's not huge).
Now what am I doing wrong with this code?

This works:

PUB read_multiblock (ptr, str_size) | i
'' read a string (than spans more than one block) from EEPROM to highest location possible in RAM

  i~
  result := $7FFF - str_size     
  REPEAT WHILE (str_size > 0)
    bytemove($7FFF - str_size, read(ptr + i, 1), 1)
    str_size -= 1
    i++

But this should be faster...but isn't working:

PUB read_multiblock (ptr, str_size) | i
'' read a string (than spans more than one block) from EEPROM to highest location possible in RAM

  i := block_size - ptr // block_size                                           ' determine bytes to end of block
  result := $7FFF - str_size                                                    ' start address
  bytemove(result, read(ptr, i), i)                                             ' move to lowest portion of the highest location in RAM
  str_size -= i
  REPEAT
    IF (str_size =< block_size)
      bytemove($7FFF - str_size, read(ptr, str_size), str_size)                 ' read the last of the info
      QUIT
    ELSE
      bytemove($7FFF - str_size, read(ptr, block_size), block_size)             ' read a block of the info
      ptr += block_size
      str_size -= block_size

For both of these...block_size represents the block size of the EEPROM which is 64 (bytes).
And read() returns the RAM address of the read EEPROM information (used with basic i2c driver).
As usual....it's probably simple....but so far not obvious to me...more pairs of eyes will help.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

Post Edited (Bobb Fwed) : 8/21/2009 5:05:26 PM GMT

Bobb Fwed · 2009-08-21 17:25

never mind...I figured it out, I was missing a ptr += i before the REPEAT

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

CounterRotatingProps · 2009-08-22 02:14

jazzed said...
...·Spud gun ... is that like a Pumpkin catapult ?

Yup, only made in Idaho [noparse]:)[/noparse])

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

large temperary storage [SOLVED]

Comments