I find KDevelop a very good IDE overall and I already have a good experience using it for cross-compiling and debugging software for ARM9 CPUs running embedded Linux. Now that I got some Arduino boards for smaller projects, I found them a very nice and easy platform, but its IDE is far behind Kdevelop in functionality, code introspection and so on, so I'd like to adapt Kdevelop to compile and program arduino boards instead.
The goal is to enable software development in pure C/C++ or regular C++ using arduino libraries as well (this answer helps a lot in making this possible), bypassing arduino's artificial limitations imposed to make it easy for begginers. I intend to use CMake as the build system, for it integrates well with Kdevelop and allows for easy cross-compilation. As a side note, you could use this toolchain file for making CMake use the avr-gcc cross-compiler:
INCLUDE(CMakeForceCompiler)
# the name of the target operating system
#SET(CMAKE_SYSTEM_NAME Linux)
# which C and C++ compiler to use
CMAKE_FORCE_C_COMPILER(avr-gcc GNU)
CMAKE_FORCE_CXX_COMPILER(avr-g++ GNU)
# here is the target environment located
SET(CMAKE_FIND_ROOT_PATH /usr/avr)
# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
Since arduino uses avr-gcc and avrdude behind the scenes to compile and program the target AVR microcontrollers, I found some interesting directions such as AVR Tutorial, Programming Arduino Uno in pure C and Program Arduino with AVR-GCC, but I still don't know how to add a button on Kdevelop's interface to call avrdude in order to upload the compiled binary to the microcontrollers' flash memory. Anyone can help me out doing that?
Related
I have an embedded project for ARM platform, specifically aarch64.
Up until now I was using Make. I recently set up CMake with no particular issues.
I moved to CMake because I was under the impression it was a more modern build tool that would have allowed a smarter configuration.
For example, I can compile my project using different toolchains (aarch64-elf-gcc-linaro, aarch64-linux-gnu-gcc,...) and I would like CMake to try if any of those are installed on the system and use whichever is found first by default.
Is this possible (or meant to)? I'd expect it to be an easy feat for the tool, but after searching for a while I can't seem to find the right track.
Yes, you can make your CMake project to search for available tool-chains installed in your OS, choose one and compile your project. I also write a CMake program for ARM embedded project, because now it is universal transferable between different OS system Windows and Unix. On Linux there is ARM ToolChain installed and on Windows there is Keil-MDK. If you have different tool-chains to choose between, you can write CMake script which will find paths with command like find_path() and then call correct "toolchianxx.cmake" script with right compiler flags for chosen compiler.
In your particular problem just use find_path commands and use hits to find installed compilers in "pre-set" known paths.
I realize this may be a really dumb question. Please humor me:
True or False: The only way to compile a program to run on a VxWorks platform is to purchase a development environment like Tornado or Workbench from WindRiver.
(I'm looking for an free/open-source solution to compile for a VxWorks platform.)
Outside of an academic license (which would use a VxWorks installation anyway), there is not any way to legally compile your code for a vxWorks platform.
Technically, you CAN obtain the GNU toolchain used to compile code for VxWorks.
The issue you will run into is that you won't have access to the header files necessary for compiling your code or the libraries to link against.
One can use a generic GNU cross-compiler to generate ELF files, and load them onto a running VxWorks system using the ld command. However, I don't recommend it for anything beyond proof-of-concept or initial experimentation -- the VxWorks libraries and Wind River's superb documentation of them are both necessary.
On the development host:
powerpc-elf-eabi-gcc -c foo.c
Then on the target-resident shell, that has mounted a filesystem from the development host (for example, over NFS):
-> ld < foo.o
-> main()
(Where the function main() comes from foo.c)
Since VxWorks is proprietary, they made it so you need their tools (Workbench/Tornado), which they supply, in order to develop for their OS.
OK, this might be a very general question but I'm not to familiar with the topic and happy for any hint.
I have a Cross Compiling tool chain from SoucereyCodeBench for ARM ( arm-xilinx-linux-gnueabi-). I cross compiled a library which uses the compiler Options: -DSC_INCLUDE_FX -DSC_USE_PTHREADS -pthreads -fPIC -DPIC
So if I want to use the libary for bare metal program I would need pthreads for the bare metal compiler (arm-xilinx-eabi-) I guess?
Otherwise my program probally wouldn't run or compile in the first place. So could it be done to compile pthreads for bare metal?
Threads and Bare Metal
Bare metal programming targets only provide what you put on them. The pthread implementation most folks are familiar with is the Linux NPTL version, which works because the Linux kernel and the GNU C library make it work. On bare metal targets, you don't get the benefit of either the Linux kernel or the GNU C library. You'll have to bring your own bare metal thread library and runtime but at that point you may be better off using an RTOS that provides threads.
A Note on Toolchain Prefixes
The gcc toolchain prefix, arm-xilinx-linux-gnueabi-, indicates the target as ARM Linux, not bare-metal. The arm-xilinx-linux-gnueabi- toolchain will build pthread aware code (-lpthread) but it will assume that the Linux target has the pthread library and other necessary software layers already installed.
If instead you switch to the bare-metal version of the gcc ARM xilinx toolchain, your toolchain prefix will be arm-xilinx-eabi-. Everything I said above about bare metal and threads will apply.
I think it will be a matetr of porting your code rather than simply cross-compiling it unchanged. As its name suggests POSIX threads (pthreads) assumes a POSIX API.
If you need threads on a bare metal ARM target, the you at least need some sort of thread scheduling libraries of which there are many. Most RTOSs are not full OSs in the sense of Linux, but rather simple schedulers with IPC mechanisms that link as static libraries like any other to your monolithic application - that probably still counts as "bare metal" in the sense that the system boots directly to your main() function where you are responsible for creating tasks/threads and starting the scheduler.
Some RTOSs support POSIX APIs and therefore pthreads, but these tend to be the larger more complete OSs rather than simple schedulers - either way they are generally smaller and more scalable then Linux so may meet yout "bare metal" requirements nonetheless.
Of course nothing stops you from creating a wrapper around any RTOS library to provide a pthread compatible API that might make porting your code simpler.
I am new to angstrom and linux. I am in the process of building an sdk with angstrom. But I cant understand what is a Toolchain and its functionality. Please someone help me here.
In software, a toolchain is the set of programming tools that are used to create a product (typically another computer program or system of programs). The tools may be used in a chain, so that the output of each tool becomes the input for the next, but the term is used widely to refer to any set of linked development tools.
A simple software development toolchain consists of a compiler and linker to transform the source code into an executable program, libraries to provide interfaces to the operating system, and a debugger.
http://en.wikipedia.org/wiki/Toolchain
I am a newbie to embedded developement, as figure shown. I have a small ARM board, AT91SAM7-EX256. I have also a JTAG programmer dongle, too. I am using Linux (Ubuntu x86_32) on my notebook and desktop machine. I'm using CodeSourcery Lite for cross-compiling to ARM-Linux.
Am I right that I can't use this Linux-target cross-compiler to make binary or hex files for the small ARM board (it comes without any operating system)? Should I use the version called ARM EABI instead?
As I see, it's a "generic" ARM compiler. I've read some docs, and there're lot of options to specify the processor type and instruction set (thumb, etc.), there will be no problem with it. But how can I tell the compiler, how should the image (bin/hex) looks like for the specific board (startup, code/data blocks etc.)? (In assemblers, there're the org and load directives for it.)
What software do I need to capture some debug messages from the board on my PC? I don't want to on-board debugging, I just need some detailed run-time signal, more than just blinking leds.
I have an option to use MS-Windows, I can get a dedicated machine for it. Do you recommend it, is it much easier?
Can I use inline assembly somehow in my C code? I dunno anything about that. Can I use C++ or just C?
I have also a question, which don't need to answer: are there really 4096 kind of GNU compilers and cross-compilers (from Linux_x86_32 -> Linux_x86_32, Linux_x86_32 -> Linux_ARM, OSX -> Linux_ARM, PPC_Linux -> OSX) and 16 different GNU compiler sources (as many target platforms/processors exists) around? The signs says "yes", but I can't believe it. Correct me, and show me the GNU compiler which can produce object file for any platform/processor, and the universal linker which can produce executable for any platform.
While Windows is not a "better" platform do this kind of embedded development on, it may be easier to start with since you can get a pre-built environment to work with. For example, Yagarto (which I would recommend).
Setting up an embedded development environment on Linux can require a considerable amount of knowledge, but it's not impossible.
To answer your questions:
Your Linux cross-compiler comes with libraries to build executables for a Linux environment. You have hinted that you want to build a bare-metal executable for this board. While you can do this with your compiler, it will just confuse things. I recommend building a baremetal cross-compiler. Since you're building your own baremetal executable (and thus you are the operating system, the ABI doesn't matter since you're generating all of the code and not interoperating with other previously built code.
There are several versions of the ARM instruction set (and Thumb). You need to generate code for your particular processor. If you generate the code for a newer version of the instruction set, you will likely generate code which generates a reserved instruction exception. Most prebuilt gcc cross-compiler toolchains for ARM are "multilib" and will build for a variety of architectures in both ARM and Thumb.
Not sure exactly what you're looking for here. This is a bare metal platform. You can use the debugger channel to send messages if you're debugging on target, or you'll need to build your own communication channel into the firmware you write (i.e. uart support).
See above.
Yes. See here for details on gcc's extended inline assembly syntax. You can do this in C++ and C. You can also simply link pure assembly files.
There is no universal gcc compiler / linker. You need a uniquely built compiler for each host / target combination you use.
Finally, please take a look at Atmel's documentation. They have a wealth of information on developing for this target as well as a board package with the needed linker directives and example programs. Note of course the package is for Atmel's own eval board, but it will get you started.
http://sam7stuff.blogspot.com/
I use either of the codesourcery lite versions. But I have no use for the gcc library nor a C library, I just need a compiler.
In the gcc 3 days newlib was great, modify two files worth of system support (simple open, close, read, putc type stuff) and you could compile just about anything, but with gcc 4.x you cannot even go back and cross compile gcc 3.x, you have to install an old linux distro in a virtual machine.
To get the gcc library yes you probably want to use the eabi version not the version with linux gnueabi in the file names.
You might also consider llvm (if you dont need a C library, and you will still need binutils), hmm, I wonder if newlib compiles with llvm.
I prefer to avoid getting trapped in sandboxes, learn the tools and how to manipulate the linker, etc to build your binaries.