Good IDE for micros

[yanir]

Can anyone make a recommendation for a solid IDE that can work with a variety of micros ( arm, pic, atmel).
Also looking for Decent debugger, and built driver libraries for generic devices. I currently use mplab for pic and i have altium designer which incorporates tasking. It has the features I describe but the debugger is crap and the libraries are buggy. Is there something better out there?

Yanir

[calin]

I really suggest Netbeans - http://netbeans.org/

I am using it to develop for x86/64 Linux, ARM, AVR and MSP430, you can even write Java in the same IDE if you want .  I am using it on Linux but Windows is same procedure. And you even have the possibility to do HW debugging if you use the Gdbserver plugin (allows you to attach to a remote target)

Here is what you will need:

1) Toolchains for the micros you use
2) Grab Netbeans for C/C++ and other plugins (GDBserver works a treat for any debugger with GDB support)
3) If you download the one without a JRE included you will need a JDK

I was a long user of Eclipse but lately I have to say .. Netbeans has taken the lead in many areas when compared with Eclipse.
It is just simple clean and does what you need to do; I think Eclipse is starting to suffer from bloat.

BTW, you can either use the Netbeans managed projects or do as I do .. write your own Makefiles. Netbeans works a threat with your Makefiles.

PS: I do not want to start a religios war in the style "Emacs vs vi" ... "Netbeans vs Eclipse" on this thread.

[mariush]

MPLAB X is based on the Netbeans platform ... it's basically netbeans ide with some plugins.

[T4P]

MPLAB X is based on the Netbeans platform ... it's basically netbeans ide with some plugins.

And a much slower interface ... MPLAB X is bullshit to me

[nctnico]

Eclipse. It beats all the IDEs I've come across hands down. But... because it can do so much it takes some learning time to get the most of it. The interesting thing about Eclipse is that you can use it for any language and platform. So if you are tired of electronics and move over to PHP you can still use Eclipse for writing code and debugging 

[firewalker]

There is also Code::blocks.

Alexander.

[Bored@Work]

The best on is the one you like best. To figure out which one you like best you have to try a few.

The problem, however are MCU manufacturers who love nothing more than throwing spanners in the works by tying their MCUs not only to one or a few "preferred" toolchains, tying tools and the toolchain into a particular IDE, and even if the IDE they selected is cross-platform, make sure everything only runs on a particular operating system - thinking they know best for you and/or thinking this is the best way for them and their "preferred" partners to generate the most business.

So in the end, if you have found the best IDE for you, there comes a fucking MCU manufacturer and screws you.

Just give me the tools for my preferred operating system, make them so they can be integrated in whatever IDE, editor, tools, development environment, I prefer, and I will happily spend an hour to do the integration on my own. I really wish fucking MCU vendors would stay out of my lawn and stop telling me what is best for me.

[nctnico]

I couldn't agree more. Once a sales rep. wanted me to try Coldfire MCUs so he sold me an evaluation board. Ofcourse I didn't want Freescale's Codewarrior so I tried to setup my Eclipse environment to compile for Coldfire (which basically is a 68000 based controller). That went well up to the point I wanted to program the MCU. It turned out the programming tool that came with the eval. board only worked with Codewarrior. The sales rep. couldn't answer how I was supposed to program the MCU otherwise withouth spending lots of cash. I pointed out all NXP's MCU could be programmed with a simple TTL level UART interface. I expect something just as simple from any alternative. End of the story: the eval board was send back and I still use NXP's MCUs.

The bottom line is: an IDE from an MCU manufacturer is an very tricky vendor lock-in tool for them. All seems nice until you want something special like tweaking the memory map, use overlays or integrate version control.

[yanir]

Thanks for the suggestions, what about stacks (USB, tcp/ip , rs232, etc). I usually do a combination of writing my own or using stacks that come along with example apps. Are there stacks available for eclipse and let's say nxp devices?

[Mechatrommer]

