Hi, I am using Netbeans for my IDE instead of PN. Everything works great except I get some nit problems with the code assistance. The problem is the assistance is flagging as an error these lines in the initialload.c program:

DDRC |= (1<<PC4); PORTC |= (1<<PC4); PORTC &= ~(1<<PC4);

It is saying that it is "Unable to resolve DDRC, PC4, PORTC variables"

What's funny is that it doesn't stop me from building the project/code and runs the existing Makefile compiling, linking and loading the uC just fine.

I am using the downloaded source code for this so the includes are the same in the following order:

include <stdio.h>

include <avr/io.h>

include <avr/interrupt.h>

include <avr/pgmspace.h>

include <inttypes.h>

include "../libnerdkits/delay.h"

include "../libnerdkits/lcd.h"

I've made sure the the winAVR include paths are a part of the project and should be searched which is why I think everything is still working properly. I'm no C expert and I assume everybody is using PN but I thought I would ask here anyway. Anybody have any thoughts on why this may be happening. I've been using NetBeans for quite some time so I am not rushing to quickly to judge that the problem is in their system.

Thanks,

    Chris

I've recently started using netbeans too. It flags errors for me whenever I access the registers. I think it's because they are MCU specific and not declared anywhere (as far as it knows). I'm not sure how to fix it, but I would be interested to know if you figure it out.

Hi crizzo99 and huzbum,

This is just a guess, because I have never used NetBeans, but I think the avr-libc documentation for io.h offers some insight as to this problem. In addition to defining some other things io.h also looks at the -mmcu switch given to avr-gcc to load the appropriate avr/ioXXXX.h header. The switch is defined in the Makefile, which explains why it works when you compile, but doesn't work for NetBeans stand alone compiler.

I think if you explicitly add <avr/iom168.h> to your includes this issue might go away.

Humberto

You can actually turn these errors off specifically if they are bothering you that much.

Open the options menu and along the top you will see a big "C/C++" icon (assuming you have the C/C++ plugin installed). Click this and go to the highlighting tab and un-check "Highlight Unresolved Include Files" and "Highlight Unresolved Identifiers"

Humberto and Others,

Thank you all very much for your assistance. Humberto's suggestion works perfectly. This definitely appears to be a problem in the Netbeans code assistance software and/or the AVR include files (or both) that one or the other doesn't like. When researching this I did notice the linkage between io.h and all the specific uC include files but I noticed they stated very clearly not to include them directly so I didn't, thinking the problem might be elsewhere. Stupid me, not that my computer would blow up or something if I actually stuck it in there and ran a test. Oh well, live and learn.

Like I stated before I am not a very proficient C/C++ or uC programmer (yet). That's why I am starting with the NerdKit... Anyway, I depend a lot on the Netbeans IDE to allow me to view the prototypes, declarations, definitions, defines, etc. to increase my understanding of where these are identified. They (Netbeans) have a nice interface to do this and I rely on it a lot. I am happy Humberto's suggestion solves the issue and now I can get back to the important stuff...learning!

Thanks again, Chris

Hi crizzo99,

Glad you have it working. The reason the documentation suggests you not include these files directly is for portability. By including a header file meant for a specific chip you are making your code work only with that chip type. It is generally recommended from a design stand point to try and keep the specific hardware abstracted away from the code, but to make something work with and IDE temporarily, its not going to hurt.

Humberto