Rolling Your Own Eclipse for ARM

[Sal Ammoniac]

If you told me a few weeks ago I'd me making this post today, I'd have told you you're crazy.  I've tried Eclipse in the past and was disappointed by its sluggishness and its complexity.

All this changed a few weeks ago when I got a Freescale Kinetis K64 Freedom board and downloaded Kinetis Design Studio to try with it. KDS, of course, is based on Eclipse, and as I mentioned in another thread, I didn't hold out much hope for it and assumed that I'd try it for a few minutes and then switch back to my old standby Rowley CrossWorks. What really happened, however, changed my whole outlook on Eclipse. Not only is KDS fast and responsive, it's also very intuitive to use and I quickly became very fond of it. It showed me that crappy Eclipse implementations are the fault of the vendor, not Eclipse itself.

Since I had such a good experience with KDS, I decided to go all out and put together my own Eclipse/GNU ARM development environment from scratch. I expected it would be difficult to get working because, like most open source projects, it would be poorly documented and many of the steps would be abbreviated because the writer assumed knowledge a user wouldn't necessarily have.

I came across a blog that has a very explicit set of instructions for installing the GCC ARM cross compiler tools, Eclipse, GNU ARM Eclipse, the Segger J-Link server, and everything else needed to build and debug ARM code in Eclipse. The instructions are a little out of date, but I didn't have any problems using the latest versions of Eclipse (Mars) and GCC (5.2) rather than the ones mentioned in the instructions (Eclipse Kepler and GCC 4.7). There are instructions for setting up the tools to use Segger J-Link, P&E Multilink, or OpenOCD debugging tools (although why anyone would want to torture themselves with OpenOCD when the Segger J-Link EDU is only US$60 and the Multilink Universal is only US$199 is beyond me).

http://mcuoneclipse.com/2013/07/20/dyi-free-toolchain-for-kinetis-part-1-gnu-arm-build-tools/

Once Eclipse and the other tools are installed, there is full support for the various flavors of Cortex-M parts, with particular support for the various flavors of STM32 and Freescale Kinetis parts, but it wouldn't be difficult to extend it to support LPC, TI, or other ARM vendor's parts.

Some of the advantages of this DIY approach are:

• You get the latest versions of the tools without having to wait for the ARM vendors to catch up
• Everything is free, open source (with the exception of the Segger GDB server) and without code size restrictions of any kind
• It's not tied to any one ARM vendor's parts
• You learn a lot about how Eclipse and the GCC tools are integrated versus using a canned vendor package
• The satisfaction of doing it yourself

[AlfBaz]

I went through a similar process quite some time ago, then forgot how to set it all up. The second time was a lot easier and I jotted down the steps with the aim of producing documentation to post here.
One of the biggest problems I had was that nearly all the information assumed you where a Linux expert and was not aimed at windows users.

I started with downloading arm gcc, stlink and openocd. Learnt how they all worked and tied in together from the command line. I ended up creating a bunch of bat files and a pretty cool command line environment for editing, compiling and debugging stm32 processors. This helped immensely when integrating the whole lot with eclipse

There are still some obstacles in eclipse who's solutions are somewhat cumbersome but the immense aid eclipse gives in writing code is well worth the effort

[AlfBaz]

• You get the latest versions of the tools without having to wait for the ARM vendors to catch up

This was the main reason for doing it for me. None of the offerings at the time had support for new stm32f4 processors

[dannyf]

'None of the offerings at the time had support for new stm32f4 processors'

Unless you are talking about the distant past, m4 has been supported by GCC for quite some time now. All you need to for is to load up the start up and cmsis files, provided by st at the launch date, and hit compile.

I have, for example, compiled to chips introduced recently on keil 3.24, using this approach. All it requires is that the core is supported.

Coide how's so far to allow you to compile to a generic core. Coupled with the right start up and header files, you can pretty much develop for any chip as long as its core is supported.

[AlfBaz]

'None of the offerings at the time had support for new stm32f4 processors'

Unless you are talking about the distant past, m4 has been supported by GCC for quite some time now. All you need to for is to load up the start up and cmsis files, provided by st at the launch date, and hit compile.

I wasn't talking about gcc, I was talking about pre-packaged IDE's with wizards, templates and the like

I have, for example...

That's the point of my posts. Setting up your own stuff gives you the insight to go forward without waiting for IDE/compiler vendors to update their stuff

[Sal Ammoniac]

One other advantage to DIY that I forgot to mention...

Most of the vendor tools use convoluted wizards to create new projects that then pull in all sorts of vendor libraries. I don't want all that crap--all I want is a bare bones project with a simple startup file that copies .data to SRAM, zeros the .bss, and then jumps to main. I write all my own peripheral libraries, and it's often a royal pain to figure out how to exclude the vendor crap from a project.

[Sal Ammoniac]

Another advantage: some vendor's only provide a 32-bit IDE, but you can build your own 64-bit Eclipse development environment. I find 64-bit Eclipse is noticeably faster on a 64-bit machine with lots of RAM.

[Boomerang]

Is there any problem to do the same with NetBeans?

[AlfBaz]

Is there any problem to do the same with NetBeans?

I don't see why not. While eclipse has a version specific to C/C++ (CDT), it appears there's a 32/64bit C/C++ version of netbeans.

I'm kind of curious how it compares to eclipse 

[BloodyCactus]

Is there any problem to do the same with NetBeans?

I don't see why not. While eclipse has a version specific to C/C++ (CDT), it appears there's a 32/64bit C/C++ version of netbeans.

I'm kind of curious how it compares to eclipse 

you can write c/c++ in loads of ide's but its more about integration of the segger jlink etc than just c/c++ in netbeans.

i think it was possible to connect netbeans to the segger jlink gdb server. never tested that myself.

[AlfBaz]

you can write c/c++ in loads of ide's but its more about integration of the segger jlink etc than just c/c++ in netbeans.

i think it was possible to connect netbeans to the segger jlink gdb server. never tested that myself.

Ahh, ok. I always use openocd. It's the middle man between what ever programmer/hardware debugger you are using and gdb. So long as the IDE can handle gdb you should, in theory, be right

[Pack34]

CooCox CoIDE is a decent Eclipse based ARM development environment and works quite well with a wide range of STM32F4 microcontrollers.

http://coocox.org/software.html

[Sal Ammoniac]

CooCox CoIDE is a decent Eclipse based ARM development environment and works quite well with a wide range of STM32F4 microcontrollers.

http://coocox.org/software.html

I haven't tried CooCox, and probably won't now that I have my own custom Eclipse IDE from just the basic components.

Based on what I learned this week by doing it myself, I utterly fail to understand how companies like Atollic can put out such poorly performing dogs of an IDE when it isn't hard at all to tune Eclipse for good performance.

[dannyf]

"Based on what I learned this week by doing it myself, I utterly fail to understand how companies like Atollic can put out such poorly performing dogs of an IDE when it isn't hard at all to tune Eclipse for good performance."

Because some people are willing to pay.

My favite free ides are coide for arm, emblocks for pic24, and code block for avr.