How many cogs ?

Ole Man Earl

This may seem silly, but how do you know how many cogs are being used by your program? Is there some spin code to tell you ?

mctrivia

there is an example code in the manual. try opening new cogs until you can't count how many times you could then shut them all down

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

mosquito56

download the scogs in the obex.
http://obex.parallax.com/objects/154/

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·······

······· "What do you mean, it doesn't have any tubes?"
······· "No such thing as a dumb question" unless it's on the internet
········

Brian Fairchild

Unless you explicitly start them with COGINIT or COGNEW then your program will only use one COG from reset to run the SPIN interpreter. No COGs are started 'by magic' in the background.

mctrivia

no but code can start cogs dynamically

cog starts up do something, checks p0 if low start same code in new cog and do some something else.

any number of cogs could be running in this example

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

MagIO2

Why not simply add a little piece of code to each COG-function or PASM which sets a byte to true at the end of RAM? Each COG has it's own byte .. or maybe a long which stores the first 4 letters of the function/PASM name? Each COG needs it's own area for that (say $7ff-cogid) because using one byte for all makes things more difficult as read, modify, write might interfere with another COG. If you're now interested in how many COgs run you only have to count the bytes which are not 0. Of course if the COG code ends running it has to be set to false again.

SPIN code:
byte[noparse][[/noparse]$7ff-cogid]:=cogid
....
byte[noparse][[/noparse]$7ff-cogid]:=0


PASM code:
cog_id cogid cog_id
sub cog_run, cog_id
wrbyte cog_id, cog_run
...

wrbyte zero, cog_run
cogstop cog_id

zero long 0
cog_run long $7ff

SRLM

Each cog (except the initial cog 0) is started by the programmer. Therefore, you can examine your code to figure out at any particular moment how many cogs you have running. Many of the obex objects will have a start routine with a cognew, and if you have one of those objects in your program then you'll be using two cogs: the initial and the obex object. This thread has really helped me get my head straight.

mctrivia

srlm that is not always true. see my example above of a code that can not be predicted

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

Mike Green

It's unusual for a program to have to keep track of the number of cogs in use, so it's not good to build in the functionality into everything. MagIO2's suggestion is one that can work. SRLM's observation is also correct and can be applied to McTrivia's circumstances by making it the responsibility of the part of the program that starts a cog responsible for updating a single global count of the number of cogs in use. If a cog stops itself, it has to update that counter. If a stop routine does it, then it's the stop routine's responsibility.

Most of the time cog usage can be predicted.· It's easy to build-in some dynamic bookkeeping for those few situations where it can't be predicted.
·

localroger

Cog use can indeed become murky because some common objects spawn cogs, especially if they need to run PASM code. The TV and VGA drivers need a cog (some more than one), the spi driver for SD cards needs one, fullduplexserial needs one, all audio functions need at least one, ADC will need one, and so on. Then your actual application might need some PASM or asynchronous SPIN code. It's not hard to find uses for all eight.

mctrivia

I wrote a 4x3 keypad object that kept one cog checking for expenses it would then span a new cog to execute the code. because some buttons code could take a few seconds(like the one that said the time) multiple cogs could be running at any time. if all where full I just waited until one was available

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.