Can you use a cog to....

Newzed · 2007-10-10 19:55

Is it possible to have a program running, then start a new cog with COGINIT, have that cog run an entirely different program, than at some point stop itself with COGSTOP and return to the original program?· Sort of like using the banks in a BS2E.

If it is possible, could someone show me how to do it?

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com
·

deSilva · 2007-10-10 20:59

You can start a new COG #2 from a COG - say #1.
Then both run absolutely independently.
Each of them can stop. by either running out of SPIN or explicitely be COGSTOP(COGID)
Even #1 can stop #2 or #2 can stop #1

There is no such thing as a "return" with COGs!

When you want to stop #2 and start it with a new program from #1, this should be straightforward.

When you want it (i.e. #2) to stop itself, and COG #1 to substitute a new program, then it (i.e. #2) has to set a communication variable before, to be read by #1, so it (i.e. #1) knows that #2 has terminated.

I think this is a rather complete description of the situation...

Post Edited (deSilva) : 10/10/2007 10:08:54 PM GMT

Newzed · 2007-10-10 21:57

deSilva, I understand what you are saying - I just don't know how to write it.· So....first things first.· How do I find the next available cog?· I am using Mike Green's OS so I am sure it uses several cogs.

Thanks

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com
·

deSilva · 2007-10-10 22:05

Use COGNEW; this looks for any free COG and also returns its number; it returns -1 if no free COG was available, and thus the operation failed.

Newzed · 2007-10-10 22:41

deS, I think maybe first I should find out what cog my program is running on.· If I insert (red line) in my menu method, will this tell me what cog my program is running on?

PUB menu
· text.dec(COGID)
· WAITCNT(CLKFREQ*2 + CNT)
· z := 0
· repeat
··· text.out(0)
··· text.out(13)
··· key.clearkeys
··· y := y + 1
··· text.dec(y)
··· readadc

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com
·

deSilva · 2007-10-10 23:05

Indeed, but I am not comfortable with your question.. There are very few cases where you really need to know your own COGID...

Newzed · 2007-10-10 23:18

deS, suppose my program is in cog 4 and I·start a new cog, say cog 6.· Will it run in the foreground until I stop it, or do I have to stop cog·4 at the beginning of cog 6.· If I have to stop it, then I need to know its ID, don't I?

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com
·

Graham Stabler · 2007-10-10 23:38

Sid,

There is no forground, the cogs are independant processors so if you start a cog from another cog then you end up with both running at the same time. What you need to do is put the cog that starts the second cog in a loop waiting for the second cog to do it's business and finish.

So you just need a flag that the second variable can set to say it is finished before doing its cogstop (or the end of the code), the first cog detects it has finished and moves on from the waiting loop.

Graham

Harley · 2007-10-10 23:57

Sid,

Myself I've wanted to know how many cogs my two Props are using. So....

Since I'm using a TV monitor with TV_text to view variables during debugging I've included a heading for each Prop which, from the source of each, includes the text with date, Prop version#, and also post id value for each (see attached). This has changed recently, but illustrates what I'm describing. Also helped me learn a bit more about working with the Prop. Props communicate at 115200 baud.

Since I've been using ViewPort and PASD for debugging I didn't like counting cogs each time I changed setups. Running near to 8 cogs in each Prop at times.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

Newzed · 2007-10-11 13:18

Graham, this morning I wrote:

PUB menu
· z := 0
· text.str(string("CogID is "))
· text.dec(cogid)
· waitcnt(clkfreq*5 + cnt)

and the screen said:

CogID = 0

Can that be right?

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com
·

Graham Stabler · 2007-10-11 13:33

The value returned by cogid is the ID of the cog that executed the command, I think menu is running in your main cog so it makes sense it would be zero.

Graham

Harley · 2007-10-11 14:23

The way I understand it, since cogs are numbered from 0 to 7, add 1 to get values from 1 to 8 of how many cogs are used.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

Newzed · 2007-10-11 15:06

Graham,I tried to start a new cog but I got some weird results.· Before we get into that, I need to ask a question.· When I run my main program it appears on the VGA screen.· Now just suppose I was able to start another cog, say cog 5, ·with a similar program with a menu that required action from me.· Can·I bring up cog 5 on my VGA screen, and switch the display from cog 5 to my main program and back and forth whenever I want?

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com
·

potatohead · 2007-10-11 15:44

If you write in some means for the COG's to communicate, you should just be able to have them each use the pins that your display is connected to. This will cause the monitor to sync though, as you would switch hit right in the middle of a signal. I don't think this is what you want.

One could also just use two displays at once! Connect two displays, and just let both COGs do their thing. This consumes pins and is limited by the amount of RAM.

Or, if you are using one display, you could have any of the cogs write to the display buffer. In this case, you've one COG building the display for the monitor, and other COGs writing to the display buffer. The only real limitation here is making sure those writes make sense, through inter-COG coordination. If you are drawing lots of stuff, then performing writes during the vertical blank interval is a good idea to cut tearing and flicker on moving objects. Menus and such can ignore this.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Graham Stabler · 2007-10-11 15:51

Sid, your program does not appear on the screen but rather it communicates with another cog(s) that sorts out the display so in theory as Potatohead says you could have more than one cog using the display as long as they talk to each other.

I can see what you want to do but personally I would try to keep the menus at in one cog even if the programs they control are in other cogs otherwise you could be heading for much complexity.

Graham

Newzed · 2007-10-11 16:04

Graham, that is what I wanted to know.· You always explain things very well.· So I will forget the new cog - I have 3145 free longs so, if necessary, I will just augment my current program.

Someday, just in case, I need to find out how to start a new cog and display its ID.

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com
·

deSilva · 2007-10-11 21:46

Sid, I generally do not understand your problems... I just answer to your questions, that make but little sense to me....
So why do you not use this obvious program to do what - according to how I interpret your question - you probably want to do... though I am not sure...

COGNEW(aNewCOG, @somestack)
....

PUB aNewCog
  text(string(13, "New Cog started, #"))
  text.dec(COGID)
  repeat ' now locked in endless loop...

ericball · 2007-10-12 21:05

deSilva said...
Indeed, but I am not comfortable with your question.. There are very few cases where you really need to know your own COGID...

1. Have the code COGSTOP itself
2. Have the code COGINIT to reload it's own COG with new code
3. Access COG-specific data from a buffer used by multiple COGs.

I used #3 in my (badly broken) multi-COG NTSC driver.· Multiple COGs were started using the same code block, but each COG needed to know whether it was the first, second, or Nth COG so it could properly synchronize with the other COGs.

  repeat i from 1 to NUMCOGS
    if (cog := COGNEW( @cogcode, LONGPTR )) < 0         ' no cogs available
      stop                                              ' stop anything started
      RETURN FALSE
    else
      cogid0num[noparse][[/noparse]cog] := i                               ' save cog index (works 'cause COGNEW is not instant)
      vidcog[noparse][[/noparse]i-1] := cog + 1                            ' save cogid for stop

cogid0num[noparse]/noparse was towards the end of the 496 longs loaded
·

deSilva · 2007-10-12 21:25

You could also parametrize each COG you are startng with a "logical number", its physical number has no magic properties...

I agree that it is a little bit more comfortable to learn that number from the hardware ( by the result of COGNEW at the main COG and by COGID at the slave COG)

Using COG-IDs can be helpful when you start multiple instances of the same code, trying to simplify the management of those COGs.

The main reason why you generally do not need the COG-ID is that there is ONLY ONE operation that requires it: COGSTOP.

Yes, I noticed #2, but this is what I should call "one of a few cases"

But I do not want to split hairs...

Post Edited (deSilva) : 10/12/2007 9:33:12 PM GMT

Can you use a cog to....

Comments