View Full Version : Life of allocated hub

10-11-2011, 02:22 AM
I've been thinking about a method to allow various objects and methods running on different cogs to pass information back and forth. My thought is to have have the initial method/object reserve an array as global memory and then pass the address of the array to the different objects. This way an object can pass data to other objects.

I'm doing something like it already in other short programs I've written. Rather then having an objects stop method simply cut out a method at it's knees by stopping a cog and then having to clean up the mess I have the stop method set a "stop" variable that's global to the object which is "monitored" by the other methods in the object and when set it's set causes the method to shut itself down and when it's done shuts down the cog.

My question is if during the run of the "program" I stop cog 0 and use it for something else does the memory it reserved become available for other use?

Duane Degn
10-11-2011, 02:34 AM
You can reuse the memory if you know where the program is stored.

It's not hard to reuse the program space of PASM code since it all grouped together. This is a semi common practice already. Finding where the Spin code is stored in hub RAM is more involved but I think others have done it.

Dr_Acula uses cogjects. Objects that are all PASM (or are they mostly PASM) which makes reusing their memory easier.


10-11-2011, 02:57 AM
PASM for 1 COG requires up to 2KB of hub space. You can reference that space any time from SPIN. You can set it to a fixed length if you want to recycle it. However once it's recycled, you can't use it again to start a COG unless you put code there. You could always reload the PASM buffer from the EEPROM or via some other device.

Stopping a COG will effectively destroy the code. You don't need to stop a COG though as you have already realized. Many people use mailboxes for HUB/COG communications - it is not an advanced concept. All you have to do is share the variable via the PAR register. The COG can "SPIN" on the PAR pointer waiting for a command to be non-zero, go do work, signal it is finished, and spin again.

Hope this helps.