I really suggest Netbeans - http://netbeans.org/

hours of download frustration... java java java... i once taught "java developed software" can run on any machine, ok good!... now today, why a software (the netbean IDE) needs a java in order to live in WinXP machine? i thought its not the other way around, like other C/C++ ide i used to before. its politics sux spread like a pleague. who's rensponsible to say we need java in our everyday life! i dont! damn!

[calin]

Well .. Java is a simple virtual machine that abstracts the underlying OS and hardware and it does give you almost a write once run anywhere solution. If almost all cases a Java program will work on any platform on which the Java vm is running unless it is coded in such a way that it ties it to a certain OS - but that is not the language's fault .

Yes unfortunately or furtunately you need to install Java on XP as on any OS before you use it; actually you can even not install it if you don't want too - a simple zipped version will do (all JDK , Netbeans , Eclipse are available in a archived version - aka OS independent JAR). 

I recommended an IDE that I know it works and integrates really quick and easy with any toolchain , and in a generic way not by showing you the cake and then putting the glass lit in top of it .. see the other posts above. I used Eclipse for years @ work , now I switched to Nebeans just because I think is a tad cleaner - heck I use Netbeans configured with the Eclipse keyboard shortcuts , that's how used I am to Eclipse .

But like someone said above .. use what you like that is important - rest is "just wind"

[aluck]

I use AVRs, and WinAVR is pretty good.

Did someone manage to get JTAG ICE mkII to work under Netbeans or Eclipse?

Bonus: GCC lines in MS Visual Studio "output" window makes me smile each time.

[Mechatrommer]

Well .. Java is a simple virtual machine that abstracts the underlying OS and hardware and it does give you almost a write once run anywhere solution...

and then i suspect there will be alot of smiley "not so cool" buttons there with invisible "textual based" menus. another damned... you saying it can be used for most mcu bought me to that. and yet another "toolchains" i'm going to figure out. i need to regain enthusiasm to download the java6 first. thanks

Did someone manage to get JTAG ICE mkII to work under Netbeans or Eclipse?

this. exactly this. please explain calin :| i used WinAVR too, but that only for avr mcu.

[pkrobot]

Recently, I've seen a trend for the vendors to move to Eclipse. For example, TI used to use Code Composer Studio IDE. Then a couple of years ago, they moved to a modified Eclipse environment, but the environment was locked, so you couldn't use any other plugin. Now, they've released version 5 of CCS, which uses Eclipse Indigo, and is completely open. I've seen the same trend with FPGA vendors like Actel, Altera etc for their soft cores, and various other vendors selling ARM cores. It is slow, though, and may not be available for vendors like AVR.

For cases where Eclipse cannot be used, I learn the toolchain, and make my own build environment using SlickEdit. Reason: I'm familiar with SlickEdit, and have been using it for quite a few years. It is one of the best IDE I've seen, but has a steep learning curve. I'm not advising that you use SlickEdit. Chose any IDE of your liking, learn it, and then keep to it. Almost all vendors provide command-line build options, which you can use to call directly from a generic IDE. Also, the provide stand alone applications which you can use to upload your image to the target.

-pk

[calin]

Java, good bad not too many choices out there, or are they called .Net C# - and yep companies are moving to Eclipse or Netbeans because is not very cheap to maintain an IDE but it is much cheaper to throw in there few plugins and you are on - two examples are TI's CCS studio with Eclipse and Mplab X with Netbeans. Menus .. eh they can all have shortcuts ... but it does take a bit of time to get used to.. pain in the arse with many IDE's or editors I agree.  Yes these IDE's are slower than an native one but they have a ton of maintainers and backing companies for these projects. Eclipse seem to have taken off big time by quite a long period in the Java world, it is gaining a lot of market in the C world now; Netbeas comes or was derived from the old Forte for C made by SUN ... it has always lagged a bit behind eclipse but lately it started catching up. I hate to say it but Oracle is doing a good job with Netbeans. I wold not hide it .. I don't like Oracle period;  And Visual C ... is now a .Net application .. "mlutiplatform" because it runs on different windows versions ... heh

