[Q] Recommended compiler and IDE

[brainwash]

I've been writing simple embedded programs for a while (mostly for PIC) but I always reach that point when the IDE plainly sucks. In my everyday life I use Java with Eclipse and I'm pretty proficient managing millions of lines of code but all these embedded <10kloc projects become a pain.
Closest thing that comes to mind is MPLABX with the Eclipse keyboard mapping, but I will choose anything that's close to decent and is here to stay for a while.

Another thing is that I'm looking to switch from HI-Tech compiler to GCC or whatever else is recommended (SDCC).

What I've used:
- Notepad and command line compilation - 0/10
- SourceBoost - 5/10 - decent enough IDE and compiler but is lagging behind with supported chips; can use just the plain IDE and Hi-Tech compiler but then it's almost useless
- MPLAB + Hi-Tech - 4/10 - very good compiler (especially the PRO), nice debugging features but the IDE seems from 80s and fights you at every step
- MPLABX - 6/10 - based on Eclipse, bloatware, but it works and has autocomplete and other nice goodies; unfortunately you cannot install Eclipse plugins, source versioning is not properly integrated and seems to always be in a beta state
- Eclipse + GCC - 6/10 - I've used it for some AVR Butterfly projects. Unfortunately I cannot find any edition of Eclipse with some microcontroller support, it would help a lot

So two questions:
- What IDE do you recommend that is flexible enough not to outgrow it? It should support basic autocomplete, error highlighting and easy managing of hundreds of files. It should be usable with any architecture: PIC 8-bit, AVR 8/16-bit, ARM. Bonus it should have step-by-step debugging, either simulated or real.
- What compiler do you recommend for the PIC architecture? Does it make sense to switch from the free Hi-Tech one to GCC/SDCC? Is GCC's efficiency close the the Hi-Tech one? I'm looking to easy port code from one architecture/manufacturer to another so that just by changing specific pinouts, macros and includes in a file I'm able to switch platforms.

I think at one of my former employers, where there was some professional embedded design involved, Eclipse and Visual Studio were used interchangeably, mostly with GCC compiler.

Learning curve is not a problem. Also switching from Win7/xp to another OS is not a problem, plenty of RAM available for VMs.
I'm not well versed with C/C++, I've only used it for simple stuff in university and the teachers knew less than me. For predictable results I always have to write first in Java (for quick testing) and then translate into C code.

L.E. : I actually think the IAR compiler or something even more expensive was used for those commercial projects. Will have to ask my former colleagues on those. But I think the setup was chosen for legacy and management reasons and not because it was the best.

[nctnico]

I use Eclipse for everything. If you edit the project settings you can select a different compiler and linker. All you need is CDT (Eclipse C Development Toolkit) to write C for any microcontroller. I wrote a wrapper around the hi-tech C compiler to make is behave like GCC. I've attached the source code.

[mrflibble]

Love the header. I take it you don't own Microchip stock.

[alm]

The choice of C compilers for the 8/16-bit PICs is somewhat limited. As far as I know, gcc only supports the PIC32. Sdcc was quite immature and limited last time I checked. Can't find a current version of IAR embedded work bench for PICs either. GCC is a decent choice for ARM, AVR and MSP430, but not for architectures that don't lend themselves well to C like 8051 and the small PICs. I think the main options are the Hi-Tech compiler and whatever the new Microchip compiler is called.

[brainwash]

Thank you for the answers so far.
I've talked to someone in the industry but they are doing really complex stuff and have toolchains worth several tens of thousands. But he said that the latest trend is to move to Eclipse and GCC, which are mostly free and involve only the cost of training and maybe later maintenance if things go dead.

Well, for hobby projects @8/16-bit this is pretty much overkill, so I'll probably stick to 8-bit PICs and PICC for really light stuff and move to ARM and GCC for bigger stuff.
It would be nice if Eclipse would support the real-time highlighting of errors (for PIC) like MPLAB X does. Maybe I will try to do an Eclipse plugin as a side project.

Love the header of the source, it should be done as a series of prompts: "Are you sure you want to compile? Really sure?".

Ok, to justify myself why I want so bad features for lazy people: these small autocomplete features in Eclipse save me more than an hour per day and allows better naming of the variables, so readability. Catching errors while typing them saves the time having to go back and figure out what you were trying to do. A nice file manager (like Total Commander) saves another hour. An SSD (bought with my money and installed into the work computer) saves another hour. All in all, more time for drinking coffee and reading blogs. Not EEVBlog though, it is blocked by our proxy.

