How to Global Variables?

william chan

Hi,

How to declare Global Variables that can be accessed by all cogs and all objects?

I tried PUB VAR but it didn't work....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

DavidM

HI, William,

You declare your variable in your main method as normal

LONG MyVariable

You pass these variables to an EXTERNAL method ( ie SPIN file ) using the @ symbol

MyResult : = External.MyMethod ( @MyVariable )

This passes the ADDRESS of the variable to the method and NOT its value!

In your external method refer to the variable as a POINTER or address , so you need a new variable name declared in the method
I use the same variable plus the letters PTR after.

---External.spin----
PUB MyMethod (MyVariablePTR)

When you want to read the Global variable in this external method do this..

Something : = LONG[noparse][[/noparse]MyVariabePTR]


When you want to write to that variable within this external method do this..

LONG[noparse][[/noparse]MyVarablePTR] : = Something

Your global variable's value ( back in the main method) will be updated immediately even if its running in a cog or another external spin file!



regards

Dave M

DavidM

Hi William,

Did you get a chance to try this out?


Regards

Dave M

william chan

Not yet.
Currently looks too complicated for me.......

Thanks. It is an ingenious idea.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

StefanL38

hello david,

if it is not too much work for you

post sourcecode of real working example. This means a simple example just showing the principle with one variable

regards

Stefan

Ronny D'Hoore

I'm kind of surprised that there is no way in SPIN language to define variables which are really global to all cogs. If I understand well, all variables are in general RAM, so I don't understand why the variables cannot be made accessible from another cog, especially if all code is within one spin file.

The system of passing a pointer to the variable as kindly explained by DavidM is fine and alright as long as you have just a few variables that you need in your other cog. But if you need access to almost all, it becomes cumbersome and increases the chance one will make mistakes.

So if the people from Parallax would be wondering where they could still improve their IDE, then this is where to look [noparse]:)[/noparse]

DavidM

HI Ronny,

Having too many GLOBAL Variables is bad programming practice ( I read that some where , but its true! ) . Also having to use the same variable name in external methods would make generic/modular code impossible.

The instructions I posted earlier work for me, I generally write my code to be a modular as possible so that individual spin files can work anywhere.


My description before is fine for single bytes but it become a little difficult for strings, arrays etc ( which I haven't tried).

A suggestion ( for parallax ) would be how to access the variable as a whole ( a true pointer ) rather than as a single byte address using the byte function and [noparse]/noparse brackets.

regards
Dave Metus

deSilva

Dear all,
there are COGs and there are Objects - they have nothing to do which each other - nothing!

In SPIN the scope constraints between Objects have been critized from each and everyone, so there is no need to repeat this again and again - or is it ?

It simplifies the compiler considerably, and it is in the spirit of OOP.
However as there is little else in SPIN in the spirit of OOP and SPIN is missing any datastructure anyhow this is hardly a very convincing argument...

I should say that the need to use some tricky referencing/dereferencing constructs can obfuscate a program more than the unrestricted use of globals...

william chan

Now that I understand SPIN objects better......

In my opinion and experience from PC programming languages,
the current var scope limitations in SPIN are the correct thing to do.
Kudos to the SPIN development team.

The correct way to access variables in other objects (not cogs) is to create your own get_xxx and set_xxx methods in each object.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

Ronny D'Hoore

Like mr deSilva already pointed out, there is a difference between cogs and objects. I was talking about accessing global variables from different *cogs*, from within one source file.

I'm collecting pulses and their timing into a buffer (a number of array variables) in one cog, and then in another cog I'm sending all that data to a host pc over a serial link. The first cog is doing the time-sensitive stuff, and the second is sending the data in less critical timing. So coming from a programmer's background, I started off using objects, with getters and setters, and the whole show. But very soon I got quite stuck. The SPIN "objects" are useful, no doubt, I do understand their purpose. But they lack a lot of the functionality of what objects are elsewhere.

So then I thought, let's put everything in one file, and use global variables. But no joy either, the global variables aren't global. Even though the code is all in the same file, just because one function runs in another cog, therefore it does not "see" the variables that are right there within the same SPIN file. It doesn't feel right (even though I understand the technical reasoning behind it). Not only that, but also there is no way to define variables that *are* global to the other cog within the same SPIN file. And there is no option to tell at which address in RAM a block of variables should be located.

I guess my two options are to either go assembler (which I'm hesitating to do, I'm a total newbie here), or to pass all my variables through pointers.

Or is there some other way that I don't know of?

Mike Green

Ronny,

1) You are absolute correct in that "objects" in Spin are not objects in the same sense as in other programming languages. They provide some name-scope convenience and there's provision for static multiple instances, but that's most of it.

2) If your program is all in one source file, then all of the functions (methods) have access to all of the global variables regardless of which cog is executing the method. I don't know what you've experienced, but I've written many Spin programs where there is essentially one source file (maybe I used FullDuplexSerial or a video and keyboard driver) and several cogs used to execute parts of the main program and the various cogs communicate through global variables in the main program file, so I don't understand what didn't work for you. Maybe you just didn't find a way to explicitly declare variables as global ... they're all global (within the same file) without doing anything.

3) There is no particular advantage to going to assembly for this. Both the Spin and the assembly code have the same scoping rules.

Post Edited (Mike Green) : 3/10/2008 4:55:25 PM GMT

deSilva

As Mike said (2): We don't know what you are talking about...

Ronny D'Hoore

> As Mike said (2): We don't know what you are talking about...

The problem is, I don't know myself what I'm talking about. This is the first application I make, and I must have made some blunder in my software that made me conclude that the variables are not accessible from the second cog.

My program didn't do what it was supposed to do. So I decided to use debugging LED's. But from the second cog, they didn't light up. It took me quite a while to figure out why. Then I found that apparently one should set the output direction only for the bits one is using, and leave the others alone (even if you use the proper direction for the others). And one must do this in each cog separately. At least, if I did anything else, the respective LED's would not light up. Anyway, this only made me more convinced that nothing is global when you work with multiple cogs, including the global variables. I'm glad to hear I'm mistaken.

I'll try again now, and see where I get. I'm a total beginner with the Propeller, and appreciate very much your help. I really do.

Ronny

Mike Green

There's a lot of information to assimilate in learning how to use the Propeller. That's why it's helpful to go through tutorials like those in the Propeller Education Kit while learning. You don't even need the Kit if you have the basic parts like LEDs, just download the tutorials.