An Embedded system blog

Friday, October 14, 2011

Effective use of header file and .c files

I recently worked with some embedded system teams who were struggling with the best way to use .c and .h files for their source code. As I was doing this, I remembered that back when I was learning how to program that it took me quite a while to figure all this out too! So, here are some guidelines on a reasonable way to use .c and .h files for organizing your source code. They are listed as a set of rules, but it helps to apply common sense too:

Use multiple .c files, not just one "main.c" file. Every .c file should have a set of variables and functions that are tightly related to each other, and only loosely related to the other .c files. "Main.c" should only have the main loop in it.
.C files allocate storage and define executable code. Only .c files have a function defined in them. Only .c files allocate storage for variables
.H files define external storage and define function prototypes The .h files give other modules the information they need to work with a particular .c file, but don't actually define storage and don't actually define code. The keyword "extern" should generally be showing up in .h files only.
Every .c file should have a corresponding .h file. The .h file provides the external interface information to other modules for using the corresponding .c file.

Here is an example of how this works. Let's say you have files: main.c adc.c output.c process.c watchdog.c

main.c would have the main loop that polls the A/D converter, processes values, sends outputs, and pets the watchdog timer. This would look like a sequence of consecutive subroutine calls within an infinite loop. There would be a corresponding main.h that might have global definitions in it (you can also have "globals.h" although I prefer not to do that myself). Main.c would #include main.h, adc.h, output.h, process.h and watchdog.h because it needs to call functions from all the corresponding .c files.

adc.c would have the A/D converter code and functions to poll the A/D and store most recent A/D values in a data structure. The corresponding adc.h would have extern declarations and function prototypes for any other routine that uses A/D calls (for example, a call to look up a recent A/D value from polling). Adc.c would #include adc.h and perhaps nothing else.

output.c would take values and send them to outputs. The corresponding output.h would have information for calling output functions. Output.c would probably just #include output.h. (Whether main.c actually calls something in output.c depends on your particular code structure, but I'm assuming that outputs have two steps: process.c queues outputs, and the main.c call actually sends them.)

process.c would take A/D values, compute on them, and queue results for output. It might need to call functions in adc.c to get recent values, and functions in output.c to send results out. For that reason it would #include process.h, adc.h, output.h

watchdog.c would set up and service the watchdog timer. It would #include watchdog.h

One wrinkle is that some compilers can only optimize in a single .c file (e.g., only do "inline" within a single file). This is no reason to put everything in a single .c file! Instead, you can just #include all the other .c files from within main.c. (You might have to make sure you include each .h file once depending on what's in them, but often that isn't necessary.) You should avoid #including a .c file from within another .c file unless there is a compelling reason to do so such as getting your optimizer to actually work.

you can see my another post about making a header file.

This is only intended to convey the basics. There are many hairs to split depending on your situation, but if you follow the above guidelines you're off to a good start.

Animation and custom character on lcd

Hello friends I have been very fascinated about the custom character generation on normal (16x2) LCD

So I decided to have some hands on about it. I started reading about it on net and finding data about CGRAM.

I came across many good websites they are listed at the end of the post..

There are mainly two RAMs in our LCD display

1)DDRAM-you put the ASCII value and it is displayed on the screen (normally everybody is aware with it)

2)CGRAM-discussed below in detail

CGRAM is 64 Byte ram we can use it to make 8 custom characters.so this is clear that each character consist 8 bytes now let us start generating a custom character.

Each block we see in our LCD is 5x8 pixels(5 columns & 8 rows) we can configure lcd row by row as shown in the figure thus we get 8 bytes for one pixel.

We can make 8 characters in CGRAM so after obtaining the values of each row just load it to CGRAM .To do so you have to point starting address of RAM you can take help of the below given able you have to do 0x40+(CGRAM address)once a byte is written on the RAM location then you need not to point the next data then the pointer is incremented by itself.

Now if you have constructed your character in CGRAM how would you display it ?

This is the question puzzled me the most. I’ll try to explain in easy words .once you have created your character in any location in CGRAM (say 1^st location=0x40 to 0x48) and you want to display it in any location (say 1^st row 6^th column=0x86)then point to 0x86 by using “lcd_cmd(0x86)” and write ASCII value zero (‘0’)(this is the equivalent value of CGRAM 1^st location)there you can see the table below to get the ASCII values of Characters generated in CGRAM.

So you are now done with all the basics of generating a custom character you can generate a character independently or with the help of two or more blocks as shown below.