Embedded nubie help

No, it DOESN'T refer to external and internal RAM- I understand your confusion- it refers to the SCOPE of the variable. An "extern" variable is one that is "created" and perhaps initialised in another file. He has defined a macro EXTERN that converts to a blank in the definition file, and as the string "extern" in all the other files.

Take the variable

EXTERN int BreadBasket;

So in the file where _GLOBAL_H_ is defined, this converts to just:

int BreadBasket;

but in the other files it converts to:

extern int BreadBasket;

What he's trying to do is ensure that the variables get defined in the same way for all files. Imagine writing in one module:

extern int ChoppingBoard;

and in another:

float ChoppingBoard;

The result is chaos. I know, I've done it!

Paul Burke

Paul

You seem to have misread a little - Rob said he is happy that xdata and idata refer to external and internal RAM, he wasn't referring to EXTERN/extern at that point.

The rest is fine though :-)

Best Regards John McCabe

To reply by email replace 'nospam' with 'assen'

new

are

David, I'm invoking the rule that says you don't get away with asserting the existence of better techniques unless you are prepared to show examples.

Given the declarations at hand, which are defining memory-mapped registers, using a language extension, what do you suggest as an "easier and safer way to ensure consistenccy"? Please show example code, using

int at 0x500 xdata; else extern int xdata;

as part of your example. In other words, show us how to accomodate that specific language extension.

Of course it does. C is a case-sensitive programming language, after all.

[...] [...]

This is one of several different tricks people like to pull off to avoid one of the little quirks of C: the fact that the preprocessor is the only thing you get to couple individual source modules together.

Without this hack, you would have to write down every global variable twice: once as a "definition" proper, like in:

int foo; or char bar[] = {0,1,2};

to be found only exactly *once* in the whole source tree. The second mention of each variable is in one header file. It's not allowed to be initialized, and is flagged with "extern" keyword to make it a "declaration" instead of a definition:

extern int foo; and extern char bar[];

Some people dislike having to type everything twice, so they invented this EXTERN hack. You write "EXTERN" instead of "extern" in the header file. With some preprocessor magic, you

#define EXTERN extern

for almost all sources being compiled, except for a single source file (per header file). That one has

#define EXTERN /* nothing */

and thus the declarations turn into definitions, in this single source file's compilation.

Note that, as given, this trick only works for un-initialized globals. For initialized ones, you need more involved tricks, like a macro

#indef MASTER_SOURCE # define EXTERN_INITIALIZED(name, initializer) extern name #else # define EXTERN_INITIALIZED(name, initializer) name = initializer #endif

This particular line in your case:

hints that this is using one of the sillier approaches to deciding which sourcefile will generate the definitions: it's the one that does

#include "global.h"

*twice*, instead of once. That plan is silly because properly written headers should always be allowed to be #include'd more than once, without changing their effect. Otherwise, you'll have a hell of a time extending their usage to larger projects.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Lowercase extern is a reserved word. It informs the compiler that the following variable exist somewhere. Allow this module to work with it but don't allocate any space for it. That's ecough for the compiler (The Linker will later verify that the variable really exists)

Uppercase EXTERN is being defined as nothing or as extern, depending if _GLOBAL_H is defined. If _GLOBAL_H_ is defined, then EXTERN is turned into white space. Any variables defined will also have memory allocation. If it's not defined the EXTERN is turned into extern and the preceding paragraph applies

Hope this helps, Yaakov

-------------------------------------------------------------------------------------

programmer

to

dealing

the

Fair enough - I didn't want to complicate matters for the OP by showing different methods - I just wanted to point out that there are other ways of dealing with externs, so that he did not "learn" from the code he is fixing now. I thought maybe he'd ask when he was ready, or else find some book or tutorial on C.

registers,

way

That's a non-standard extension, which is not used on any compiler I have, but I guess my system will work fine there too. The system I use is, as far as I know, widely used by C programmers on big and small systems.

As an example, consider a program that reads an analogue input and drives a pwm output to the value read, and you want to split the program into neat modules. Then you have files such as:

/* common.h */ typedef unsigned char byte;

/* pwm.h */ extern void initPwm(void); extern void setPwm(byte newPwm); extern byte currentPwm;

/* pwm.c */ #include "common.h" #include "pwm.h"

byte currentPwm; void initPwm(void) { .... }

static void doSetPwm(byte newPwm) { ... }

void setPwm(byte newPwm) { if (newPwm != currentPwm) { currentPwm = newPwm; doSetPwm(newPwm); }; }

/* adc.h */ extern void initAdc(void); extern byte at 0x500 input; extern void pollAdc(void);

/* adc.c */ #include "common.h" #include "adc.h"

byte input; static byte samples[4]; /* For average filter */ void initAdc(void) {...} void pollAdc(void) {...}

/* main.c */ #include "common.h" #include "adc.h" #include "pwm.h"

void main(void) { initAdc(); initPwm(); while (1) { pollAdc(); setPwm(input); }; }

The whole idea is that each module has its own global data and functions, which are declared as extern in that modules header file. The module itself also #include's its own header - any conflicts between the extern declerations and the definitions show up as compiler errors when the module is compiled. I also prefer to declare functions and data as static if they are not global, but that is not really necessary (unless you are working on big programs, especially in colaberation with others). The advantages of this system are that modules are much more self-contained, their external interface is completly specified in the module header file, you can't get conflicts between declerations and definitions (unless you fail to re-compile modules as necessary - in which case, you need to learn "make"), and your code does what it says it does (i.e., no claims of "EXTERN" when you really mean a definition).

OP = Original Poster

Regards, Doug

Okay, I give up. What is "OP"?

-=Dave=-