Short Eclipse feature list, just because one day you may want these:
- CTRL+Space to autocomplete
- CTRL+Shift+T to quickly open a type (ignoring secondary files like images and binaries; for those you can use Ctrl+Shift+R)
- CTRL+O to navigate to a method
- each of these searches support camel case, so you only need to type MGD to open something like MicrocontrollerGenericDefinitions
- CTRL + / to quickly un/comment blocks of code
- CTRL + 1 to show suggested compiler fixes, rename the current variable (and all references to it)
- CTRL + Shift + F to quickly format all or selected code with your chosen formatting
- "sysout" and Ctrl+Space magically writes out 'System.out.println("");' and puts your cursor within the quotes; there are a lot of other templates and you can define your own that writes a standard sanity check for a variable that I select and type 'iae' + autocomplete
- Edit - Cleanup code - does a ton of stuff like adding parenthesis where needed, declaring untouched variables as constants/finals
- three clicks away: quickly adding getters/setters (essential for clean code), generating a nice toString() function with all object values
- renaming or moving a file to another folder (package) updates all the code that refers to it
And that is just scratching the surface.

I would say that as the technology evolves these features are a must, because in the future you will have all the libraries (all LCDs, ADCs, EEPROMs, wlan,..) at your fingertips and more time will be spent searching or reinventing the wheel. Flash/code space in a uC is essentially becoming free.
MPLAB (former one) should be relegated to where it belongs: a good IDE for ASM developers.
Rant over, it's too late here.

[PuterGeek]

While the ARM parts might be overkill the small parts have gotten inexpensive. Digi-Key has 24 different Cortex-M0 parts in stock for $1.57 to $2.50 (qty 10) with the most expensive one being $6.27. That isn't as cheap as some of the PICs but unless you are talking volume production, how much is it worth to only need Eclipse?

From what you've said you obviously value your time so if the MPU cost is doable, why not dump PICs?

For PIC compliers, AFAIK, only Microchip, Hi-Tech (owned by Microchip) and CCS are available. It looks like GCC has dropped all PIC and SDCC only supports PIC16 and 18.

[nctnico]

Using a controller supported by GCC has the advantage that you can always switch from one to another without having to rewrite most of the source code. I use GCC for several architectures like Renesas (Hitachi) H8/300, MSP430 and several ARM flavours. If you need a different compiler for each architecture its a lot harder to make most of the compiler and protect the investment in writing the software. One would say C is C but in reality each compiler has its quircks and its own C language extensions.

[janoc]

- MPLABX - 6/10 - based on Eclipse, bloatware, but it works and has autocomplete and other nice goodies; unfortunately you cannot install Eclipse plugins, source versioning is not properly integrated and seems to always be in a beta state

MPLABX is based on Netbeans, not Eclipse. That is why the usual Eclipse stuff doesn't work.

Re compilers - I have used only the PIC18F series of chips so my experience is limited. However, I have to say that both C18 and XC8 (the new Microchip compiler) are junk. I had all kinds of issues with C18, especially its linker doesn't make things easy when compiling for low memory devices. Just yesterday I have discovered that C18 produces bad code for some floating point calculations   The new XC8 compiles the same code into 2x as large binary and the code is still bad. XC8 doesn't even compile their own MLA libraries! Moreover, the documentation for that compiler is non-existent.  I wonder why did they bother to actually release that thing as default choice for MPLABX - do they really think people are going to buy the Pro version when the free one is unusable and be their unpaid Q/A bug hunters?

Add to that weird glitches and bugs in MPLABX, such as change several compiler options, hit Apply, you get an error (null pointer reference) and the changes are lost, weird error messages, GUI bugs, and I regretting investing the time to start with PICs. I took it up because I needed cheap USB-enabled chips where AVR Mega and Tiny series are not competitive, but I guess it isn't worth it. Pity, because the chips are not bad at all.

For AVR MCUs: I am working in Linux, so the new AVR Studio is unusable for me. I am not very fond of the Visual Studio shell neither, but the integration is quite good from what I have seen. I am using Eclipse + CDT + AVR plugin + AVR GCC, works just fine, no problems, except there is no debugging. I suppose it is possible to set up avarice and remote debugging with gdb in Eclipse, but I couldn't be bothered so far - I have usually the problem fixed faster than it would take to wire up my Dragon, set up the DebugWire stuff, avarice and gdb.

I am planning to move to ARM for anything requiring USB or more memory, at the prices of the STM32F10x series or LPC11xx chips it isn't worth bothering with AVRs or PIC and their crummy, proprietary tools. I am using self-compiled GCC toolchain + Eclipse + CDT again, works just fine, including remote debugging through OpenOCD and JTAG. I have tried LPCXpresso - Eclipse-based toolchain from NXP - works fine, but why did they have to block installation of Eclipse addons ?!? Stupid! I guess nobody would otherwise pay for things like debugging support if they could use the regular Eclipse debugger

[janoc]

