I first explored the opportunity of using the Eclipse and Net Beans open source projects as a foundation for embedded software development tools in an article a few years back. Back then these Java-based IDEs (Integrated Development Environments) were squarely targeting application developers, but the embedded community was beginning to experiment with using these platforms for their own development tools. Since then, many companies have built and released Eclipse-based development tools – and a few have retained using their own IDE.
This week’s question is an attempt to start evaluating how theses open source development platforms are working out for embedded suppliers and developers. In a recent discussion with IAR Systems, I felt like the company’s recent announcement about an Eclipse plug-in for the Renesas RL78 was driven by developer request. IAR also supports its own proprietary IDE – the IAR Embedded WorkBench. Does a software development tools company supporting two different IDEs signal something about the open source platform?
In contrast, Microchip’s MPLAB X IDE is based on the Net Beans platform – effectively a competing open source platform to Eclipse. One capability that using the open source platform provides is that the IDE supports development on a variety of hosts running Linux, Mac OS, and Windows operating systems.
I personally have not tried using either an Eclipse or Net Beans tool in many years, so I do not know yet how well they have matured over the past few years. I do recall that managing installations was somewhat cumbersome, and I expect that is much better now. I also recall that the tools were a little slower to react to what I wanted to do, and again, today’s newer computers may have made that a non-issue. Lastly, the open source projects were not really built with the needs of embedded developers in mind, so the embedded tools that migrated to these platforms had to conform as best they could to architectural assumptions that were driven by the needs of application developers.
Do you care if an IDE is Eclipse or Net Beans based? Does the open source platform enable you to manage a wider variety of processor architectures from different suppliers in a meaningfully better way? Does it matter to your design-in decision if a processor is supported by one of these platforms? Are tools based on these open source platforms able to deliver the functionality and responsiveness you need for embedded development?
Processor Tracker
All Entries RSS Feed
I definitely DO care if it is Eclipse based.
And by that I mean I absolutely, positively DO NOT want it to be Eclipse-based.
There was a thread a couple months back on an embedded forum, and another one somewhere at LinkedIn, where Eclipse was discussed. I’d say the experiences & opinions were at least 2/3 against Eclipse-based IDEs.
Vendors love Eclipse because it’s free (what? we don’t have to develop our own IDE anymore?) and because Eclipse is cool/sexy/hip.
The problem is that Eclipse is a jack-of-all-trades, master of none. It is slow, clunky, unmanageable, unstable, inconsistent, sluggish, and the UI looks like a 1998 Java Swing UI (I guess Eclipse is written in Java, so that makes some sense).
>And by that I mean I absolutely, positively DO NOT want it to be Eclipse-based.
Same here.
TI CCS 4 for example is a real PITA. It has all eclipse/JAVA drawbacks and some advantages are lost (where is the standard .h/.c file switch ?)
Slow, memory hungry: after using it 1 hour -> 400 MB for editing a C source (you need to customize JAVA heap settings or it crashes) and 5 seconds delay to start the external make/compiler, Views not implemented or buggy…….
Eclipse is something that can be polarizing. You get people who love it and you get people who hate it. Code Composer Studio (CCS) from TI is based on Eclipse and we’ve had comments, mainly from those who dislike Eclipse, that it is big, slow and hard to use. With CCSv4 today we are using a very old version of Eclipse (3.2) that included many TI modifications (basically our own private branch). Future versions of CCS will be based on stock Eclipse, i.e. CCS will use the latest available Eclipse release which addresses a large number of reported issues. TI is also making additional changes in CCS to further improve the user experience. Any changes being made to Eclipse are done in the open source stream so that we are able to continue to keep pace with the latest Eclipse releases.
Eclipse definitely is a Jack-of-all-trades, it is used to create everything from modeling tools to business reporting tools. However at its heart it is a software development environment as that is where it originated. How an Eclipse based product looks to users is something that is really controlled by the individual software vendor. For TI our goal with the next CCS release is to make it small, fast and easy. While we do have to work within the Eclipse framework, we feel that the ability to achieve those objectives is under our control and are confident that users will enjoy the improved experience. Hopefully at the same time users will become fans of Eclipse.
I have a love-hate relationship with Eclipse, but I have finally given it the boot, never more to darken my computer.
I first looked at it when considering working with a startup whose dev tools were written as plugins for Eclipse; the clunkiness of the Eclipse environment spoilt the experience for me – the startup’s tools were great, but setting up the system and hunting for configuration settings in Eclipse were awful. It seems that you never really ‘know’ Eclipse – you just know the current set of plugins that you use, which means that looking online for information on how to use the system is a patchy experience at best.
Years later I tried again with the PHP plugin for Eclipse – loved it, very nice toolset with powerful search options (as long as you click in the right pane before hitting ctrl-f or ctrl-h) and the organisation pane was invaluable.
Then I did something dumb – I upgraded from Ubuntu 10.04 to 10.10, and it broke Eclipse. I looked online & the official position from the Eclipse team was “Ubuntu broke the install, we’re not going to fix it”. Fair enough, I can see their point. So I tried a complete uninstall and reinstall of the latest version. Fired it up, installed the PHP plugin and got exactly the same error messages. It seems that the project settings file format is incredibly fragile – lots of absolute locations hardwired in with no recovery or fallback to sane defaults if things change. I guess I could have purged all the breadcrumbs that Eclipse leaves around and got back to a working system, but I have better things to do with my time than nurse a cranky and frankly overweight text editor.
I’m currently using the free Komodo editor, and seriously considering paying for the IDE to get back the few features I miss from Eclipse.
Don’t know much about Net Beans but it seems to lack of support for embedded software development. Eclipse on the other hand has full support from ARM development community. Though, Eclipse project management is so badly designed and quite buggy as well.
Eclipse on Fedora Core 11 with target x86: buggy, terrible default code/file search for identifiers — ended up grepping on command line. On Fedora Core 14, fewer bugs. CVS integration, worked on FC11and FC14. Reasonable debugger for native x86. My sense is you really need to download, install, config and test drive to see if Eclipse is going to work for your development needs. Compile to x86 target for test harnesses if using in resource restricted embedded situations. I felt like Eclipse on FC14 was ready for some prime-time development situations.
even the limited eclipse ported to microblazes ide, often cause me to waste my time figuring out problems with settings
I use Eclipse for TI OMAP development and general code development under Ubuntu and Windows 7. The older version had a lot of bugs and you continually fought it. The latest is actually getting much better although not officially supported on Ubuntu. What I like about it is the ability to do development for a number of platforms using one generic tool. Configuration gets to be a pain but it is doable. Also a number of useful edit features don’t see to work all the time so you end up finding other solutions, like external diff tools, etc. Regardless, beats fighting the “yet another Development Tool” syndrome.
One thing I have learned about using Eclipse for embedded, as well as other types of development, over the years is that it is very important to have someone on hand whom knows sane defaults and is able to roll a version of the companies users. Assuming sane defaults power users are then able to customize to their hearts content with minimal effort. I mostly use eclipse because I can combine the power of many plug-ins to accomplish a task better than with any other IDE I have tried in the last 12 years. Also having developed plug-ins for Eclipse myself I have enough understanding to get a well configured default system that I can then update.
That being said there is nothing wrong with other IDE’s. NetBeans is very nice to use but I feel is still behind Eclipse in features I used for embedded development. There are lots of great tools out there that need to be evaluated based on your current needs. On the other hand if you are developing tools for the masses right now Eclipse has the largest single user base out there.
I come from an embedded target, C/C++, embedded Linux and RTOS world.
You will find some developers who love to work in an integrated IDE environment, and other developers who want the command line with direct invocation of make, compilers and the like. Those who like the integrated environment love the ability to quickly look up library calls, do source line debugging using remote control of targets over ethernet, USB, or ICE. Those who love the command line like not having to have a huge stack of software to maintain between them and the target, deal with the limitations of metaphors of development and target interaction process, or are working on early boot/driver/core features which wouldn’t really be helped by debuggers or source code and IDE based features anyway.
So, embedded OS or target demonstration hardware vendor has to cater to both audiences of developers. In this world of open source, by adopting a well-supported framework like Eclipse you may be able to avoid staffing a large team who are experts in GUI and developing the framework for you, answering service calls, or the like… you may be able to leverage off and adapt or extend existing plugins (like C Development Toolkit or GDB/ptrace-based debugging), and you can benefit from community involvement, feedback, community peership, influence the development of what’s considered the defacto standard, give talks to demonstrate industry leadership, and the like. The ability to leverage a large and reasonably well-supported tool can be valuable.
Although I’m not an embedded application developer these days, I can understand that if one has to develop with an IDE, it’s good to have a well-known/well-supported one, and stick to stable relatively supported development platforms with it.
I found Eclipse too fat and too unstable to replace raw tools, like git, binutils, make, ssh and your favorite console based editor. Eclipse just add a new layer that hide the reality. It require new knowledge that don’t replace the knowledge you must have anyway in the raw tools in case anything go wrong.
I find that Eclipse is a tool that tries to be all things to all people and falls short in many respects. Bugs, half-baked ideas, Java performance, and more all conspire to make it a tools that only a Microsoft Visual Studio lover could tolerate. For me, the real big problem is the amount of screen real estate that it occupies. All of those tabs, menus, modes, views, etc. make it difficult to used Eclipse and still have screen space to edit code on anything less than 1600×1200. On my 2560×1600 screen, it’s not too bad. But, I can’t carry that around with me. And, with 8GBs of RAM and a quad-core (with SMT) processor, Eclipse performance is acceptable. But, why do I need that kind of engine just to run the editor and compiler?
Tools like Visual Slickedit on the commercial side, CodeBlocks, KDevelop and others on the OSS side all provide similar capabilities for cross-compilation/cross-debug and don’t seem to require near the resources if I really need an IDE. But, most of my work is done with VI, gdb, make, SourceNavigator/cscope and git which all me to dictate the interaction style (GUI or command line) and don’t need a behemoth machine to run. My Eclipse-centric colleagues will call me a dinosaur to be sure. But, I’m usually finished with my rebuilds of the kernel way before they are.
M., you are not a dinosaur ! The real fact is that the guys that make the code of a compiler expect to process some inputs files to produce a output file. There is no need of anything more than a command line to use a compiler. You are faster because you use directly the required tools to do your job.
Maybe someday someone will produce a superb GUI that don’t make the mistake to hide as many things as possible, but permit to show as many details as possible on how the compiler internals works. With a such tool, I would certainly produce better code more quickly. Because you need to understand how the compiler make some choice to deeply optimize your code.
Finally, using just command lines make you able to work from any machines that have a simple SSH client. This is very useful to provides remote support.
I’ve only used Eclipse for developing Android apps and Python code with the Pydev plug-in. So far so good… it integrates greate and works like a charm. So far, I love Eclipse.
I’ve not used Eclipse seriously for my embedded/driver development. Off late, I’ve been doing some application development in C++, SOAP etc which these tools give good visualization of methods, web services etc. Once we get the skeleton, command line is usually the best and fastest. I think Eclipse is best suited for application development, not for embedded space, as an embedded developer, one would always want to see what commands are invoked. Eclipse is more like a wrapper to command line commands.
Ideally, any developer should work with tools he is most proficient, efficient with. I don’t know much about Netbeans but Eclipse is best supported by multiple embedded vendors, has wide ranging plugins, and by far has better community support. And totally agree with Morgan about having a competent person for default rollout settings, backup and support.
No one will agree with the fact that for debugging firmware, a good GUI based debugger is very useful.
But do we need a full blown (and mostly mediocre) IDE to develop and debug embedded system code?
This would be nice (but not so useful)…
Most IDE, including Eclipse are clumsy to use, hide the building components.
So for the moment, I do prefer to use :
* An editor of my choice with good tags support. (I use mostly vim).
* Makefiles (cmake may be quite good too!).
Makefiles are highly flexible with very lean encapsulation of building components.
The syntax is a bit weird, but it is not so important: functionality is superb.!
* The best possible debugger with JTAG debug support.
* For remote debugging, so far a terminal does the job
* DDD is an ok (not great) gdb GUI frontend , it is still buggy!
Hopefully someone will redesign DDD as a gtk+ or qt application as a better gdb GUI frontend. This is much needed.
* For the JTAG, I have use many, and only a few seem to be good quality (I will refrain here to give names), most are buggy, slow and unreliable.
So far, the best are not cheap.
J.
I used to work with the ARM tool developers a lot; whenever they needed to debug a code generation issue, they always preferred to receive a makefile than an ide project file, because it was easier to determine the command line arguments passed to each tool.
That’s actually a good reason not to use an IDE for released code – the output of the tools is entirely dependent on a set of configuration switches buried in the gui; are you sure you didn’t leave a debug switch enabled by mistake? One IDE (I won’t name it, I hope they have fixed this) even had multiple interdependent sliders for setting optimization parameters – move one of seven sliders and three or four others would move up or down. It was like a scene from sickbay in Star Trek.
P., I agree with the need to be able to access the build system from the command line. That is one reason I prefer eclipse to most other GUI’s. The default makefile project is completely runnable from the command line. Even better it integrates well with projects that aren’t managed at all from eclipse’s build system. For example I have been using waf with a number of projects lately and they work just fine with eclipse even though it doesn’t understand anything about waf.
The biggest problem I see in using eclipse as an IDE is that I couldn’t determine a way to check in the project files to source control such that they could be shared with other developers and represent a fixed point in the development.
Of course, it might have just been me that was the idiot, but I couldn’t believe that the normally sane open source community would come up with a tool that stored fully qualified paths in the project files…
One of the important decisions when starting an embedded project is to choose proper tools for the job. I’ve been using Eclipse for 5 years in embedded development, mostly with success, but I’ve had my share of frustration.
Good things about Eclipse:
* portable on all the host OSs I’ve used (Windows, Linux, MacOS)
* Integrates well with GNU tools (gcc, gdb). There is a plugin to make the embedded debugging with gdb even easier: http://opensource.zylin.com/embeddedcdt.html (disclaimer: I used to work for Zylin full time).
* Supports syntax highlighting for a variety of languages like C/C++, Makefile, but also TCL (for testing tools and scripts, for example)
* Symbol indexing works OK, so navigating bigger projects is easy.
* Source control integration: CVS, SVN, even a nice try to integrate Git.
* The Eclipse project is actively developed
The bad things:
* It eats memory like there’s nothing else running on the universe.
* It can be slow at times
* Indexing gets lost now and then
* Refreshing the file system, if the file was modified outside Eclipse
* Debugging with GDB command line is a bit tricky.
Thank you E. for your detailed response. This is the response I would have liked to give had I more time when I made the first post.
Not exactly, I feel that Eclipse is useful while developing Application like Web technologies, where we can develop the GUI based code development. But during Embedded development, where there is no GUI basis development.
Here, we can use IDEs like Code composer studio Or IAR embedded workbench.
As far as eclipse concerned Embedded development, I doubt we can do the ON-BOARD debugging…
Regards
M.V.S.
On the first embedded project I worked on the ICE machine available only ran at about 1/2 the clock speed our system normally ran so getting real-time information on what was going on was difficult. The only way I was able to do it was to hook a logic analyzer up to a port that was dedicated to debug information output and add as little as possible code to the software to tell me what was going on while it was running. I then wrote a program that would translate the output bytes into meaningful data that myself or the other engineers working on the project could understand. We also attached what we called a Christmas tree, which was nothing more than a bunch of driven LEDs to the various external chips so that we could read their current state. Even when we got a better ICE machine the Christmas tree let us know when noise or voltage levels were causing things to change when they shouldn’t.
I use Eclipse some and just finished a project working with MPLAB IDE v8.
Maybe MPLAB X is and improvement, but v8 was basically not usable. It was a way to run the compiler and debugger, but editing code was a complete waste of time. I also have a dual montitor setup. Putting the IDE in the second, larger monitor made it crash. Why? I have no idea.
The idea of Eclipse and plug ins is a good one. Still there are three separate installs on my machine. Each vendor’s version is incompatible. An expert may be able to get all the plug-ins working together happily. I just don’t have the time to become an Eclipse expert too.
We lost a FORTUNE trying to hobble together the Eclipse environment for embedded development and debugging for a Stellaris target. The GNU tools worked fine for cross-compiling. The big disaster was in trying to piece together the debug toolchain. We first tried to use a simple JTAG dongle with OpenOCD. We could never find a combination of versions of gdb, OpenOCD, and the FTDI drivers that would work together. OpenOCD and to some extent even the GDB command set changed RADICALLY over simple minor revisions. I managed to tweak it into shape once, and then someone rev’d something and I could never get it to work again.
We also tried with a premium J-Link JTAG dongle and the J-Link GDB server, and still couldn’t get it to work with the nightmare of drivers and initialization strings, even with Segger’s help. Again, after 10′s of hours of banging my head against the wall, I got it to download on one system, but we could never reproduce it on another system and could never get the debug stepping to work properly.
We installed the IAR workbench and with one Email exchange with IAR for setup details, it worked instantly.
Don’t give me the “community support” line of crap. I’m not a hobbyist. I have to get work done. For embedded development, proven, complete toolchains and direct support are the rule if your project is at all mission critical.
That being said, if you don’t have any debugging needs, open-source tools should work pretty well for cross-compiling and then all you have to deal with is the JAVA idiocy of Eclipse — buggy, slow, arcane, distracting.
@J. A year ago I struggled with OpenOCD myself. The environment included Linux development systems using Eclipse + GNU Tools targeting Atmel Sam7 devices. I spent over two weeks on it only to finally determine that it just didn’t work. And by didn’t work, I mean that when I programmed the devices with the Atmel tool, I got one binary image in the device. When I programmed the devices with OpenOCD/GDB tools, I got a different image, never the same one twice in a row. We scrapped OpenOCD and purchased a Lauterbach debugger and haven’t had a problem since. Which in all honesty isn’t an Eclipse problem, it was an OpenOCD problem or the small JTAG debugger we were trying to use with OpenOCD.
That being said, I personally don’t care for Eclipse. I can use it, I just don’t like it. My biggest complaint is its response to user input speed. When I click something, I want it to respond immediately, especially if I’m editing text. If it intermittently pauses for short times when opening files, redrawing text to the screen, etc., it disrupts my concentration and becomes a hindrance not a help.
J., after much struggling I actually did get a Stellaris toolchain up and running with Eclipse, OpenOCD and and the BD-ICDI JTAG adapter board, using Windows XP as the dev machine OS. It took a lot of reading and playing around with things, and there are still a few quirks, but I’ve actually just about finished putting together a tutorial on the process if you are interested. Once you’ve done it once, you can replicate it on another machine in less than an hour. I definitely agree that commercial tools would have been worth the cost if I could skip the toolchain setup time, although we had a requirement to use a GCC based toolchain.
Maybe I didn’t look far enough under the hood, but the demos of the commercial versions of the GCC based toolchains for Stellaris seemed to just be packaged versions of standard eclipse with a bit nicer installer, and yet the cost was just as high as the IAR and Keil versions. I think that if companies are building their commercial product on an open source solution, they either need to do a really good job of selling the differentiating features, or else price their solution at a point where the time saved compared to DIY is worth the license price, especially considering a company may need several licenses. Solutions built on extending open-source tools aren’t so much competing with other commercial solutions as they are competing with DIY.
I’ve used Eclipse for 2 years. I only use as a text editor because automotive suppliers has no support for Eclipse based tools, only for its own tools (Freescale/Code Warrior, Renesas/HEW and so on). Freescale started its first Eclipse based tool for 8 bits line. KPIT GNU has one Eclipse toochain for some families from Renesas, but Renesas doesn’t support this community. So, I use Eclipse IDE and specific tool of microcontroller supplieer. I also use it for debugging of code in off board mode as assertion messages (I use MinGW). For me Eclipse is the “new way” to write code. Eclipse and plugins solve a lot of common problems of text edition. This is important, because programmers have to be focused on programming problems not with text ediditon problems. We don’t have to spend time searching a function in a library file or paste a lot of lines of incremented variables name (it’s so easy with emacs plugin!). Yes, there is others tools tha do this, but I prefer Eclipse.
Ufortunately, the plugin feature of Eclipse is not full used by companies yet. For example, You have to have 2 Eclipse installed in your PC if you use Freescale 8 bits and Renesas H8. Well, the Eclipse idea is only one Eclipse and a lot of others plugins. Manufactures don’t understand this yet.
Eclipse has made my work easier and faster!
As a software modeling tool editor we investigated the opportunity to port our environment on Eclipse. We thought we could connect to all other plug-ins very easily but we found out that was not the case because guess what: there are no defined and stable APIs within the eclipse plug-ins !
It is also important to remember that Eclipse was initiated by IBM to fight Microsoft Visual Studio. A lot of things are open source in that environment and commercial plug-ins are not always welcome.
Last but not least the only way to be a plug-in is to be written with the Eclipse Java framework. So if you already have an existing technology, every thing should be re-written in that framework.
In the end I think tool vendors should try to avoid Eclipse as much as possible.
“…I couldn’t believe that the normally sane open source community would come up with a tool that stored fully qualified paths in the project files.”
I’m with R. on this one. Eclipse has giant, crufty project files. Do you have an Eclipse project with settings that are working well for you? Do you want to duplicate them in another project? Good luck with that. It *is* possible, but it’s way harder that it ought to be.
I used to have CodeWright as my editor/IDE. (CodeWright is dead! Long live CodeWright! Anyway…) CodeWright had a project file that was text-based, really comprehensible, and that used filenames that were relative to any base directory you wanted. I could copy and hack that project file easily to make derivative projects, install different plugins, etc.
Eclipse? Meh.
I’ve only tinkered with Eclipse, mostly because I can’t comprehend how everything is organized and where I need to go to set up stuff. It just seems to different and non-intuitive to me. The worst thing a tool can do is get in the way of productivity and that seems to be what Eclipse is good at… I’m sticking with vi and makefiles as long as I can.
I buid my software on the command line window in a makefile based environment.
I started using eclipse when Borland killed CodeWright, some 5 or 6 years ago. Since then I have been evaluating a series of IDE’s and none has showed to be better than eclipse.
I use Eclipse on a daily basis and have so for at least 6 years to do 100% embedded development. So many posts here start off with “I don’t really use Eclipse” or “I used it once years ago”. Maybe you should give it another chance? Or maybe you only spent a few hours with it. I have been a Vi, Emacs, etc. user for many many years too and am SO HAPPY not to have to deal with those editors anymore. You complain about setup and sane defaults and sharing projects with developers, all issues I have no problem with in Eclipse and have had all of those problems with Emacs setups over the years for example. Getting tags to work was always a problem. Just works in Eclipse and works in the background as I edit. Re: using the command line, of course I can use it when I want. Re: makefiles, you can still use makefiles in Eclipse without a problem. And then there is the plug-in world where I can get all kinds of useful add ons, Integrated source control saves huge amounts of time. I could go on but you get the picture. I never want to go back to the old days. I want my tools to integrate with Eclipse.