I'm trying to include a folder that contains a combination of around 60 .h and .hpp files. This folder contains libraries for programming robots with a Wallaby (a mini-computer-like device) for Botball competition. include is located in the same place as main.c (inside code). Up until now, this is what my header for including libraries looks like:
#include "../code/include/accel.h"
Just like accel.h, I have 60 other .h and .hpp files inside include. So, coming to my question, do I need to type out all the 60 header lines? or is there a way to include the include folder.
I'm using Clion for this project, if I can't include the folder itself, does anyone know of a shortcut in Clion to include all the files in include.
I was also thinking of using some sort of placeholder for the folder name and only specify the file type. So, for example: #include "../code/include/(generic placeholder name).h". I have no clue if something like this exists.
I would also request you to keep in mind that I'm a beginner to programming, so please keep your answers simple.
This is just for some extra info:
The Wallaby is a mini computer to which you would connect your sensors, motors, servos and cameras in order to control a robot for the Botball competition. Usually, one can connect to the Wallaby either via Wifi Direct or a cable and write programs on it directly through an online interface (not entirely sure of the word for it, but you just type in an IP address in your browser and it brings up an interface where you can make projects and code). All the code written in that interface saves directly onto the Wallaby. Here the default include statement is #include <kipr/botball.h>, so I'm assuming that botball.h (which is located on the Wallaby's storage) has all those 60 libraries consolidated in it. I got the include folder that I'm using from GitHub. This link was provided to me by one of the Botball organisers. So the main point in me trying to download the library is so that I can write and successfully compile code even when I'm not connected to the Wallaby. Hope this provides some relevant context.
Thank you for your answers!
What I'd do is
Create (maybe with scripting tools or a specific program) a "all.h" file which includes all the other header files
#ifndef ALL_INCLUDED
#define ALL_INCLUDED
#include "accel.h"
#include "bccel.h"
//...
#include "zccel.h"
#endif
Include "all.h" in your main file
#include "../code/include/all.h"
You can create "all.h" automatically every time you build your code.
CLion is an IDE for Clang and GCC. These compilers are instructed to search paths for include files by specifying -I<path> command line arguments. Any number may be specified, and they are searched in the order given, and the first match found is the file that gets included.
I am not familiar with CLion specifically but no doubt it has a dialog somewhere where you can set header file search paths.
Edit: It seems that CLion may not make this so straightforward. I understand that you have to add then via CMake: https://cmake.org/cmake/help/v3.0/command/include_directories.html#command:include_directories, but after that, the IDE will not recognise the header in the editor and will warn you of unrecognised files and will not provide code comprehension features. I believe it will build nonetheless.
Related
I am trying to implement the use of DSP in the STM32 F411RE board, but I cannot seem to include the necessary files without invoking numerous errors.
Background
I have previously had CMSIS and CMSIS-DSP working in Keil uVision, but given the code limit of 32k that puts me over the evaluation limit rather quickly. As such I have been attempting to include CMSIS-DSP into Atollic TrueStudio but this seemingly is difficult to accomplish: there is limited documentation available on the CMSIS-DSP to begin with and even less so for implementation in Atollic TrueStudio.
Some related resources can be found in the
Atollic TrueStudio User Guide
as well as
StackOverflow topic #1
and
StackOverflow topic #2
. Most other related topics I could find just refer to the use of Keil uVision or the User Guide without much further help.
Atollic TrueStudio does incorporate a in-built package manager where the base CMSIS is available for download, but it does not provide this option for the CMSIS-DSP pack.
Attempted solution
I have attempted to manually download the corresponding CMSIS package (STM32Cube_FW_F4_V1.24.0) and place the corresponding DSP package into the project file structure. This then permits the use of the DSP functions such as
#include arm_math.h or arm_rfft_fast_instance_f32 S; which can also be invoked with the use of the autocomplete functionality and as such are thus recognized by the IDE.
However, this process also invokes many errors as the included functions fail to recognize their header dependencies (such as the #include arm_math.h). I find it confusing that the main.c is able to recognize the #include arm_math.h command yet the functions included are not, but I nevertheless try to fix this by adding the CMSIS DSP to the included directories (found at 'Build properties --> C/C++ Build --> Settings --> Tool Settings --> C Compiler --> Directories`). However, this does also not remedy the issue at hand.
Code results
The function cannot find the header
However the main can find the exact same header
And the header is included in the build options -> directories
Just verified that it is also included in the 'path and symbols', which it should do automagically AFAIK once you include it in the build options:
Update
Since my OP I have made some progress, mostly via messing around with the includes, symbols and linker. I have now managed to defeat the original error (though unfortunately I have no idea how), but I have now incurred a large amount of additional errors for the startup_stm32 files.
These all appear to be bad instruction errors referring to the template files included in CMSIS (CMSIS / Device / ST / STM32F4xx / Source / Templates / ARM / ...), which somehow cannot interpret the various commands listed in these templates.
Example errors: bad instruction __heap_base
I have since figured out the issue for my project: including the CMSIS folder as available from the Github repo means that a lot of templates are present throughout the entire folder structure. When attempting to build / compile whilst these templates are still present it causes a lot of issues with invalidated types and re-defining errors.
Most of these templates are in a logical location, but some are buried quite deep down and may thus be difficult to find. I will try to make a video soon describing the process of adding CMSIS (DSP) from the github repo to your project in TrueStudio.
In the meantime, the following steps should make CMSIS and CMSIS-DSP work in your STM32 TrueStudio ProjecT:
Ensure that all templates (folders) are removed from the CMSIS folder. This may require some searching and experimenting: the particularly noxious ones are hidden in
../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/Device/ST/STM32xxxx/Source/{Templates}
whilst there are also other sets at ../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/DSP/{Examples} and ../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/DSP/{Projects} that I had removed for my project to compile / build succesfully.
Include all the folders that are named include in the folders. AFAIK you cannot just include the main ../Drivers folder, as includes do not appear to also include the underlying structure and it also seems to include errors for my project. Best to just include the folders manually: you can so so by right-clicking on the intended folder to include, click the option near the bottom "Add/Remove include path" and tick both boxes for release and debug before pressing 'OK' to include this folder. Repeat for the other 'include' folders.
Fish up the RTE_Components.h file located at ../STM32Cube_FW_xx_Vx/STM32xxxx-Nucleo\Templates\MDK-ARM\RTE. There are also files with this name (RTE_Components.h) available in the NN (Neural Networks) CMSIS-pack folder, do not touch those. Copy this file to any location that you have previously included (placed mine in ../Drivers/CMSIS/Include), and open it up in your IDE of choice. Add the line #define CMSIS_device_header " DEVICE_NAME.h " before any of the other statements and replace device name with your STM32 board name. For example, my RTE_Components.h file looks like
/*
* Auto generated Run-Time-Environment Component Configuration File
* *** Do not modify ! ***
* Project: 'Project'
* Target: 'STM32F410Tx_Nucleo'
*/
#define CMSIS_device_header "stm32f4xx.h" // define own board header, eg stm32f4xx.h or stm32f7xx.h
#ifndef RTE_COMPONENTS_H
#define RTE_COMPONENTS_H
#endif /* RTE_COMPONENTS_H */
Make sure that the device name for the CMSIS_device_header corresponds to the header .h
file located in ../Drivers/CMSIS/Device/ST/DEVICE_NAME/Include/DEVICE_NAME.h
Add the required symbols (right-click your project, go to properties, C/C++ General, Paths and Symbols; then go to the #Symbols tab) to define the FPU and your Cortex Core type. For me I need to add __FPU_PRESENT (either with no value or value '1') and because I have the Cortex M4 chip on the STM32F411RE I add ARM_MATH_CM4. This means that my list of Symbols looks like:
__FPU_PRESENT
__packed with value __attribute__((__packed__))
__weak with value __attribute__((weak))
-ARM_MATH_CM4
STM32F411xE
USE_HAL_DRIVER though this depends if you want to use the HAL or not
Again make sure that the necessary includes are well defined, as not including only 1 directory can lead to a large amount of errors. These can be found by going to project properties (right-click your project, option at the bottom), going to the C/C++ Build, Settings, then the Tool Settings tab, C Compiler dropdown and to the Directories option.
For my project I have the following include path's inside the project properties:
../Inc (should be by default)
../Drivers/CMSIS/Device/ST/STM32F4xx/Include (should be by default)
../Drivers/STM32F4xx_HAL_Driver/Inc (should be by default)
../Drivers/STM32F4xx_HAL_Driver/Inc/Legacy (should be by default)
../Drivers/CMSIS/Include (should be by default)
"${workspace_loc:/${ProjName}/Drivers/Device/ST/STM32F4xx/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/Core/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/Core_A/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/DSP/Include}"
Hopefully this helps and works for you too!
I've got a tool that generates files that contain definitions and declarations. These files need to be included from other source files or headers - they aren't usable standalone.
The obvious thing to do is have a custom command to generate them. My CMakeLists.txt that does this is as follows. I'm currently using this with the GNU makefile generator.
project(test_didl)
cmake_minimum_required(VERSION 3.0)
add_custom_command(
OUTPUT test_didl_structs.h test_didl_structs.c
COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/didl.py --decls=test_didl_structs.h --defs=test_didl_structs.c ${CMAKE_CURRENT_SOURCE_DIR}/test_didl_structs.py
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/didl.py ${CMAKE_CURRENT_SOURCE_DIR}/test_didl_structs.py
MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/test_didl_structs.py)
add_executable(test_didl test_didl.c)
target_include_directories(test_didl PRIVATE ${CMAKE_CURRENT_BINARY_DIR})
target_link_libraries(test_didl shared_lib)
test_didl.c is very simple:
#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include "test_didl_structs.h"
#include "test_didl_structs.c"
int main(void) {
}
But on the first build, make tries to build test_didl.c, which of course fails, because test_didl_structs.* haven't been generated yet. Naturally, before the first successful build of test_didl.c, the dependency information isn't known, so make doesn't know to run the python command first.
I tried a custom target, but that's no good, because custom targets are assumed to be always dirty. This means the C file is recompiled on every build and the EXE is linked. This approach won't scale.
My eventual solution was to make the output .h file an input to the executable:
add_executable(test_didl test_didl.c test_didl_structs.h)
.h file inputs are treated as dependencies, but don't otherwise do anything interesting for makefile generators. (I am not currently interested in other generators.)
So that works, but it feels a bit ugly. It doesn't actually state explicitly that the custom commands need to be run first, though in practice this seems to happen. I'm not quite sure how, though (but I'm not up to speed on reading the CMake-generated Makefiles just yet).
Is this how it's supposed to work? Or is there something neater I'm supposed to be doing instead?
(What I'm imagining, I suppose, is something like a Visual Studio pre-build step, in that it's considered for running on every build, before the normal dependency checking. But I want this pre-build step to have dependency checking, so that it's skipped if its inputs are older than its outputs.)
My eventual solution was to make the output .h file an input to the executable.
This way is correct.
It actually states, that building executable depends on given file, and, if that file is OUTPUT for some add_custom_command(), this command will be executed before building executable.
Another way is to generate needed headers at configuration stage using execute_process(). In that case there is no need to add header files as sources for add_executable(): CMake has notion of autodetecting dependencies for compiling, so test_didl will be rebuilt after regeneration of test_didl_structs.h.
execute_process(COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/didl.py --decls=test_didl_structs.h --defs=test_didl_structs.c ${CMAKE_CURRENT_SOURCE_DIR}/test_didl_structs.py)
# ...
add_executable(test_didl test_didl.c)
Drawback of this approach is that you need manually rerun configuration stage after changing your .py files. See also that question and answer to it.
Another problem is that header file will be updated every time configuration is run.
You can try tell cmake that you are using an external source, see docs about set_source_files_properties, see this past post
I have some custom .h files placed under /usr/include, but in a directory (/usr/include/itsmag1c), and I'm trying to include them in my C file. I'm guessing that because I use
#include "filename.h";
for files in the same directory, and I would use angle brackets for including a file like math.h or stdio.h. Am I right in guessing that I would use the angle brackets for including my custom header files? If so, my program wont compile, I get the error that the included files cannot be found. Can someone please point to me how I would include these files, or would it be best to have them in the same directory as my program?
Two choices:
Use #include <itsmagic1c/filename.h>
Use #include <filename.h> as before but add a -I switch.
Boost etc use method 1. (which works well provided you have Boost installed in system locations as you would on a reasonably standard Linux box with reasonable package management).
Method 2. is fine too, but more work on the build system, Makefiles, etc.
Usually, you would put your own headers in the same directory or in a subdirectory. Same-dir includes work with "". For bracket includes, if you use gcc, you can pass additional include directories with
-Irelativedir
or
-I/usr/local/yourpath.
I am running Ubuntu 10.10 on an IBM R51 machine. When I access list.h to read it(manually/humanly) I open /usr/src/linux-headers-2.6.35-22/include/linux .
But when coding a C program in terminal, I cant invoke any #include because it is not in the default /usr/include folders.
When I change the statement to reflect the path by typing #include "/usr/src/linux-headers-2.6.35-22/include/linux/list.h" it returns errors as list.h in turn calls other header files which are mentioned as located in "linux" folder
The header files are as you must be aware:
"linux/poison.h", "linux/prefetch.h" and "asm/system.h"
So if I have to copy each, I can but prefetch in turn calls other dependencies, which are not present in /usr/include directory. I hope you understand.
How can I solve this problem?
Are you sure these headers are really what you need ? The standard C headers should be under /usr/include
Anyhow you need to pass the header search path to the compiler via the '-I' flag.
Pass the path via -I
-I/usr/src/linux-headers-2.6.35-22/include/linux
Then in your C code
#include "list.h"
Link to GCC manual & preprocessor directives
The header files you are using are designed for internal use of the Linux kernel. They were not designed to be used by a userland program.
If you MUST use these headers (the Linux kernel list implementation is brilliant), copy the headers into your program source directory. Copy each file that is referenced, edit each one to remove whatever assumptions exist about being used in-kernel, and recurse until you're finished. I might suggest to make your own prefetch() macro that simply does nothing, rather than try to untangle <linux/prefetch.h>. Do the same for <linux/poison.h>, and untangle <linux/types> and <linux/stddef.h> (not too hard here :) as best you can.
And also be sure you license your project GPLv2 (and specifically GPLv2, the Linux kernel's COPYING file is quite strict that GPLv2 is the only license that applies; there is debate whether the GPL allows specifying only one version, but that is the license Linus chose ages ago, and the license that is valid on all files unless specified otherwise).
adding -I/usr/src/linux is a no-go, since unsanitized header files are not meant to be used from user programs
you could manually copy list.h to your own project and sanitize
or use a library that is specifically for userspace and provides the same functionality (since you already used libHX elsewhere, you might want to continue reading into the linked list chapter)
How to install new units (i mean includes ex: stdio.h) for my C, and how to download more?
put the header file on the same folder as your main source file,
ex:
/folder /-->main.c
-->function.h
-->function.c
then on main.c include it by writing :
#include "function.h"
the quotes are used to include a header file that's on the same folder as your c source file
u can also write your own and include them like above.
You're looking for libraries. The headers (normally) just contain information to tell the compiler about the content of the library. There are quite a few C libraries to be found, covering all sorts of different topics. Of course, SourceForge isn't the only place to look -- Github and Google code would be a couple more obvious ones.