Beats me. The newer versions of Eclipse allow to set a path and prefix for a cross compiler. Things couldn't be easier. IMHO the main problem is that many people don't know how the compilation process is organised. In my experience no school ever pays attention to that.
This is one of the biggest problems, in my opinion, that stems from advising people to start with HLL's. If you start at the start, doing asm, single file with absolute code, then tackle relocatable asm (coming to grips with the linker) and then move onto C/C++ you can gain an invaluable insight into how the whole compilation works.
The second biggest problem is that these "free" tools are very, very confusing as they are designed for, and on, Linux. So if you trying to get this stuff going on windows there is an order or two magnitude of complexity added to setting up.
Add to that the eclipse version nomenclature and you are left wondering what to down load to start with. It took me nearly a day to realise that eclipse names such as helios, juno, kelper are all just version 1, 2, 3 of eclipse. And then you have a choice of which pre packaged version of the aforementioned eclipse to get. CDT is mentioned every where as the "must use" plugin, but when you look through the available plugins to d/l from Help->Install New Software... it's nowhere to be seen as cdt is an acronym for C/C++ Development tools.
Then there's the problem of deciding on which gcc to use. Seems like every company and that ever existed has created a trunk off the main branch
With GCC (which actually is just the compiler) comes a package called binutils (which contains the linker, assembler and some other utilities to make hex files for example) and GDB the GNU debugger. The people who have created the compiler package give it an option which library is to be used with it (for microcontroller work this isually is newlib). From there the compiler and linker know where to find the include files and libraries relative to where the compiler is installed. So when compiling and linking a piece of code gcc and ld automagically know where to look.
I actually found this the most annoying when it came to the IDE and the CDT plugin. GCC is actually the command line front end to the whole set of subtools which means you can create the final elf output with one call to gcc
Where as the cdt settings explicitly ask for gcc, linker and assembler options and the auto generated make file then calls gcc, as, and ld separately. The problem with this setup is given the chosen architecture gcc passes, quietly, which set of libs to use to the linker (multilibs). If you call each subtool separately as cdt defaults to then you will have to set up a all the includes to the appropriate library manually!
For a microcontroller you'll also need a linker descriptor file telling the linker how the memory is organised. Usually an IDE hides these as well or even the compiler makers can hide these for you (see MSPGCC -gcc for msp430- for example).
This is indeed a very difficult section to get your head around, further compounded by matching it with a decent startup.asm file
All this 'making things easy' obfustigates the processes involved. Its not difficult to setup if you are aware of what happens under the hood. Using bare Eclipse CDT isn't difficult. Download/install a pre-compiled GCC package for ARM, tell Eclipse which compiler to use, set the code generation options for the compiler (arm7tdmi, cortex, etc) and the proper paths to the includes and libraries. Depending on your programmer you may need objdump to create a hex file from the ELF binary format.
With all of this fresh in my mind I wonder if I should create a series of explanatory videos that outline the process so that "free tool chain" users don't have to rely on a third party to support what ever MCU they like
Home
Help
Search
Login
Register