It would be nice if Eclipse would support the real-time highlighting of errors (for PIC) like MPLAB X does. Maybe I will try to do an Eclipse plugin as a side project.

It does - the new C/C++ CDT plugin released this year with the Juno release has something called Code Analyzer. It highlights typos and problems as you are typing, then press CTRL+1 and you get prompts on how to resolve the problem (rename the identifier, add #include, add a cast, etc.). On the other hand, with large software it can have lots of false positives, so you will have to tweak the settings.

I haven't tried Eclipse with PIC compilers (only using MPLABX), but it should be doable.

[mrflibble]

I have tried LPCXpresso - Eclipse-based toolchain from NXP - works fine, but why did they have to block installation of Eclipse addons ?!? Stupid! I guess nobody would otherwise pay for things like debugging support if they could use the regular Eclipse debugger

Or maybe they just don't want to deal with support issues related to plugins.

[TheDirty]

The LPC Xpresso toolchain is Code Red's.

[ToBeFrank]

I am planning to move to ARM for anything requiring USB or more memory, at the prices of the STM32F10x series or LPC11xx chips it isn't worth bothering with AVRs or PIC and their crummy, proprietary tools. I am using self-compiled GCC toolchain + Eclipse + CDT again, works just fine, including remote debugging through OpenOCD and JTAG.

Does OpenOCD work well with SWD yet? LPC11xx chips are SWD only and last time I tried it, it was an exercise in futility.

[janoc]

Or maybe they just don't want to deal with support issues related to plugins.

Then it is very convenient that the debugger they ship is restricted to only the LPCXpresso boards. The compiler and everything works just fine with another board having the same MCU, but you cannot debug unless you have the LPCXpresso board with their proprietary debug circuit.

[janoc]

Does OpenOCD work well with SWD yet? LPC11xx chips are SWD only and last time I tried it, it was an exercise in futility.

I haven't tried myself yet (that's why I focused on the STM32F103x series for the time being - it has JTAG), but it should be possible already:
http://snowcap.fi/blog/2011/11/21/openocd-with-swd/
https://forum.sparkfun.com/viewtopic.php?f=18&t=33398

and:
http://repo.or.cz/w/openocd/openocdswd.git

It may not be the simplest thing to get to work, but then you either pay megabuck for the commercial toolchain where this is set up for you or you pay with your time to set it up.

[shebu18]

I want to go from windows to linux with avr programing. What ide is there that also has librarys for avr's. Librarys for SPI, I2C, PWM and so on, something like MikroC. The ideal thing would be that i can use the librarys from Arduino.


Else i am stuck with Arduino because of the library support and only 2-4 avr's.

[Kremmen]

The manufacturer Atmel provides IDEs in the form of AVR Studio 4 and 5 and Atmel Studio 6, but only for Windows. If you want an IDE, do seriously consider using these; they support all Atmel parts, AVR, UC3, ARM. The compiler behind the scenes is the gcc we have learned to trust and love, more precisely the AVR variant of it.
Atmel Software Framework (ASF) provides example code for all of the embedded peripherals and much more besides.

If your priority is Linux, then this won't work and you will lose a lot by making that decision. There are supposed to be toolchains for Linux as well - the compiler and other tools certainly work but if there is a proper IDE available, i have no idea. I do development in Linux as well, but not for Atmel processors.

Studio 6: http://www.atmel.com/tools/atmelstudio.aspx?tab=overview

Older versions: http://www.atmel.com/tools/STUDIOARCHIVE.aspx

[alm]

Eclipse with CDT or Code::Blocks seem fairly popular. Both will integrate with avr-gcc since it's a standard GCC toolchain, but might require some manual setup. I believe there are some instructions available on various websites/blogs. IDEs don't typically come with libraries, they don't even come with a compiler. Both the compiler and libraries will have to be acquired from other sources. Avr-gcc is available in many Linux distributions. I don't see any reason why you couldn't just download the ASF and use it with your IDE of choice, it won't have any nice setup wizards, though.

[shebu18]

so I shall use virtualbox with win 7 and install studio 6 there. I shall see what i will do because i use some apps that are running only on windows.

Sent from my GT-I5800 using Tapatalk

[McMonster]

The simplest way for AVRs on Linux is Eclipse with CDT and AVR Eclipse plugins, avr-gcc and avrdude, that should be enough. Everything except AVR Eclipse plugin should be available right from any major distro's software repositories, installing the plugin should be easy, just follow the guide on its web page.

Some USB programmers may require additional steps with writing udev rules like described here, just supply proper USB id numbers and reboot.

[westfw]

Atmel Software Framework (ASF) provides example code for all of the embedded peripherals and much more besides.

That's not quite true.  ASF supports the XMEGA, the AVR32s, and the ARM chips, but it's support of the standard AVR line is very limited.