i think i've got the following two ideas more or less correct:

1) foo.c is source C code written by a programmer

2) foo.o is made by compiling foo.c and is a translation of the data and instructions in the source code to machine code instructions the microprocessor understands

so where do foo.hex and foo.h files fit in?

Keith -

The "foo.o" is a binary file (i.e. non-text) that is an intermediate file created by the compiler program "avr-gcc". There is another file "foo.hex" that gets created by a linker from one or more "*.o" files. This is the file that gets transferred to your microcontroller. The "foo.h" file is an optional file that contains function prototypes, define statements and other things related to your program. A good example of all of this is using the "delay.h" functions from the NK directory inside your code. If you have "delay.h", the compiler will know how to create "your_program.o" from "your_program.c" if it uses the delay functions. The linker will then create "your_program.hex" as long as it knows where to find "delay.o". What is realy interesting is "delay.c" is not needed here at all. So if the NK guys wanted to be proprietary, they could just give you "delay.o" and "delay.h" and you'd have no way of seeing how they implement each function call. You would know how to call the functions by looking at the "delay.h" text file, but not the nitty gritty details inside the functions.

thanks pcbolt... i did have it wrong...

please check this to see if i've got it straight:

1) write source code and save in foo.c file

2) insure that Makefile is up to date with correct program name (foo), mmcu (atmega168 or atmega328p), serial port name (cu.usbserial for my computer) and any other changes

3) run make from terminal with working directory = the directory containing foo.c and Makefile

      3.1) compiler reads foo.c then generates object code and stores it in foo.o

      3.2) linker finds constants, macros, functions and other stuff(?) called by foo.o,  combines the object code for the called items with foo.o then generates hex code and stores it in foo.hex

      3.3) foo.hex is downloaded through the serial port (cu.usbserial for me) to the mcu in program mode

assuming that's correct i now have another question:

if i add io_328p.h to the libnerdkits folder/directory do i need to modify the Makefile to something like:

GCCFLAGS=-g -Os -Wall -mmcu=atmega328p

all: delay.o lcd.o uart.o

delay.o: delay.c
    avr-gcc ${GCCFLAGS} -o delay.o -c delay.c

lcd.o: lcd.c
    avr-gcc ${GCCFLAGS} -o lcd.o -c lcd.c

uart.o: uart.c
    avr-gcc ${GCCFLAGS} -o uart.o -c uart.c

io_328p.o: io_328p.h
    avr-gcc ${GCCFLAGS} -o io_328p.o -c io_328p.h

and then run make from the terminal (in the libnerdkits directory) to generate the io_328p.o file or will that happen automatically the first time i run make for a 328p project?

hope i'm not boring you to death... thanks keith

i forgot one modification to the Makefile in the libnerdkits directory... make line 3:

all: delay.o lcd.o uart.o io_328p.o

Keith, the .h files are "included" in/from your .c source file!!

#include <stdio.h>

Ralph

thanks Ralph... now that you point it out it's obvious...

the reason why i asked is because i (stupidly) did exactly what i described above and i'm thinking that, because it's not a normal project, when the make command downloaded it to my mcu it may have overwritten something in the mcu's reserved memory that's involved with sending control signals or data to the lcd...

the above doesn't seem likely but i'm fustrated about not being able to send output to any of my lcds and get an expected display... see the support forum>>putting atmega168 and atmega328p projects in different folders/directories (you've already given me valuable help there)

if i have done something stupid do you think there is a way to reload the mcu's reserved memory (is bootloader involved with that?) or should i just buy new 168 and 328p chips? they're not expensive...

thanks to Rick_S it turns out that all my problems are due to a code optimization problem... in the thread Support>>Ubuntu LCD problems the LCD displayed the same problem as mine and some simple changes to the makefiles in the project and libnerdkits directories, trashing all .o and .hex files and recompiling fixed the lcd display problem...

thanks to all for helping... Merry Christmas... k

• i'm thinking that,

Careful with that "thinking" act it can really get you into serious/vexing/unfathomable problems.

Best to do what you know (working code) and build off that, one line (compiled and running) at a time.

Ralph

thanks Ralph... it looks like i was way up in non-existant branches of the wrong tree... but now that i have initialload compiling and running again it's time to go check out my other projects... Merry Christmas... k

i was way up in non-existant branches of the wrong tree...

Been there, done that

Ralph

you're very kind... it turns out that Rick_S turned me on to a thread called Ubunto LCD problems that suggests turning off optimization by changing the -Os option and deleting the -j .text option under avr-objcopy in the project's makefile... this works :)

but i'd still like to optimize my code but even the option -O1 causes compiler errors and i still don't know what the -j option does... Rick and Noter have given me some links in my error 1 thread which i'm going to start studying after posting this...

again thanks and wishing you and yours a very Merry Christmas... k