Using the 2k cog memory?

Oldbitcollector (Jeff) · 2011-02-16 06:55

Has anyone (if it's possible) written an assembly object to allow access to the 2k of memory that appears to be free when a cog isn't running spin? I could really use this extra few bytes, and I've got open cogs in my current project.

I'd like to be able to send/receive data much like that of the memory drivers.

OBC

JonnyMac · 2011-02-16 06:59

There was a tread in the original forum. MagIO, myself, and a few others tossed out ideas.

Heater. · 2011-02-16 07:10

OBC,

Have you reused any HUB memory that was COG images before they were started yet?

Oldbitcollector (Jeff) · 2011-02-16 07:13

No.. Elaborate?

Duane Degn · 2011-02-16 09:22

Well, it's been about two hours without anyone answering. Let's see if I can answer before someone posts as I'm typing (don't you hate that?)?

The code to be loaded into a cog on cognew is in hub memory. When the new cog is launched, the PSAM code is copied into a cogs memory for execution.

If the code doesn't need to be used again (relaunching a cog) then the area in hub RAM can be reused.

You need to make sure the object doesn't already reuse some of the memory. Tim Moore's four serial port object uses the same memory location for his buffers and I'm sure other objects reuse portions of the PASM image in hum RAM.

If the object doesn't already reuse the hub RAM than you can use it yourself. If the first location declared after ORG is "entry" then you'd start using the RAM at @entry. You'd want to find a simailar label for the end of the RAM memory used for PASM code that has been launched.

Duane

Miner_with_a_PIC · 2011-02-16 10:41

It would be VERY useful to many if for a given project all the PASM code segments could be organized so as to be concurrent in main RAM and post cog launches the memory was reallocated for program use. I took a peek at Tim's serial driver and it doesn't seem to be actually reusing PASM code space but rather preallocating some longs for the buffer. Perhaps I completely missed the point and this is likely given my limited understanding of this advanced topic.

What would be very helpful would be an example project with multiple objects with PASM content that achieves the following:

1) PASM code concurrency in main RAM.
2) A clear example of reallocating this segment of memory for some arbitrary buffer (a single large buffer) used by the main routine running.

Is all this possible? If the concurrency part is impossible for multiple objects then I for one would be open to combining them all into a single object and placing all DAT sections adjacent to one another as the trouble would be well worth the gains.

Duane Degn · 2011-02-16 11:04

I spent much of the day yesterday trying to get Tim's driver to use two cogs for eight ports. If you look down in the PASM you'll see reads and writes to areas of hub RAM within the PASM code section. Sections are loaded pre-launch with data the cog needs and then the cog reads and writes to hub over the same address.

I haven't yet got Tim's driver usable for eight ports. (I want to reuse the PASM code in two cogs. It's his reuse of hub RAM that make it tricky.)

MagIO2 · 2011-02-16 11:17

I remember the thread as well, but did not find it.

But here I have some code which might have been posted in that thread by Jonny and ????
It's for simple access ... depending on the usecase you might rather want to copy whole blocks of HUB-RAM to COG-RAM and vice versa instead of doing it long-wise.

Jim Fouch · 2011-02-16 12:10

I'm trying to get my head around this concept of reusing HUB Ram after a COG is loaded with PASM...

I can see where this would work for a cog that is started ONCE, but if the COG was stopped and then restarted, would it not have issues if it's sourced area of HUB had been modified?

The HUB (RAM) would need to be reloaded from eeprom to be launched correctly again, right?

Oldbitcollector (Jeff) · 2011-02-16 12:11

Thank you guys! This gives me some good material to dig into.

I could only locate part of the answer in Desilva's Assembly Tutorial, so I think i'm well into this now.

OBC

Cluso99 · 2011-02-16 12:15

my 1pin debug tv driver in the obex reuses the hub ram for the screen buffer. You will see a little bit of code in the pasm area that allocates extra space in case the text buffer is > cog code space because we don't want the screen buffer tromping over another piece of hub ram that's not ours.

MagIO2 · 2011-02-16 12:28

@Jim:
I guess either I did not understand your post or you mean something else than we talk about here.

The idea is to use the COG RAM of not used COGs from the running COGs. With 2 unused COGs you have nearly 4kB of unused RAM. So, the idea is to load a little bit of code in the not otherwise needed COGs that allows to copy data form HUB RAM to COG RAM and vice versa. This does not mean to free HUB RAM occupied by COG code before, it means to make the not used COG RAM available.

You talk about reusing HUB RAM after loading the code into COG RAM (with cognew). Yes, here you would have issues in an environment where you dynamically have to start/stop COGs. But stopping COGs only makes sense if you run out of COGs.

Miner_with_a_PIC · 2011-02-16 13:36

Success! My current application is now 571 longs richer which is awesome given that encroachment onto the stack was becoming a greater risk with each code addition. I was only able to pull this off if:

1) The objects were combined and DAT sections placed adjacent. (I needed a large buffer of concurrent bytes)

2) Cogs are loaded with the intention of not reloading them again prior to writing to the reallocated memory.

Unfortunately I cannot post the code as it is for commercial use and I am bound by confidentiality. Essentially the procedure would be:

1) Identify the objects containing PASM code that you would like to free up.
2) Copy and paste all objects into a new object.
3) Place all Dat sections RELATED TO THE CODE (not main RAM variables which may have their own DAT sections) adjacent to one another.
4) Take a summation of the new target memory by using your cursor post compile and a calculator.
5) Write a PUB that returns the top address in your new lengthy object (PUB GetTopAddress Return @entry)
6) In your main routine load the address by calling the PUB from previous step (ex. MyAddress := LargeObject.GetTopAddress)
7) Start all cogs related to the code
8) Write and read the memory at will Longfill(MyAddress, 0, 256)

MagIO2 · 2011-02-16 13:45

@Miner
Don't worry about 'not posting'. I'll soon release some code in my blog which also frees some HUB RAM. Hope the next entry follows latest on the weekend.

RossH · 2011-02-16 14:25

Hi OBC,

Catalina has a module called "CogStore" which allows cog RAM to be used to store and retrieve arbitrary data (up to 300 longs, although this could be increased if you needed more space - I use this module in Catalyst to pass command line parameters to C programs when they start up, so my CogStore object also contains code to parse a command line and break it up into C argc and argv parameters - you could remove this code to get more storage space).

You'll find the CogStore module in the file Catalina\target\Catalina_CogStore.spin - this is the PASM implementattion. You will find an example of a SPIN acess module in the file Catalina\Catalyst\demo\Catalyst_Arguments.spin

Ross.

Using the 2k cog memory?

Comments