Re: [avr-chat] HowTo split a program into several files ?

[Bernard Fouché]

Till Harbaum wrote:

> Hi,
>
> On Monday 12 September 2005 18:10, Vincent Trouilliez wrote:
>  
>
> > Okay I changed the <foo.c> for "foo.c" and the compiler is now
> > happy ! :o)
> >
> > --
> > Vince, who can now keep his programs very tidy...
> >    
> Uhm ... unfortunately noone told you, that this isn't the way to split 
> programs ... it works, but it's soooooo ugly.
>
>
>  
Also:

- Use #include <...> when you want to include a header coming with the 
system (i.e: provided by the compilation environment). Paths processed 
by the preprocessor for '<..>' are defined in the preprocessor itself 
and usually it's '/usr/include' plus eventually some others. You can add 
paths to this with the -I option. For instance: -I/my/include/dir. The 
point of "<..>" is to think that files included this way are well-known 
ones and you don't really care where there are stored.

- Use #include "..." for files related to the application being compiled.

If you develop an application framework, and others programmers will use 
it, then usually you do something like:

- /home/appframework/include <- will hold all .h related to the 
application framework you provide. Inside you can have subdirs for 
different 'modules' (for instance include/communications , include/setup 
, etc)
- you will tell to programmers wanting to use your frame work that they 
must add -I/home/appframework/include in their makefiles and use 
#include <..> (of course you have to provide documentation telling what 
include is needed to get what function prototype, etc)
- if such a programmer needs to make his/her own .h file, this file will 
be included with #include "..."
- you will probably also provide /home/appframework/lib with libraries 
to include (-L/home/appframework/lib -llibname..)

A big part of learning C is knowing these habits. If you known them and 
stick to them, you'll feel at home very quickly when moving to a 
compilation environment to another.

Another unsaid rule is that someone using a compilation environment or 
an application framework requiring use of '<...>' to include /h files 
must not modify these .h files since they can be upgraded at any time by 
the provider of the application framework or compilation environment.

For instance there are actually a lot of talks about changing the API of 
avr-libc. If you stick to the habit of including the avr-libc .h files 
without modifying them, and locate all your own stuff and possible 
changes in your own .h files, then chances are great that the API 
changes will be transparent to you. Otherwise it can be a nightmare.

Other usuals C habits:

- use a #define each time you need a constant. For instance:

for(i=0;i<3;i++) is no good but

#define NBR_OF_NEEDED_SCANS
for(i=0;i<NBR_OF_NEEDED_SCANS;i++) is better

(this will document your source files in some way)

- Of course you locate all #define's in .h files

- use enums in any state machine using a switch/case system. Enums will 
of course be defined in a .h file.

- constants are always in uppercase. Variable may have uppercases 
letters but must has lower cases also.

- names beginning with '_' are reserved for the system designers.

- Do not allocate memory in a .h file, just define structures types, 
typedef, enums, etc and make the memory allocation in a .c file.

For instance:

x.h:

enum toto { START, MIDDLE, END };

struct foo {
enum toto shmoo;
int bar;
int wuz;
}:

x.c
#include "x.h"
struct foo myfoo;

- etc.

C allows you to mess up everything since there are nearly no mandatory 
requirements to organise your work. So some kind of organisation has to 
exist and if you use the same one used by C programmers for decades 
you'll spare a lot of time, it will help you feel that code you run into 
that has been written by others could have been written by you.

Bernard