Moving variables between routiens.

Ok, I'm stuck.

I understand the idea that a "function" does something and maybe returns a value saying it has suceeded or failed.

It can also return other values.

Using the PHI-menu I have written a routine to set a variable/value.

So, when I call it I do something like:

my_routine()
{
do stuff here and set a value
I forget how I return it, but I am 99% sure I have it right.
}

my_variable my_routine();

This sets "my_variable" to the value returned by "my_routine"
Fantastic.
but how do I then get this variable to other routines?

Some of the routines have values in the () like:
void their_routine(int blah)
So if I want to include my variable, what would I do to it?
void their_routine(int blah, int my_variable)

my_variable my_routine();

This sets "my_variable" to the value returned by "my_routine"

Wrong, this generates a compiler error. Assignments are done using the "=" operator. So your line reads correctly:

my_variable = my_routine();

Maybe you should look at a C++ tutorial like

http://www.cplusplus.com/doc/tutorial/

my_routine()
{
do stuff here and set a value
I forget how I return it, but I am 99% sure I have it right.
}

That's not how you "call" a function. To call a function you would do something like this:

int a;
a = my_routine();

So a would be set to the return value of my_routine. What you have above looks more like a function implementation, but you're missing a return type. This is would the implementation should look like:

void my_routine() {
  // Do stuff
}

The above doesn't return a value (hence the void). If you want to return, say an int, you would do this:

int my_routine() {
  // Do stuff
  return someInt;
}

Again, this is only the implementation. This is placed somewhere in your code, outside of all other functions and only done once.

my_variable my_routine();

This sets "my_variable" to the value returned by "my_routine"

Incorrect, that looks more like a function prototype, assuming my_variable was a variable type, rather than a variable. To call a function that returns a value and store it in a variable, you would do this:

int my_variable;
my_variable = my_routine();

Keep in mind, my_routine() would need to be implemented (like the example above) somewhere in your code.

Some of the routines have values in the () like:
void their_routine(int blah)
So if I want to include my variable, what would I do to it?
void their_routine(int blah, int my_variable)

Variables inside the parenthesis are passed to the function that you are calling. They are then used in whatever calculations need to be done within that function. They are passed by value, meaning the value of the variable is not manipulated.

Here's an example of code that uses both arguments and return variables:

int kelvin, celsius;

kelvin = getTemperature();

celcius = convertToCelcius(kelvin);

This of course, assumes getTemperature() and convertToCelcius() are implemented somewhere in the code.

I understand the idea that a "function" does something and maybe returns a value saying it has suceeded or failed.

It can also return other values.

Yes... A function can return ONE value (or it can return nothing). You can pass multiple values into the function, but you are (normally) passing-in only the value, not the variable itself. So, if you pass-in X, you are passing in the value of X. If your function changes X, it only changes the numerical value copied into the function, it does not change the value of the original X. ( If you return X, you can change the original value.)

If you want a function to change more than one value (a classic example is if you want to swap the values of X & Y, or if you want to change a string) you have to pass-in pointers or references, and that allows your function to change the original variables. (You can also use global variables, but that's normally considered bad practice.)

Ok, sorry.

It is early morning and I may not be explaining myself too well.

In my first post, I listed the "function"/"routine" first - it seems they pop up anywhere when I am looking at the code/s.

However, I put it there only to show you my little function/routine.

Thanks for pointing out the need for the = sign.

in the exaple:

int my_routine() {
  // Do stuff
  return someInt;
}

You lost me.
int defines an integer. But what is it's name?

So what I read as being need for e to do is:
int my_variable
my_variable = my_routine()

where my_routine is a bit of code which returns a value which is stored in "my_variable"
All well and good, but if then later on, I want to call another routine/what ever which is exisitng and send it "my_variable" and there are alredy things sent to it, how do I append what I want to send?

(Sorry the screen has kgone all weird with this jump/scroling when I am typing and it is as annoying as anything.)

lost_and_confused:
You lost me.
int defines an integer. But what is it's name?

In that context, it doesn't define an integer, it defines the return type of the the function my_routine() as an integer.

So what I read as being need for e to do is:
int my_variable
my_variable = my_routine()

where my_routine is a bit of code which returns a value which is stored in "my_variable"
All well and good, but if then later on, I want to call another routine/what ever which is exisitng and send it "my_variable" and there are alredy things sent to it, how do I append what I want to send?

What do you mean by "append what I want to send?" The temperature example above shows you how to pass a variable to another function. my_variable contains the value that was returned by your my_routine() function and is just like any other variable. You can modify it any way you see fit.

Perhaps it might be better to explain what you are trying to do from a more abstract level.

Are global variables really that bad practice on a micro controller? I can see why they are on software for a PC on a bigger system. But on a micro controller? Sometimes it's a lot easier to have a global variable than mess about with pointers.

EVP:
Are global variables really that bad practice on a micro controller? I can see why they are on software for a PC on a bigger system. But on a micro controller? Sometimes it's a lot easier to have a global variable than mess about with pointers.

I don't think I'd ever consider global variables bad practice, overall. It simply the depends on the context of what you're coding and how you are handling these variables. Functions with arguments/return types rather than global variables also helps cut down the code by making code reusable and portable.

Ok another try to explain - sorry guys I am not trying to be difficult.

a bit of my code and the existing code as well.

int my_variable
my_variable = myroutine()  //do a routine which returns a value stored in my_variable


//  (later on in the code - or somewhere else)

void their_routine(int foo)

That is the "existing" code.
Not only do I want to send "foo" to their_routine but I also want to send my_variable as well.
Obviously I will have to alter their_routine - and I accept that.

But HOW do I send/append/what ever my_variable to the "their_routine"?

Does that make sense?

int my_variable
my_variable = myroutine()  //do a routine which returns a value stored in my_variable


//  (later on in the code - or somewhere else)

void their_routine(int foo)

First off, you're missing semicolons.

Secondly, assuming their function is implemented like this:

void their_routine(int foo) {
 // do stuff with foo
}

To add another argument to the function you would need to simply do this

void their_routine(int foo, int myVar) {
  // do stuff with foo and myVar
}

You would also need to change any function prototype, if that's declared anywhere (like in a header file for a library).

In your code, you would call the function like this:

int foo, my_variable;
foo = something;
my_variable = my_routine();

their_routine(foo, my_variable);

Does that make sense?

Still iffy. Why not just post the entire code? You're better off doing that and explaining WHAT you are trying to do, rather than HOW you are trying to do it. Explaining the former allows us to get more context and identify any issues you may run into or flaws in your assumed HOW method.

Sorry, got distracted.

Yeah, looking at that now.

I think things are starting to become clearer.

(Well, I can but hope.)