I am currently working on my project wherein I need to program a DSP processor for a modem to do binary FSK modulation. The system was earlier using a QPSK modulation. I have use the same infrastructure, only need to modify the frequency modulation technique. The DSP processor is simulated using a set of C files on a LINUX machine and all the code is tested out on LINUX before moving on to the actual device.
Right now I have just started with the programming and I am just trying to compile my current codeset. I am facing a lot of issues with missing header files.
The device infra files use the header files like:
filter.h,
sysreg.h,
builtins.h
Now I am getting all these headers as "file missing" errors. I was able to fix a couple with
#include <sys/reg.h>
#include <linux/filter.h>
But the builtins.h file is still missing and I am not able to compile the code.
I am using UBUNTU 11.10 and gcc version 4.6.1. Is there some special set of files that I need to update for programming with embedded C. Any help would be much appreciated.
builtins.h is a header that is part of the compiler project and specifies which functions are, literally, built-in to the language, according to the gcc docs.
Your problem is that the compiler you're using cannot find this file.
You have two options:
The first, assuming everything else is set up correctly, is to run find /usr -name "builtins.h" to locate the file and add that directory to the include (-I/path/to/dir) path.
If the system uses some form of cross compiler, make sure you're using that, rather than your host's gcc. If you aren't using the correct toolchain, I suspect you'll have problems linking, too.
Related
When I compiled a device driver with APIs like sysfs_create_group or attributes declaration without including linux/sysfs.h, I found that the driver can still be compiled, and the driver worked fine with the device. Furthermore, I had searched other headers included in the driver, such as linux/module.h, linux/i2c.h, or linux/device.h, none of them includes linux/sysfs.h.
I assume the APIs are exported by the kernel, so the loaded driver is able to call the function. In that case, is it okay not to include linux/sysfs.h? or is it caused by other reasons?
I have just begun to learn C and device driver programming recently, so the question might be unclear.
The Linux kernel version I used is 5.15.
One of your include files will be including linux/sysfs.h, possibly indirectly, i.e. it includes a file, which includes a file, which includes sysfs.h. Possibly nested even deeper than that. You could compile your code with the -E option to gcc to see the pre-processed output. That should show you where the include came from.
Relying on other header files to #include files that are required to build your code is fragile and not recommended, especially if you don't even know which one it is. Maybe in the future you won't #include whichever one happened to bring in sysfs.h, and then your code won't compile. Or maybe a future version of that header file won't include sysfs.h.
If your code explicitly uses something provided by a header file, you should #include it yourself.
I am trying to compile C code on a Mac (M2), with as target windows. I have tried this in the past on linux, with success, but there doesn't seem to be a straightforward way on Mac.
On the linux machine I was able to get a whole range of cross compilers from GNU, they had the system headers built in, so it was really really simple, something like
gcc-...-mingw main.c -o main.exe
would create a simple windows executable. From there it was as simple as moving the main.exe file to a usb drive or cloud to and transfer it to a windows machine to run it. Really simple!
For Mac I have found some resources about Clang, but you need to provide the system headers yourself, which I have no idea how to do. And there is more setting up, which I don't want to get into if there is a solution as simple as the one I just showed.
My question: What is the way to compile a C program on a Mac with the target system being windows, or even Linux?
Thanks for the help!
Visual Stdio Code has support for various C compilers native for M2. It isn’t a full IDE, simply a code editor with extensions.
You should be able to download the plugins/extensions you need via the GUI interface and let it manage the environment.
There are many different answers circling around this topic, but I think my problem might be a bit more specific, as none work.
I am using Eclipse (v3.8.1) to build a C application for an embedded target. I use LTIB to build the target image, and I have been able to confirm that the GCC toolchain provided by LTIB (for a Freescale i.MX processor) is sound - I can successfully build and deploy a "Hello World" application to the target.
Now I'm trying to include some Linux headers for the target in Eclipse. So, I add a VAR to ${LTIB_LOC} = /home/user/ltib in Eclipse and add the include file directories everywhere seemingly imaginable (with help from other answers).
${LTIB_LOC}/rpm/BUILD/linux-2.6.31/include
And in the source code, I add the headers I need:
#include <linux/types.h>
#include <linux/imx_types.h>
Now, the problem is two-fold. Firstly, the common header types.h is being picked-up from the built-in host directories (/usr/include/linux), whereas I want to use the ones in the LTIB directories. Secondly, the custom i.MX header imx_types.h cannot be found by the Eclipse discovery scanners, so I have persistent semantic warnings/errors, even though the compiler can find the headers and the project builds.
How can I get rid of the built-in host directories so that I always use the target Linux headers, and how do I get rid of the incredibly annoying semantic errors?
You need to configure your built-in compiler settings provider to find the correct toolchain.
Go to Project Properties | C/C++ General | Providers. Select [Your Toolchain] Built-in Compiler Settings, and in the Command to get compiler specs, replace ${COMMAND} with the path to your cross-compiler.
This should get CDT to stop picking up the built-in includes of the system's default toolchain, and start picking up the built-in includes of your cross-compiler toolchain.
(Yes, replacing ${COMMAND} with an explicit path is hacky. The proper way to do this, at least in the minds of the developers who designed this system, is to have the cross-compiler's developers distribute an Eclipse plugin that defines its own [Cross Compiler Name] Built-in Compiler Settings provider, which knows where the compiler executable is (i.e. for which ${COMMAND} is the right thing to begin with), and use that instead of the default built-in settings provider. I assume you do not have such an Eclipse plugin handy.)
Since this is my first question after years of finding answers in this site, id like to say a big thanks to everyone.
I want to use FANN in an embedded platform, and i am using UVision 4 to code in C.
Since i am a C/C++ rookie, i cant figure out if i can / how i can use that library.
When i try to simply include the files, i get this error:
FANN\fann.h(51): error: #5: cannot open source input file "sys/time.h": No such file or directory
which makes sense because i am not compiling for windows platform.
Can i use the FANN library for embedded C? If so, how to include it?
Thanks
You have to write your own "sys/time.h" for your embedded system. It must offer everything the original one does to be compatible with your external library. Wether you write one from scratch or wrap something around an existing code base which is compatible to your embedded device is up to you.
You can also have a look at this SO question.
If you're not compiling on windows you'll have no problem - simply include sys/time.h like this :
#include <sys/time.h>
Note the < and > character, these will make sure that your header is looked up within $PATH.
If your compiler still wont find that header you will need to install libc, on debian this can be done with tools like apt-get
I've got all the source code for PARI, but i'm not sure how to use it/generate the pari library. Up to now, i've had to add a couple header files for things such as complex numbers using #include <complex.h>, so I figure it is the same idea for using PARI.
I add pari.h's path in my compiler and #include <pari.h> works, but creates a massive list of other errors including mostly "expected ')' before numeric constant" inside of paricfg.h.
I'm definitely doing it wrong. I know there's some semi-automated way to create a library file to import in using linux commands, but i'm using windows, and i'm not sure I can run the necessary files via cmd.
How can i utilize PARI?
Did you build the library before trying to use it? If you didn't, take a look at the INSTALL file or one of the README files.
To be able to build this type of library on Windows you'll need either MinGW or Cygwin. Although after a quick look at the README.WIN file, MinGW seems to be out of the question. You might also want to consider installing a Linux distro in a VM and using that to build and run your application.