Unfortunately I do not have an mkII - if it supports GDB then it should work. Look for the Gdbserver plugin for Netbeans. That should work using a generic gdb remote target. Works a treat for me with JLink and MSP FET from TI, on linux 64, I debugging done using the STK 500 for  AVR's. Usually what I do is this .. I have a Make target defined that I call debug .. what that does it just "uploads the code using the standard flash tools and starts the debugger - for arm it starts the JLink GDB server and for MSP starts mspdebug). Now if you use netbeans it alows you to define what make target to be run before/when you debug .. so it runs the burn then connect using Gdbserver plugin and you can debug pretty nice. For ARM I use either Linaro either code sourcery as toolchains, mspgcc for C, avr-gcc for AVR. I can go in a lot of details how I have it set up etc. but it will not be a short.

WinAvr works a treat under netbeans .. it is a "GNU toolchain" just configure it like that and you are on. I use avr-gcc (becasue of Linux) and I also have the Arduion libs tied in the IDE (after all Arduino-ish .. is just C). Lo an behold I have code completion on all arduion libs in netbeans. So to answer yanir .. the software stack/libraries for the MCU should not be/are not a feature of the IDE. These are standard C libraries that you should be able to include and link against - remember these 3: Makefiles, "gcc -c -I./inlude/path" and "ld -L/link/pat -llib" .. oldie but goodie.

As for "multi mcu support" it does work decent enough for me with the ones I write code for.

An here is another thing, I truly really absolutely hate the IDE "writing" your Makefiles (old style UNIX kernel development habit I guess - I used to do that). An when I say "writing" I mean make a mockery of a Makefile using half of the environment variables defined on you development  machine and half from the IDE and the other half hardcoded in the build file and another half in a .conf file - how it manages to use 4 half's I still have to figure out (kidding) .


So YES I use an IDE but I keep it old school - I write my own makfiles and have the IDE just as a more sophisticated editor able to do code completion, build etc. I like having 100% control of the build, and that makes for another great thing, especially in a team you have your code building properly without an IDE and you can have automated builds/continuous integration etc. The reason I switched to Netbens is that Eclipse it keep sticking its nose in my business ... Netbeans is more civilized and knows to stay out if is say so - all I want is a good editor, shortcuts for my build targets, a nice debugger interface and to keep it's paws off my project and makefiles. I also find the C/C++ parser from Netbeans to be better than eclipse's when it comes to code parsing and code completion.. and finally a freakin editor that let me use "indent with spaces" in code and does not screw up the  TAB-s in the makefiles.

Like someone was saying on the thread .. give me a good toolchain and stop selling me your crappy "specialized" visual configuration tool tied to work only with your programming dongle ... I'll take care to set up an IDE as I want it for that.  The latest "visual" blasphemy I saw was GRACE from TI for MSP430 ... what a waste of electrons and bits !!!


BONUS:  Netbeans spills the guts of GCC out .. not one line missed !!

[pkrobot]

Except for the speed, I think starting with an IDE is not that bad an idea. In almost all the IDE's, you are provided with an option to start your own makefile project. I agree that your own makefile is going to be much more efficient, and build structure much better, but for a beginner, it is better to start with auto-makefile generation for a project. Later on, if you want, you can switch over to writing your own makefiles.

Another plus is the free plugins that you get. In Eclipse, with CDT (C Development Tooling), you even get static code analysis. That's an excellent tool for a beginner, when you don't have skills developed yet to write good code. Also, code browsing with Eclipse beats linux/unix search tools hands down. If you are still not happy, get SlickEdit or any other commercial tool plugin for Eclipse.

My advise would still be to start with Eclipse. If you outgrow, you can move to commercial generic code editors/browsing tools, and make your own build structure and makefiles. I personally don't use Netbeans, so can't comment on that. It might also be a good option.

