PDA

View Full Version : global information



sciguy
05-14-2008, 01:25 AM
What is the easiest way to make some variables (probably byte arrays) that can be accessed and written to by all the cogs? Do I have to pass everything through parameters, or is there a way to easily share a set of information?

Mike Green
05-14-2008, 02:08 AM
If you're talking about cogs running Spin code, all of the cogs have access to all of the global (VAR and DAT) variables that are declared in the same object as the methods being run in the cogs. From that standpoint, it makes no difference whether you're using one cog or all 8 cogs and it makes no difference which cog is running the method that's accessing the variable.

The main problem you run into is that two cogs can also modify the same variables at the same time or one cog can access (read) a variable while another is modifying (write) it. There are ways around that, one of which is to use LOCKs so that only one cog can "get" the lock/semaphore at a time. The are ways to do this in some circumstances without using LOCKs, but you're limited to only one cog modifying the variable.

sciguy
05-14-2008, 02:16 AM
Ok, I see. So as long as they are in the same physical spin file, they can be accessed, regardless of the cog running?

Chuck Rice
05-14-2008, 03:53 AM
Mike Green said...
If you're talking about cogs running Spin code, all of the cogs have access to all of the global (VAR and DAT) variables that are declared in the same object as the methods being run in the cogs. From that standpoint, it makes no difference whether you're using one cog or all 8 cogs and it makes no difference which cog is running the method that's accessing the variable.

The main problem you run into is that two cogs can also modify the same variables at the same time or one cog can access (read) a variable while another is modifying (write) it. There are ways around that, one of which is to use LOCKs so that only one cog can "get" the lock/semaphore at a time. The are ways to do this in some circumstances without using LOCKs, but you're limited to only one cog modifying the variable.



You just confused me Mike. You mean that if my main defines

rs[ 3 ] : "FullDuplexSerial" 'Serial board to board communications

then does:

rc:= rs[g#navBoard].start(cNavRxpin, cNavTxpin, %0000, g#cBaud)
rc:= rs[g#motBoard].start(cMotRxpin, cMotTxpin, %0000, g#cBaud)
rc:= rs[g#senBoard].start(cSenRxpin, cSenTxpin, %0000, g#cBaud)

The variables defined in the VAR section are shared? I thought that I was getting three separate namespaces for each of the three instances started.

Am I screwed up here?

Ken Peterson
05-14-2008, 04:13 AM
Chuck: I think it is three namespaces. Separate VAR section in memory for each object instance.

It's easy to imagine how multiple cogs can share the same object space in SPIN, because they all run from HUB memory. However, data encapsulation prevents data from being shared between objects unless they are passed with parameters or pointers.

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

Mike Green
05-14-2008, 04:25 AM
Chuck,
You're confusing "namespaces" with "instances". There's only one namespace for each object making up your program. By definition, this is the "space" of names recognized by / known to the compiler. On the other hand, in your example, there are 3 instances of the FullDuplexSerial namespace, one for each subscript value you've declared.

sciguy,
Yes. Each object that makes up a program has its own "namespace". All variables, constants, methods, etc. within that object are "known" throughout that object. There are some exceptions. For example, there are local variables within methods that are usable only within that method although curiously, you can't use the same name for a local variable as that of a global variable or constant. In some languages, you can reuse any name for a local variable. Go figure!

Constant names and public (PUB) method names are exported to other objects and can be referenced using "obj#constant" or "obj.method" notation where "obj" is the declared name of the object in the object referencing it.