In the past I have done various small assembler projects, employing only
one file to compile.
Now I have to write a bit larger embedded software in C and I wonder how
to organize my source code to keep it maintainable as good as possible.
Is there an online resource explaining what goes in which header file,
what goes in which .c file and how to reference each. How do I get some
structure in my source code so that I can keep track of what I have done?
The books I have explain C in detail, but not how to organize one's
source code.

TIA,
Michael

Good question.

Visibility is one good criteria. If something needs to be visible to more than
one code file, you put it in a header file.

As for grouping code, I think you'll find out what code should be grouped
together. For example, you might put timer code in one file, serial port code
in another, display code in another. Ideally, I'd shoot for also separating
code that could be applied to the hardware for any project, and the code
specifically for your project. Sort of like having driver code separate from
application code.

Hope this makes some sense.

In article <3F334929.10708@gmx.net>, Michael Hofmann <westbound@gmx.net>
writes
Try "Embedded C Traps and Pitfalls" on http://QuEST.phaedsys.org It's
not perfect but it is free. IT will give you some pointers. Also the
Tile Hill Style Guide for embedded C on the same web site.

Also http://www.accu.org for over 300 book reviews including a section
on embedded C

Regards
Chris


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Gary Kato wrote:

I agree. My style is to write a header file for each code file with
corresponding name (there may be other headers, as well). The header
file becomes the interface definition. I aim to have the header file
specify everything that is needed to use the code file, including
comments on the function usage. When I am working with another
programmer, I often create a header file defining the interface for the
module that the other programmer will write or that I will provide for
him to use. If I receive a question about the what one of the functions
is to do in a certain case, I usually answer by providing more
specification in the header file.

Each code file includes its corresponding header file so that the
compiler checks the prototypes against the function definition.

Thad

"Gary Kato" <garykato@aol.com> wrote in message
news:20030808034514.02803.00001092@mb-m19.aol.com...
I agree. As for the "driver" idea, I'd suggest this too. I think too much
like an over blown OS, but I really like the idea of keeping the ultra low
level away from the higher level parts of the system because it means the
higher level ends up being very well defined. Sort of like the gate keeper
between all the little different bits of hardware. Otherwise I end up with
really bad code which is all over the place. *cough* currently rewriting a
little mess *cough*

I've been cleaning up code on a system I've been maintaining for years (in
Forth). I'd love to achieve a separation so that if a vendor stops supplying a
piece of the system, it won't affect as much code to use someone else's
hardware. Sometimes this can be hard to achieve when the choices of hardware
are too different, but I try. I'm still working on that separation too. :-)