Bare and Custom Eclipse IDE's for ARM's - Page 1
Forum section: electronics / general

author: AlfBaz
author_rank: Super Contributor
timestamp: December 14, 2013, 11:47:24 am
content: I've been hard at it this past month learning gcc, gdb and all of its utilities from the command line to program stm32f4's.Once I was comfortable with these I decided to get productive and install eclipse. Coming to grips with that beast and all of it's nuances, then porting example code from the vendor (who for some reason only provides projects for expensive proprietary tool chains) where you have to #include "the moon, the sun and the stars" and I'm finally making some head way.The processes are that convoluted that if I were to go on holidays for a week I'll have forgotten the lot!Finally got to look at the data sheets for these mcu's and decided to try using one of the on board (DiscoF4) sdram chips. Started reading the Flexible Memory Controller (FMC) thinking this would be the candidate to map the sdram into the MCU's 4G linear space.... Dear lord haven't I been through enough!!!.In desperation I searched through the peripheral examples, found a bit of code in main() that looked like could work in my current "Get This Tool Chain Working" project pasted it in, modded it ever so slightly, hit compile... No Errors WTF!!Downloaded it into the MCU, stepped through the code and it bloody worked!!After a month of being a miserable sod, I finally have a big stupid grin on my mug

author: dannyf
author_rank: Super Contributor
timestamp: December 14, 2013, 01:05:54 pm
content: QuoteAlternatively, you could breeze through all that with CoIDE (=eclipse customized).

author: AlfBaz
author_rank: Super Contributor
timestamp: December 14, 2013, 03:02:47 pm
content: Quote from: dannyf on December 14, 2013, 01:05:54 pmI have this affliction where I need to learn things from the bottom upI have my head around most of bare eclipse's short comings. There are a few more things I'd like to investigate before moving on to customised versions. I'm keen to get onto Chibi.From a quick glance at Giovanni's forum, Chibios and subsequently ChibiStudio have a following of some smart people who are quick to adopt new technologies. For example they were/are the only ones to contribute xml files to the eclipse plugin, embsys's SFR viewer.I tried both ChibiStudio and CoIDE prior to my foray into bare eclipse, but none of it made a great deal of sense at the time. I'll be better equipped to assess them, second time around

author: andyturk
author_rank: Frequent Contributor
timestamp: December 15, 2013, 05:39:51 am
content: ChibiOS is way cool.

author: mrflibble
author_rank: Super Contributor
timestamp: December 16, 2013, 02:44:21 am
content: Quote from: AlfBaz on December 14, 2013, 03:02:47 pmThis sounds awfully familiar.QuoteI haven't tried ChibiStudio yet ... one of those things on the todo list. However ChibiOS is way cool, just like andyturk said. XD

author: AlfBaz
author_rank: Super Contributor
timestamp: December 16, 2013, 09:21:46 am
content: I've been getting by with state machines due to the "singular" purpose of most of my applications but with the demand for more and more features with complex software api's it's high time I looked at rtos's. The guy that wrote avix tried to get me interested in his rtos around the time he first developed it for the pic's but I just could find the inspiration to carry it through.I'm really curios to try some of these customised eclipse offerings, to see what it is that's been customised and what if any limitations are imposed because of these changes. For example do we have to wait for them to provide obscure config or jar files to target a new processors?.

author: poorchava
author_rank: Super Contributor
timestamp: December 16, 2013, 12:49:57 pm
content: CoIDE will be a great alternative to stuff like Keil and IAR when they expand the list of supported devices (for example list of supported NXP and Atmel devices is rather short)

author: AlfBaz
author_rank: Super Contributor
timestamp: December 16, 2013, 02:35:25 pm
content: What exactly prevents these custom Eclipse IDE's from enabling the end use to utilise "unsupported" MCU's?I thought simply downloading the vendors support files, libs, cmsis files etc should be enough, after all isn't it the compiler doing all the work, or is it that people using these ide's are insulated from the compiler's complexities and it is this, that prevents development on unsupported chips.EDIT: Changed thread title

author: nctnico
author_rank: Super Contributor
timestamp: December 16, 2013, 09:22:58 pm
content: 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.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.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).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.

author: AlfBaz
author_rank: Super Contributor
timestamp: December 16, 2013, 11:22:53 pm
content: Quote from: nctnico on December 16, 2013, 09:22:58 pmThis 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 branchQuoteI 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 gccWhere 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!QuoteThis is indeed a very difficult section to get your head around, further compounded by matching it with a decent startup.asm fileQuoteWith 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

author: baoshi
author_rank: Regular Contributor
timestamp: December 17, 2013, 06:30:28 am
content: Hi AlfBaz,I recently migrated from Makefile to eclipse platform for my ARM (stm32) development. I tried CoIDE, bare eclipse with GNU ARM plugin, and the trail version of TrueStudio. I would say they're all great tools but I just cannot live with the project management portion. The settings are scattered around and the project files generated are not compatible between one-another. It seems many people have the same feeling.So in the end I settled with Makefile + eclipse approach, where eclipse is only used as an editor and gdb frontend. The current eclipse is able to perform "Discovery" and instrument into building process to find project dependencies, even if the project is managed externally by Makefile. This makes the editor much more intelligent.I have the full setup documentation and project template here:http://www.ba0sh1.com/opensource-stm32-development/Baoshi