Chapter 6: C Functions and Program Structures

Scope

Variable names have scope, meaning the locations where they are recognized, that determine how they can be used.

Variable names declared in a function are recognized only in that particular function. For example, you can have multiple functions with the int i declared local to that function and they won’t interfere with each other. Likewise, a variable declared within a block remains local to that block.

External variables have scope from the point they are declared to the end of the text file. If you compile a file, you can call functions in it from other files, but you cannot use an external variable declared in another file.

There is a difference in the definition and the declaration of external variables. If you use the extern keyword as in:

extern int tramp;

you have declared that tramp will be an int, but you have not defined it. To use tramp you must define it in each file that will use it. Something like:

int tramp = NULL;

This must appear in a source file that uses it. For example:

In file1:

extern double gadabout; extern char harlot;

In file2:

double gadabout = 0; char harlot = ‘?’;

In this case changes to gadabout and harlot in file1 will also appear in file2 and visa versa. Maybe I’m being harsh calling them tramp, gadabout, and harlot, but externs are even more prone to being who-knows-where and doing who-knows- what than regular external variables so they are bug prone.

91

Chapter 6: C Functions and Program Structures

An example bug comes when you create an extern:

extern int upcount;

in file1 and declare it in files 1 and 2 and put your code aside for a few months, then get busy on file3 and decide that you need an external variable to do some up counting, so you declare it int upcount = 0; forgetting that it has already been declared as an extern in file1 which you have stuck in a library and no longer look at. Then you start getting weird bugs where the seemingly impossible event occurs that your upcount is getting changed unpredictably. This kind of error is so common that it was one of the reasons C++ was invented. Use externs if absolutely necessary (sometimes nothing else will do) but use them with extreme caution.

Headers

Header files are a convenient place to stick all the stuff that you put before the main() function. They are files with a suffix of .h and are declared as:

#include <LEDblinker.h> #include “PCcomm.h”

If the declaration uses <filename> the compiler looks in an implementation defined location, usually an ‘include’ directory. If it uses “filename” the compiler looks in the same directory that the source program was located. The choice will depend on how you’ve decided to organize your development file system.

Blocks

Initialization

If you don’t explicitly set a variable equal to some value, external and static variables are guaranteed to be initialized to zero; automatic and register variables are guaranteed to be initialized to random garbage. It’s good practice to always initialize a variable.

External and static variables must be initialized with a constant expression, but you can use other variables in the initialization of automatic and register variables:

92

Chapter 6: C Functions and Program Structures

int dosomething(int x, int y, int z)

{

int a = 0;

int b = x + y + z – 12; // do stuff

}

Recursion

Recursion happens when a function calls itself. I’ve never called myself. I’m afraid that I might answer the phone and then have to deal with the philosophical or psychiatric implications. However, C has no problems with functions calling themselves, other than the psychiatric problems it tends to cause programmers when confronted with a recursive function and the task of figuring out what’s going on. C Gurus love recursive functions.

void recursivefunc(double data)

{

double mess;

//Do some stuff recursivefunc(mess);

//Do more stuff

}

You’ll find recursion used quite appropriately in some standard library functions and in many data sorting applications. But recursion can be very problematic in microcontrollers where we are usually limited in RAM memory. Each time you call a function some data is put on the stack using RAM that isn’t released until the function returns. Each function you call within a function puts more data on the stack locking up more RAM. Recursive functions look like a good way quickly and unpredictably fill the stack leading to the often-fatal condition known as blowing your stack. Your stack usually starts at the end of RAM and builds downward. Your variables usually start at the beginning of RAM and build upward. So putting too much on the stack may push it down far enough overwrite variables. That may kill your code immediately or only occasionally, like at the worse possible moment. Maybe I’m just not smart enough, but I’ve never written a recursive function for a microcontroller and I don’t plan on it. For the same reason, I also try not to nest function calls too deep.

93