Asm to C migration

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

Reply to
Michael Hofmann
Loading thread data ...

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.

Reply to
Gary Kato

In article , Michael Hofmann writes

Try "Embedded C Traps and Pitfalls" on

formatting link
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

formatting link
for over 300 book reviews including a section on embedded C

Regards Chris

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

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

Reply to
Thad Smith

than

code

separating

from

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*

Reply to
Brett

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. :-)

Reply to
Gary Kato

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.