-pk

[jucole]

I use "Editplus" you can create your own simple highlighter if you like.  but I hate all that clunky bloated IDE stuff unless I'm coding OOP PC software, in which case the "intellisense" feature in the full blown IDEs is a must!

[JuKu]

The catch here is the debugger. you don't always need it and if you have a serial port, printf's go a long way. But when you do need it, you need it badly. At that point, you want to use the manufacturer's tools, something that kind-of works. You might be able to use a generic debugger, but those are not going to give you the detailed view to the processor inside that you need. And when you have an issue, you want to be sure that the tool is working as it should.

And most (all?) of the vendors debuggers work from inside an IDE. The current IDEs are all at least useful, and some are even great. OF course, what is great is a matter of opinion. there are Eclipse based, Visual Studio based, Netbeans based... In my experience, none has all the features you want, all are usable and all are easy enough to learn.

In other words, I would say you are better off in using the manufacturers' standard tool, even if that means you need to (re-)learn a new tool in the start of every project. The basic ideas are the same anyway, you just have to remember if make is cntrl-B or F7 and so on.

[nctnico]

The catch here is the debugger. you don't always need it and if you have a serial port, printf's go a long way. But when you do need it, you need it badly. At that point, you want to use the manufacturer's tools, something that kind-of works. You might be able to use a generic debugger, but those are not going to give you the detailed view to the processor inside that you need. And when you have an issue, you want to be sure that the tool is working as it should.

Why would you need to debug the inside of the processor? You'd need that only if the compiler is flaky. Debugging a microcontroller is useless for two very good reasons:
1) The realtime parts can't be debugged because you'll disturb the realtime process too much. Outputting internal signals, a scope and printing statistics are much more usefull.
2) The non-realtime parts can be debugged / tested on a PC. Actually you can create an extensive test-bench around the non-realtime parts and test them better than you'll ever be able to do inside a microcontroller. Running large sets of test data extremely fast and saving the results to a file for analysis is a piece of cake on a PC.

All you really need on the embedded platform are some printfs to output state information.

[Mechatrommer]

ok! i installed both netbeans and eclipse, but unfortunately.. they have this almost similar looking interface. to the dumbest question... how do i setup the look so it can become similar like the AVR Studio 4? or my old M$ Visual Studio? at least i need to view multiple files at the same time side by side inside the IDE? and move them freely in the space? they do this peculiar things when i clicked the seemingly "unmaximized" button at top right, they do nasty unexpected things. windows gone and popped up random? am i too old? i hate eclipse rounded windows look and cool buttons, but at least i can resize the source files, otoh netbean got more comfortable "old looking" windows, but i have no success resizing it. is there any other IDE that has similar look as AVR Studio 4 but i can installed the "toolchain" for any other micro?

ps: duh! people prefer more aesthetic than functionality these days, even at something thats meant for the so called "programmer". i'm not a programmer!

[free_electron]

Why would you need to debug the inside of the processor? You'd need that only if the compiler is flaky. Debugging a microcontroller is useless for two very good reasons:

Really ? that's your take on it ? you've obviously not worked on realtime systems with serious debuggers ...

