I am programming in CCS (based on Eclipse) to learn to use microcontrollers.
I'm having some problems with includes.
I have 4 files:
GPIO.h - macros and prototypes of GPIO functions
GPIO.c - implementation of GPIO functions declared in GPIO.h
main.c - main program
util.h - macros and typedefs essential to all other files
In each of the programs put the includes, I ctrl + c / ctrl + v of my code:
I really try with " ", I would like to make my code run, it would be rewarding.
GPIO.h - #include "util.h"
GPIO.c - #include "GPIO.h"
main.c - #include "GPIO.c"
util.h - (no includes)
As in eclipse all files are placed in the project folder. Already checked manually by accessing the folder, and they are there.
When I compile and run, there are 2 errors referring to include:
"../GPIO.c", Line 9: fatal error # 1965: Can not open source file "GPIO.h"
"../main.c", Line 1: fatal error # 1965: Can not open source file "GPIO.c"
I do not understand what's wrong!
I made the edit so that people understand that even with "" the error continues (# mame98). I made it clear that I am using the CCS IDE based on Eclipse and now my suspicion is with the operating system. I will have the opportunity to test on Windows only now.
You should only include H files as Eugene Sh. Points out... Also, use #include "util.h" and #include "gpio.h" as they are local files and they are not in the default search path of your compiler. If you want to include 'global' headers (which are in the search path) you have to use #include <file.h>.
Maybe also note, that it is possible to add your local folder to the search path with using the -I. option for GCC (should work with other compilers too).
For more infos about the search path, see here.
<> is for libraries like #include <stdio.h>
"" is used for your own files #include "GPIO.h"
Be careful including .c! If GPIO.h is included in GPIO.c, too, you could get errors..(multiple inclusion protection is useful here!)
Related
This is a question of an embedded application, but I imagine the solution is language (C) based and not specific to the embedded compiler (XC16) I'm using.
Problem
I have a number of code files I am abstracting from a single project to create a shared collection of files that can be re-used across multiple projects. These files will require a config.h file in the main application to #define a number of parameters for that project.
Example
Files in project
config.h
#define BUFF_SIZE 4
main.c
#include "config.h"
#include <lib.h>
/*Application Code*/
Files in 'Library' (i.e. another folder NOT in the project structure)
lib.h
extern uint8_t Buffer [BUFF_SIZE];
lib.c
#include "lib.h"
uint8_t Buffer [BUFF_SIZE];
Question
This produces the issue that 'BUFF_SIZE is un-declared in lib.h'. My understanding was that the compiler would start in main.c load in the `#define' values from config.h THEN try to process the lib.h header. But it seems this is not the case.
Do I have to back reference the library to the config.h file? This seems to work, but it then forces the application to have specific file names.
Are there any good examples of how this sort of structuring should take place?
Additional Notes
The same issue arises when I try and map pin outputs for bit-bang functions. i.e.
config.h
#define DATA_OUT LATBbits.LATB4
lib.c
void SetPin(void)
{
DATA_OUT = 1;
}
Cheers :)
C code is compiled on translation unit basis. A translation unit being one single .c file and all the h files it includes. So you must include "config.h" from "lib.h".
You also need to use so-called "header guards"/"include guards" in every header. See
Creating your own header file in C
I have a program that went like this:
//this is main.c
#include <stdio.h>
#include <stdlib.h>
...
#include "fileA.c"
#include "fileB.c"
...
//rest of main file
which worked fine but now when I replicated the exact same project (in VS) all the other files in the project don't seem to recognize the standard library #includes from some reason.
any help please?
Other files are independent files. As such, you must include the relevant header files in those files as well. Also, it is not considered a good practice to include .c files as it can easily result in linking errors due to multiple definitions.
I can't link properly to glew.
I have done:
#define GLEW_STATIC
#include "glew/glew.h"
#pragma comment(lib, "glew/glew32s.lib")
However, I still get the error:
LNK2019: unresolved external symbol __glewGenBuffersARB referenced in function initialize
Save yourself a lot of trouble and just put the glew.c file into your project. I never bother with linking to a glew library externally. Once you have that in there, the GLEW_STATIC macro will work. It's only one file, and (if this matters to you) it will carry nicely across platforms (rather than having to rebuild several OS-specific libs).
I want to extend the excellent #TheBuzzSaw's idea by providing a more detailed answer for a cmake project.
Download GLEW sources from here.
Unzip the archive and copy two files (src/glew.c and include/GL/glew.h) into your project's directory.
Edit glew.c so that the beginning of the file looks like this:
#ifndef GLEW_INCLUDE
#include "glew.h" /* Point to local glew.h file. */
#else
#include GLEW_INCLUDE
#endif
Use the following in your main.cpp file to include static GLEW correctly:
#define GLEW_STATIC
#include "glew.h"
To build the project, you must compile and link the static GLEW library. Sample CMakeLists.txt file with the use of copied files:
cmake_minimum_required(VERSION 3.17)
project(your-project-name)
add_library(STATIC_GLEW glew.c)
add_executable(your-project-name main.cpp)
target_link_libraries(your-project-name STATIC_GLEW)
Now, you should be able to build your project without any linking errors 🎉
My understanding was always that by doing #include <header.h> it looks in the system include directories, and that #include "header.h" it looks in the local directory. But I was just looking at the python source code and it uses the "header.h" method to define headers in a sibling directory.
So in py3k/Python/ast.c it does #include "Python.h". But Python.h is in py3k/Include/Python.h
Is this something common that I've just never seen, not having worked on any real large C project? How do I tell, at least my IDE, to look in py3k/Include?
Update
I figured out how to tell my IDE to include them, it was just me being stupid and a spelling error. But I'm more interested in why "" works. Is that not the different between "" and <>?
Both #include <header> and #include "header" look in "implementation-defined places", i.e. it depends on the compiler you are using and its settings. For #include <h> it's usually some standard system include directories and whatever you configure the compiler to look in additionally.
The difference between the two versions is that if the search for #include "header" is not supported or fails, it will be reprocessed "as if it read #include <header>" (C99, §6.10.2).
You need to somehow tell your compiler what directories to search in -- for GCC this means using the -I flag. Look it up for your combination of IDE / compiler.
How does one prevent an inclusion cycle in C? ie. You shouldn't have a.h #include "b.h", which #include's "c.h" which #include's "a.h". I'm looking for a way of preventing this from happening using some sort of C directive.
I had originally thought this would've prevented this from happening:
Contents of a.h:
#ifndef __A_H
#define __A_H
#include "b.h"
#endif // __A_H
Contents of b.h:
#ifndef __B_H
#define __B_H
#include "c.h"
#endif // __B_H
Contents of c.h:
#ifndef __C_H
#define __C_H
#include "a.h"
#endif // __C_H
But it doesn't seem to work.
It does work allright: the files are repeatedly included, but the sections protected by #ifdndef/#define/#endif are not repeated, and that breaks the cycle.
Use your compiler to produce the preprocessed output and look at it for yourself. With GNU CC, you need to use "-E" option on the .c[pp] file, like this:
gcc -E $(CFLAGS) -o foo.i foo.cpp
That should work. It's written correctly in your example and compiles fine for me. Did you mistype something in your actual code, or is it really some other problem you're seeing?
You shouldn't start things out with __, though, as that's reserved for the compiler and/or system libraries. Try some other names for your guards.
Macros with leading underscores are reserved for the preprocessor/compiler.
Try changing __*_H to something more standard.
I use HAVE__*_H.
ya in addition to the above things if you are working on turbo c and you are doing a project with these source files then do not attach the header files which are #included in the source files.And even then if it is not working then try it from command prompt because some compiler options give these errors again and again.so here if the header files contents are between the #ifndef and #endif then there will be no problem even you include both the files. So try removing the header files from the project keeping them in the same directory.bcos u didnt specified environment i specified turbo C because i faced this situation once on turbo C with the header files #included in source file and attached to the project files list then there will be "multiple declaration problem".also after compiling (even with errors) go to external command line and go to directory where that file is stored and try with the filename.exe directly.ok
This works.
Just to be sure, I actually compiled a test.c that included a.h with your 3 header files.
I verified this works for several versions of MSVC, Digital Mars and GCC.