[Icc-avr] Are 'local' vars in main automatuc or in bss?
Jaspers, Ton
t.jaspers at cpseurope.com
Fri Oct 26 03:06:50 PDT 2007
moduleX.h:
#ifndef __moduleX_h__
#define __moduleX_h__ /* avoids multiple inclusion */
typedef enum
{
HARD_TYPE,
SOFT_TYPE,
SEMI_SOFT_TYPE
} type_t ;
typedef struct { type_t type, int value } global_t ;
extern global_t globalvar ; /* try to avoid these */
void interfacefunction(void) ;
#endif /* end of #ifndef __moduleX_h__ */
moduleX.c:
#include "moduleX.h"
#define public /* replaced with "", for readability only */
static int variabvle_one ; /* scope limited to this module */
public global_t globalvar ; /* try to avoid these */
static void localfunc ( void )
{
statif first = 1 ; /* scope limited to this function */
int count ; /* automatic (on stack) will be destroyed after return */
if ( first )
{
first = 0 ;
....
}
.....
}
public void interfacefunction(void)
{
.....
localfunc() ;
}
Hope this helps,
Ton
> -----Original Message-----
> From: icc-avr-bounces at imagecraft.com
> [mailto:icc-avr-bounces at imagecraft.com] On Behalf Of Bengt Ragnemalm
> Sent: vrijdag 26 oktober 2007 11:26
> To: 'Discussion list for ICCAVR and ICCtiny Users. You do NOT
> need tosubscribeto icc-announce if you are a member of this.'
> Subject: SV: [Icc-avr] Are 'local' vars in main automatuc or in bss?
>
> David, can you show us in an example how it should be done? I
> try to do just as you describe but I often step into problems
> with error like double defines and so on.
> I have tried using the typical #ifdef MAIN and so on but have
> failed making it work properly. I usually have a header file
> for every c file (that should be the very basics) and in that
> header file I put declarations on the functions. The header
> file is included in every other file that uses the functions.
> I think one reason for my problems may be that I usually in
> the "project.h" (there my main is) have a lot of constants
> and maybe some typedef that I want the other files be aware
> of so I include it in all other project files (not reused
> files like drivers). The compiler do not like that I put
> extern everywhere, as it is used even in my project.c. I do
> not want to explicity write in every global variable in the
> c-files (extern nn), I want to just include a .h file, I hope
> that is the normal procedure.
>
> You can expand my little example in any way you like. I tried
> to use self-descriptional names. There should I put the
> extern and there should I put the typedef customType?
>
> /Bengt
>
>
> To be placed somewhere:
> typedef customType...
> #define A_VALUE 1
>
>
> Project.h
> =========
> ??? what should be in here?
>
>
> Project.c
> =========
> static char projectFileGlobalVar;
> char globalVar1;
>
> customType globalCustomVar;
>
> void AFunctionInProject(void)
> {
> }
>
> void main(void)
> {
> char projectFunctionLocalVar;
>
> projectFunctionLocalVar = A_VALUE;
> projectFileGlobalVar = A_VALUE;
> globalVar1 = A_VALUE;
> globalVar2 = A_VALUE;
> globalCustomVar = A_VALUE;
> }
>
>
> Module.h
> ========
> ??? what should be in here?
>
>
> Module.c
> ========
> static char moduleFileGlobalVar;
> char globalVar2;
>
> void AFunction(void)
> {
> Char moduleFunctionLocalVar;
>
> moduleFunctionLocalVar = A_VALUE;
> moduleFileGlobalVar = A_VALUE;
> globalVar1 = A_VALUE;
> globalVar2 = A_VALUE;
> globalCustomVar = A_VALUE;
> }
>
>
> > -----Ursprungligt meddelande-----
> > Från: icc-avr-bounces at imagecraft.com [mailto:icc-avr-
> > bounces at imagecraft.com] För David Brown
> > Skickat: den 26 oktober 2007 10:28
> > Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need
> > tosubscribe to icc-announce if you are a member of this.
> > Ämne: Re: [Icc-avr] Are 'local' vars in main automatuc or in bss?
> >
> > Graham Whyte wrote:
> > > main() is no different from any other subroutine except
> that it gets
> > > called at startup
> > >
> > > Variables declared outside subroutines or functions in any module
> > > file are Global within that module The can be referenced from
> > > anywhere within that module
> >
> > Correct up to here...
> >
> > > To make them Global to other modules, each other module needs to
> > > declare then as External
> >
> > That's wrong, and very misleading.
> >
> > Variables (and functions) get global linkage if they are defined at
> > file scope without "static" - C defaults to making them global and
> > externally accessible. Thus two "int x;" definitions at
> file scope in
> > two modules refer to the same variable at the same address,
> regardless
> > of any "extern" declarations.
> >
> > The point of "extern" is to tell the compiler about a
> global variable
> > (or function) without defining it - it allows access to a global
> > variable, but does not turn a variable into a global one.
> >
> > > This is exactly the same as making a subroutine available to other
> > modules
> > > The declarations must of course be identical
> > >
> >
> > The declaration *should* be identical - but be careful, because C
> > allows you to get it completely wrong and still be legal C.
> >
> > > You can make this very neat and tidy by putting the Globals in a
> > > separate module Then create the external declarations in
> a separate
> > > header file which you can #include wherever you need You
> then only
> > > got one copy to worry about
> >
> > I've seen programs made like this - as Ton says, "Yuck!".
> >
> > If you want to write programs that are readable, understandable,
> > debugable and maintainable, and allow for at least some level of
> > re-use between programs, then you will avoid this setup
> like the plague.
> >
> > Modularisation is critical to writing software. Break your program
> > into parts that fit logically together, and figure out what
> data and
> > functions (and types, macros, etc.) that module makes available to
> > other parts of the whole program. This information is your
> module's
> > interface, or API, and forms its "module.h" header file.
> >
> > The header file "module.h" contains comments about how to use the
> > module, along with all type declarations, #define's, "extern"
> > declarations of data and functions, and any #include's that
> are needed
> > to *use* the module (for example, if it contains a line "extern
> > uint8_t count;", then it should also contain a line "#include
> > <stdint.h>" or equivalent).
> >
> > The C file "module.c" contains the *implementation* of the
> module, and
> > has #include "module." near the beginning. Every
> file-scope variable
> > or function is either private to the module, and defined "static",
> > *or* it has a corresponding "extern" declaration in
> "module.h". There
> > should be no exceptions (except perhaps temporarily to aid
> debugging,
> > since you can see non-static items in the map file).
> >
> >
> > As I said in an earlier post, I tend to rant a bit and treat my
> > methods as the only correct methods, but in this case there
> is no real doubt.
> > If you look at any other properly structured programming language,
> > such as Pascal, Modula 2, or Ada, you'll see that this is
> exactly the
> > way good modular programming is always done - other
> languages enforce
> > these rules.
> >
> > mvh.,
> >
> > David
> >
> >
> > >
> > > Graham
> > >
> > > -----Original Message-----
> > > *From:* icc-avr-bounces at imagecraft.com
> > > [mailto:icc-avr-bounces at imagecraft.com]*On Behalf Of
> > > *bobgardner at aol.com
> > > *Sent:* 25 October 2007 14:30
> > > *To:* icc-avr at imagecraft.com
> > > *Subject:* [Icc-avr] Are 'local' vars in main automatuc or in bss?
> > >
> > > Great summary of 'static' vars.... I remember in pascal the scope
> > > 'nested' and stuff 'up a level' was visible, but c doesnt allow
> > > nested functions I guess. Just to clarify, if I declare vars in
> > > main, are they local or in the bss? Is main a subroutine that is
> > > called with params and returns a value? Is the iccavr
> > > microcontroller model different from a ram based system
> with an os?
> > >
> --------------------------------------------------------------------
> > > ---- Email and AIM finally together. You've gotta check
> out free AOL
> > > Mail
> > > <http://o.aolcdn.com/cdn.webmail.aol.com/mailtour/aol/en-
> > us/index.htm?ncid=AOLAOF00020000000970>!
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > ----
> > >
> > > _______________________________________________
> > > Icc-avr mailing list
> > > Icc-avr at imagecraft.com
> > > http://dragonsgate.net/mailman/listinfo/icc-avr
> >
> > _______________________________________________
> > Icc-avr mailing list
> > Icc-avr at imagecraft.com
> > http://dragonsgate.net/mailman/listinfo/icc-avr
>
>
> _______________________________________________
> Icc-avr mailing list
> Icc-avr at imagecraft.com
> http://dragonsgate.net/mailman/listinfo/icc-avr
>
More information about the Icc-avr
mailing list