Having followed the 328 upgrade guide to a t I keep running into a problem with my include of the new header file.

When I try to compile I always get this error message "error: #include expects "FILENAME" or <FILENAME>"

I would point out that I have the include and the file properly set up. thinking maybe the underscore in the file name wasn't jiving with the compiler i tried removing it from both the file itself and the include. Then I tried putting it in directory with the source and changing the include to point to it. I tried linking it in the makefile. I'm at a loss. I updated winavr. I copied the source and library directories to a clean directory. I redirected my tools to make sure they were operating in the correct directory. I can not for the life of me figure this out.

Hi delinthe,

Do you have quotes around the name of the file, it sounds like that is what the compiler is complaining about. Just so we can take a look, could you copy in the top part of your .c file (where you are including the new file).

Humberto

as per your request (keeping in mind that i have renamed the header file to no longer include the _ as one of my previous attempts at correcting the issue.

#define F_CPU 14745600

#include <stdio.h>
#include <math.h>

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <inttypes.h>

#include "../libnerdkits/delay.h"
#include "../libnerdkits/lcd.h"
#include "../libnerdkits/uart.h"
#include "../libnerdkits/io328p.h"

I had originally tried it verbatim from your upgrade guide with the underscore in place both in the file name and in the include.

If I comment out that specific include it compiles just fine. But of course without the added definitions of pin assignments provided in the header file none of my previous programs will operate without having to swap out all of my pin states for their actual memory addresses.

I've tried moving the header file into the local directory with my code and changing the include to reflect that change as simply "#include "io328p.h"

I noticed something odd when it references the line number of the compile error it seems to reference two numbers instead of one.

tempsensor.c:14:9: error: #include expects "FILENAME" or <FILENAME>

could that 9 actually be the ninth line of the header file itself? I dont know if it is any help but i was also getting another error.

tempsensor.c:112: warning: 'SIG_OUTPUT_COMPARE0A' appears to be a misspelled signal handler

following the advice of N3Roaster in this thread (http://www.nerdkits.com/forum/thread/451/)I got rid of that error by changing

SIGNAL(SIG_OVERFLOW0) {

to

ISR(TIMER0_OVF_vect) {

The second number is the character position on that line.

well character 9 is a space. specifically the space inbetween the #include and the "filename". I almost feel like theres something wrong with my compiler.

Are the quotes the straight up and down quotes or is it possible that some curly quotes got in there?

Regular quotes I've tried retyping the line once or twice assuming that i had made some typographical error I was just reading over. This honestly has me a bit stumped. I'm about ready to just grab my code off this computer reformat it and put windows xp on it because my usbtiny isp hates windows 7 anyway. I bet once i have a clean install of everything it just magically works again.

Well i solved it but this makes no sense to me. I took the space out so that the one include read "#include"../libnerdkits/io328p.h" and now it compiles. all of the other includes have a space infront of the leading quotation mark however.

define F_CPU 14745600

#include <stdio.h>
#include <math.h>

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <inttypes.h>

#include "../libnerdkits/delay.h"
#include "../libnerdkits/lcd.h"
#include "../libnerdkits/uart.h"
#include"../libnerdkits/io328p.h"

Reformatted the computer, installed windows xp pro. Fresh winavr install. Now it is working normally. Not exactly sure what in my setup was broken but that was alot easier and faster than trying to track down an outdated dll file or whatever was making it act like that.

Well thats strange. Glad you fixed the issue.

Humberto