1) A serious debugger is non-invasive and will not perturb any realtime code. processors like ARM, i960 and other racehorses have special traceports and tracememory on board specifically for that purpose. Those ports run over a jtag link or a special traceport. Part of the debugger sits in the processor. this debugger shadows memory operations so you can have a live view of relevant data without halting or delaying cpu operations. The debuggers can also emit extra trigger signals. you can set a marker 'trigger 1 when this PC is reached, or when this subroutine is entered' this allows you to trigger a LA or scope to trap certain events. we have software algorithms to control accel/decel of the headstack. i have markers in the tracer that trigger the scope on every accel start. this guarantees me that i see every seek operation neatly aligned in time.
Same during a disk spinup. during spinup we go through several algorithms ( seek the rotor pole , controlled stepping until we sense enough back -emf , go for rampup until the window feedback is detected correctly and then apply the constant torque acceleration algorithm. ) i need to be able to see wen i am in what state of the sequence. the traceport tells me and i can filter when to trigger the scope to capture the motor waveform and look at commutation of the 3 phase bridge.
if the loop is unstable i can alter the coefficients using the traceport without having to go through an endless compile - flash - alter - compile -flash sequence.
The coefficients are stored in flash rom. Using the memory debugger i simply alter those locations and send a new spinup command to the drive. the coeficients aren't known up front asd they depend on the headstack mass and how many platters there are. we run plots of the K,I and P parameters as the system attempts self-tuning. the seeds are manually tuned to give the fastest closing of the loop.

Debuggers are not used for stupid pure software debug.. that you can do indeed on a pc. It's where the software interacts with the hardware and the real world that it gets tricky !

2) good luck trying to test your peripheral i/o code on the pc.. pretty hard if you don't have the hardware to begin with. while you can test simply algorithms and dat amnipulation code on the pc that way , anything pertaining to the HAL or BSP cannot be simulated ont he pc as you don't have the models for the  i/o block. if your printf refuses to spit something out on the uart and you don't have a debugger ... good luck trying to get it to work...

There is nothing more powerful than being able to poke around in the memory and io registers of a processor when trying to bring up the board. even before code is written. you can flick bits around and see what happens before a sinlge line of code is written...

[nctnico]

Interaction with peripherals usually is less than 5% of the code and pretty trivial. Not much need to debug that. All my projects have a command line interpreter which allows to change settings on the fly within safe limits. I think I have routines to dump & change memory somewhere but I didn't need those in years. Triggering a scope or logic analyser when 'something' happens can be done with I/O pins.

[free_electron]

Interaction with peripherals usually is less than 5% of the code and pretty trivial. Not much need to debug that. All my projects have a command line interpreter which allows to change settings on the fly within safe limits. I think I have routines to dump & change memory somewhere but I didn't need those in years. Triggering a scope or logic analyser when 'something' happens can be done with I/O pins.

That depends on the application. Robotics systems or any kind of control system is heavily I/O dependent. And some of that stuff is not trivial. Ever tried talking to an ethernet MAC for example ? that a lot of I/O operations. good luck debugging that without a way to look inside the system. sure if you are always depending on pre-written libraries you never come into contact with this , but what if you are the one that needs to make the library ?

As for using an i/o pin. you can't do that. injecting a debug cluase like toggling an i/o pin or printf alters the real loop of the program. After removal of the debug code the entire system needs reprofiling and regression testing. not something you want to do on critical systems.
That's where you use debuggers.

We actually have debuggers that can emulate flash rom as well. instead of having the flash rom on the PCB we plug in a memory emulator. the debuggers can trace the source by looking at the applied addresses on the rom pins. A similar tap sniffs the buses into the rams. this allows us to monitor live data and alter it if needed without stopping , pausing or recompiling code.

If all you are doing is blinking an led and reading a rotary encoder you probably won't need a debugger. If you design real products like ADSL modems, harddisk drives, satellite settopboxes, image processors for flatpanel tv and satellite recievers you NEED debuggers, or your competition hits the market earlier than you do. it's as simple as that.

[andyg]

I've been pretty happy with just using AVR Studio (MS Visual Studio based) for AVR projects and CooCox CoIDE (Eclipse based) for ARM. All free software with debugging capabilities.

[Mechatrommer]

I've been pretty happy with just using AVR Studio (MS Visual Studio based) for AVR projects and CooCox CoIDE (Eclipse based) for ARM. All free software with debugging capabilities.

avr studio 5? istr people bashing it, inefficient etc. i downloaded the ms vstudio express 2008, i hope i can setup toolchains in there (never done this kind of thing), if not then maybe avr studio 5 is next in line.