Count_Binary alt_u8 not found

[Altera_Forum]

I have a simple NIOS II/s running the count_binary example. Eclipse is used as installed by Altera. The problem I'm running into is if you start a new project and select count_binary everything is fine. However, when you quit Eclipse and start it up again, the count_binary.c file shows errors. It cannot find alt_u8 is one error. There are several all related to libraries. I check the properties of the count_binary.c and the path is there. It only happens when you quit Eclipse and then start it up again. Why does it find the libraries only when you create a new project and never again? Any idea as to what is wrong?

[Altera_Forum]

swimteam, 

 Are you referring to C/C++ Indexing errors (specific to the Eclipse IDE/CDT -- CODAN, code analysis) or are you actually seeing build (GCC toolchain/make) errors? The former should be transitory and can usually be ignored. The latter....well, it depends. :-)

[Altera_Forum]

Perhaps you restarted eclipse without having the environment variables set?

[Altera_Forum]

What do you mean. I installed Quartus 13.0.1 spi Webpack. NIOS was included which uses Eclipse. I created a NIOS II/s processor. Then, started Eclipse and created a new project. I used count_binary. This compiled and executed OK. However, when I closed Eclipse and then started it again, the count_binary.c file showed errors. What I did was to add to include statements in the count_binary.c file: # include "alt_types.h"# include stdio.h The errors went away. If I remove the two lines the errors come back. Both of those includes are in the count_binary.h file. So, why did Eclipse find these files when the project was first created but doesn't if you close Eclipse and start it again? Something is being altered.

[Altera_Forum]

Regardless of what Eclipse "thinks", it sounds to me like you're able to build successfully...even without the addition of the# include(s) in count_binary.c. So, to me, this sounds like an Eclipse CDT CODAN issue. I think it's the C/C++ indexer/code analyzer that is throwing that error. 

 These sorts of errors are annoying, but harmless. Generally, they can be fixed by adding the includes to the Eclipse project's include paths. CODAN isn't smart enough to parse the Makefile to determine where to look for included headers.  Cheers!  slacker

[Altera_Forum]

Thanks. I right clicked on the project name, count_binary, selected Properties, C/C++ General, Paths & Symbols and added a library path to the count_binary_bsp ... HAL/inc. That took care of the errors caused by alt_types.h. However, the error "cannot resolve NULL" is being caused by the stdio.h library. That include is in the count_binary.h file and should NOT have to be in the count_binary.c. When I put it in the .c file the error goes away. It appears that Eclipse or the preprocessor is not even reading the count_binary.h file which is the only include in count_binary.c. Whoever designed these examples didn't have an# include stdio.h (left and right errors don't work in these posts) in the count_binary.c so why do I? So, what path should I put for the stdio.h?

[Altera_Forum]

I just found the answer. I put# include stddef.h into the count_binary.h. The error went away. No one else has had this problem?

[Altera_Forum]

swimteam: 

 I also just fell into the same hole that you described: yesterday, I successfully worked thru the count_binary sample, shut down, etc., only to find today that alt_u8, null, and file could not be resolved once I re-opened the project this morning.  I experimented with your steps, then ended up adding the three include paths from the software/count_binary base directory to the count_binary_bsp includes Paths and Symbols. As you discovered, and I just confirmed, stddef.h had to be manually added to count_binary.h.  I used Eclipse before (about 4 years ago), but this really seems convolved - even for Eclipse. Engineer Scott's famous statement came to mind: "the more they overthink the plumbing, the easier it is to stop up the drain."  Thanks much for your post and solution. Thanks! Dave

[Altera_Forum]

I just ran into this same disturbing issue in my own code, and I was able to resolve it timely by adding to the C++ and C library paths per swimteam's instructions. 

 Thank you for taking the time to share!  Cheers --todd