Comparaison of different ARM mcu and IDE - Page 1
Forum section: electronics / general

author: asgard20032
author_rank: Regular Contributor
timestamp: January 26, 2015, 03:08:56 am
content: As the name imply, this thread is about comparing different ARM platform and IDE.Freescale VS Atmel VS TI VS ST VS NXPemIDE VS Em::Blocks VS CoIDEUsing the free propriatary IDE VS one of the above (for example, LPCXpresso vs emIDE or CCS vs CoIDE).What are the pro and cons of each?

author: Psi
author_rank: Super Contributor
timestamp: January 26, 2015, 04:54:34 am
content: I use EmBlocks with ARM GCC for my STM32 projects.But that's the only one in your list that i've used, so i cant really offer any constructive comments other than " EmBlocks - It doesnt suck"I do wish it would let me change the background color of the messages window though.

author: Korken
author_rank: Regular Contributor
timestamp: January 26, 2015, 07:07:18 am
content: I have tried a lot and in the end I just use standard eclipse for debugging (with a few plugins for MCU registers and RTOS) and when I develop I use Sublime Text 2/3.With this just get ARM GCC from launchpad and this has worked a treat for the last 6 years.Plus it works on Windows and Linux.And with this setup I program NXP LPC, STM32 and TI, all Cortex-Mx processors.//Emil

author: dannyf
author_rank: Super Contributor
timestamp: January 26, 2015, 11:49:41 am
content: There are two camps: CB-based (emIDE and emBlocks) and Eclipse-based (everybody else).The CB-based IDEs are more utilitarian and much smaller. The Eclipse-based are, without exception, bloated, but offer decent debug support.I use emBlocks for PIC24 and have its biggest fan since its beta days.Of the eclipse-based ones, CoIDE stands out for its ease of setting up a project, and easy / robust downloading / debugging. I have no complaint about it at all, other than limited support for some vendors. It has, however, fabulous support for ST chips.LPCXpresso is fairly crappy. CCS from TI is decent, and KDE is great, when paired with PE.So the answer is quite simple: if you have money, Keil / IAR. Otherwise, CoIDE unless you happen to work on chips it doesn't support. Then vendor IDE.

author: madires
author_rank: Super Contributor
timestamp: January 26, 2015, 12:16:41 pm
content: nedit/vim, make and ARM gcc.

author: asgard20032
author_rank: Regular Contributor
timestamp: January 27, 2015, 01:10:13 am
content: KDE and PE? (kinetis development environment, but what is PE?)

author: Brutte
author_rank: Frequent Contributor
timestamp: January 27, 2015, 06:41:04 pm
content: Do you care if your development tools are Eclipse based?I'd recommend one IDE that serves all the architectures and vendors of your choice. Master this one instead of jumping through half a dozen of tailored ones.That could mean IAR or Keil for example, if that pays you back.With free IDEs, pick the one that is least restrictive and supports multiple toolchains/plug-ins/tools that you use. That could mean Eclipse or NetBeans or other..I use Eclipse with AVR8, x86, mips4k and ARMv7M. C/C++ and a little bit of Ada.I would not recommend picking six limited IDEs one for each vendor because then you have to multiply your learning curve times six at best. Even with embedded, a sheer count of algorithms is tested on host computer first. So the above LPCXpresso or CCS or MPLABx is cool only if you do not have plans to touch anything else. Of course a vendor-specific one-click IDE has the advantage of being attractive for RTFRM-disabled.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: January 27, 2015, 08:10:26 pm
content: Quote from: asgard20032 on January 27, 2015, 01:10:13 amPE = "Processor Expert", a GUI configuration "wizard" and code generator, it has some use in configuring peripherals, but a lot of the time the generated code is pretty rubbish, buggy with poorly designed interfaces.

author: Bassman59
author_rank: Super Contributor
timestamp: January 28, 2015, 04:11:29 pm
content: Quote from: asgard20032 on January 26, 2015, 03:08:56 amDatapoint: the Visual Studio-based Atmel environment is decently powerful but holy fuck is it slow as hell.

author: zapta
author_rank: Super Contributor
timestamp: January 28, 2015, 04:54:33 pm
content: Quote from: Bassman59 on January 28, 2015, 04:11:29 pmI installed it once because I wanted the programming utility. It was a monstrous installation process. Didn't like it at all.

author: dgtl
author_rank: Regular Contributor
timestamp: January 28, 2015, 09:51:33 pm
content: My setup is similar to Korken's: bare eclipse CDT, hardware debugging plug-ins, CodeSourcery compiler.The vendor-provided ide's are usually Visual Studio or Eclipse based. I prefer eclipse-based systems due to the fact that Ive been using eclipse for all my c/c++ programming projects for almost 10 years. It is a big plus if the ide's are not windows only, so I would not have to fire up my Windows VM for every work that needs to be done. Although most of them are using gcc-based toolchains under the hood and the eclipse is also platform-independent, most of the vendors are supporting windows only. It doesn't seem to be too big work to support other os'es as well.NXP's LPCXpresso is quite nicely integrated package, everything works quite well out-of-the-box and NXP board support libraries are so far the only ones that Ive been able to somewhat use in my projects. The other vendor-provided board support packages are just not what I need, are terribly written, full of bugs, take a lot of flash space on mcu and/or do not perform well enough. So most of my projects are written bare-metal, the only external file is chip register definition header file. NXP's redlib is usually a better replacement to newlib, but going this way means being locked-in to LPCXpresso toolchain later on. Also, in latest releases the new features have gone out of control; there is so much choice and so little information, that even to create a blank blinky project you need to check documentation how to set up. It was simpler to understand a year ago. The debuggers usually work well, there have been some problems (ie a couple of years ago the lpcxpresso probe corrupted data in LPC1343 in one of flash blocks in some circumstances when the uc was almost full to the last byte... that was not nice to debug)Atmel's Studio is just slow, huge, feels uncomfortable and their codebase was so badly fragmented, that code from different libraries could not co-exist in same uc. I was forced to use it for some tinyAVRs, the support for all of them was not mainlined properly back to avr-gcc. Also, it's windows only. So far, negative emotions.ST does not have their ide so far (although they told at electronica they are working on it). Their board support code is a mess. ST-Link2 works very well using texane stlink and gdb.Silabs(Energy Micro) have done good work on their ide. Very well integrated. Sadly, windows-only.Cypress tools are also quite good, but they are windows-only as well.Haven't used TI, Freescale or Spansion/Fujitsu uC's.

author: theatrus
author_rank: Frequent Contributor
timestamp: January 30, 2015, 05:52:44 am
content: My IDE is generally Emacs :-)But to the point, I always look for SDKs and comprehensive libraries for things like USB. I can setup registers for timers and interrupts, but bigger I/O subsystems better have a good vendor or open source library.I'm currently evaluating the Kinetsis SDK - sadly only newer chips, but at least USB is in there. I've used Atmel's AVR32/ARM USB library and found it chock full of bugs (but usable). ST, as far as I can tell, still can't ship an SDK where you can even compile the examples out of the box.As far as IDEs go, I've used IAR for the EnergyMicro/SiLabs parts. I ignored the horrific built in text editor and wrote a build tool around their compiler. The debugger however was very nice.

author: Howardlong
author_rank: Super Contributor
timestamp: January 30, 2015, 08:31:31 am
content: Like NXP's LPCxpresso, TI's Code Composer Studio is Eclipse based.While there are similarities, they're implemented different enough to make it feel like you might as well be on a totally different IDE.The TI implementation is slicker both in terms of being more intuitive and better-performing in the edit-compile-debug cycle.For example you need to use the NXP shortcuts to debug, not the icons you may be more used to. The NXP debug cycle often breaks too, usually due to accidental operator error, but being non-intuitive doesn't help either. Correcting it really gets in the way of our workflow.For TI's CCS, you need to really make sure you understand the way their project links work or you'll end up in an unholy mess. It seems to be much more fundamental requirement to be able to work this than with LPCxpresso.There is a lot more quality documentation for TI's CCS including both written and video, but the downside is knowing where to start, there's just so darned much of it.

author: ChrisMH
author_rank: Contributor
timestamp: January 30, 2015, 05:55:23 pm
content: CrossWorks is quite good and not based on Eclipse. I've used it for about a year and have been happy with it.http://www.rowley.co.uk/arm/Relatively inexpensive, too.I use it with Freescale and STM32 chips, but it supports many others.

author: codeboy2k
author_rank: Super Contributor
timestamp: January 30, 2015, 07:57:29 pm
content: I don't mind the Eclipse based systems, but I hate that they all install their own copy of Eclipse.From my software dev side, I understand that this is most likely a versioning issue that saves them dealing with support calls caused by mismatched software versions if they just shipped plugins. It's much safer to ship (also easier to control) a complete, working turnkey package.I have plenty of disk space, it's just my OCD

author: zapta
author_rank: Super Contributor
timestamp: January 30, 2015, 09:45:59 pm
content: Quote from: codeboy2k on January 30, 2015, 07:57:29 pmI actually likes it, it provides isolation between vendors (e.g. NXP ARM lpcxpresso vs Android app IDE) and yet having consistent UI across applications. Just treat them as different applications that were implemented using the same framework ;-)

author: dgtl
author_rank: Regular Contributor
timestamp: January 30, 2015, 10:01:09 pm
content: Quote from: dgtl on January 28, 2015, 09:51:33 pmHad a new look at EFM32. To a surprise, now they support Linux and MAC too! Everything worked very smoothly and fast (at least after the installation; you download from web the IDE, at first start it downloads almost 1GB of data and is blocked until it is doing it). Very well integrated, things are optimally layed out and no magic or in-depth study of manuals was needed to get simple things going. Definitely would recommend to a beginner.

author: Howardlong
author_rank: Super Contributor
timestamp: January 30, 2015, 10:03:19 pm
content: Quote from: zapta on January 30, 2015, 09:45:59 pmAgreed: there is a history of certain Java based IDEs like Eclipse and Netbeans not working with a common default Java VM install, with them each demanding their own specific versions and settings. These days the JREs tend to get distributed with their own tailored JVM.

author: senso
author_rank: Frequent Contributor
timestamp: January 30, 2015, 11:40:36 pm
content: Quote from: Bassman59 on January 28, 2015, 04:11:29 pmIts snappy in my 3 year old core i7 laptop, never crashed.About ARM's I have been using both CooCox and PSoC Creator, like them both.

author: AndyC_772
author_rank: Super Contributor
timestamp: February 01, 2015, 04:49:33 pm
content: Quote from: ChrisMH on January 30, 2015, 05:55:23 pm+1Tried free tools, gave up on them. Like most things in life, they're nearly, but not quite, worth what you pay for them.CrossWorks was quick and easy to install, and 'just works'. Developing for STM32 with it is a pleasure.

author: nctnico
author_rank: Super Contributor
timestamp: February 01, 2015, 11:40:15 pm
content: The commercial vendor IDEs often provide a slick interface and allow for a quick start but once you need more power to take on larger projects they often start to fall short. Eclipse has been developed to be the ultimate IDE and IMHO it is doing a good job. I have been using it for the past 10 years now for everything that smells like source code I come across (including VHDL). Being able to navigate through projects with hundreds of files, having proper version control integration, work the same on Windows & Linux (the projects are actually interchangable between the platforms), etc AND needing only one environment for any programming job makes Eclipse very, very hard to beat.

author: Bassman59
author_rank: Super Contributor
timestamp: February 03, 2015, 07:15:56 pm
content: Quote from: theatrus on January 30, 2015, 05:52:44 amSiLabs has migrated the EFM32 and most of the 8051s to an Eclipse-based environment, which works quite well and it also runs on Windows, OS X and Linux. The Precision32 ARMs (which are pretty great) is still handled by a separate Windows-only Eclipse.

author: zapta
author_rank: Super Contributor
timestamp: February 03, 2015, 07:52:49 pm
content: Quote from: Bassman59 on February 03, 2015, 07:15:56 pmUsing eclipse makes a lot of sense from vendors' protective, they get for free a fully featured and customizable IDE framework so the can focus on their added value.

author: westfw
author_rank: Super Contributor
timestamp: February 04, 2015, 08:56:39 am
content: Eclipse, or Eclipse-based?I assume that when nctnico says that they like the cross-architecture capabilities of Eclipse, that means that they're starting with a "vanilla" Eclipse and adding processor support (somehow), rather than using vendors' pre-customized "eclipse-based" IDEs, right?How difficult is adding a new cpu/etc to standard Eclipse?Do any vendors provide "packages" that add their chips to standard eclipse instead of or in addition to their customized IDE?Does Eclipse have some sort of capability that makes such packages easy to implement?Do you get sneered at by the desktop/server target Eclipse users when you have a uC-specific problem?I've used Eclipse rather briefly for an Android programming class, and didn't find it too awful (aside from startup time :-( )But it didn't strike me as something wonderful that I wasnted to use elsewhere, either. A lot of the added value seemed to be the incorporation of additional tools (XML editors in particular, for Android) that wouldn't be important in the uC world.----The biggest difference I've noticed between different ARM chips is in the quality of the documentation, and I'm not prepared to say whether that's consistently good or bad across the full 1000+ pages needed for a typical ARM chip, or just the pieces I've looked at. And there seems to be some disagreement about what makes documentation "good", anyway.

author: nctnico
author_rank: Super Contributor
timestamp: February 04, 2015, 09:30:39 pm
content: The plain version of Eclipse to use for C/C++ programming is Eclipse CDT. If you install Eclipse CDT and a GCC based compiler toolchain you can point to that toolchain in the project settings, set the right processor/mcu command line options so the toolchain know which microcontroller to compile/link for, link script (if necessary) and hit compile. That's all there is too it.The biggest thing to get your head around is the way Eclipse manages projects. When you start it you can point it to a directory. That directory is your workspace. Within that workspace you can create projects which compile into a binary. There is no limit to the kind of projects you can mix. I have Windows applications, embedded firmware and VHDL living happily together in one workspace.

author: zapta
author_rank: Super Contributor
timestamp: February 04, 2015, 09:40:17 pm
content: Quote from: nctnico on February 04, 2015, 09:30:39 pmMy conventions are to use the default workspace but have the project files in different directories that are controlled by version control. That is, the workspace is mine, the projects are shared.

author: nctnico
author_rank: Super Contributor
timestamp: February 04, 2015, 10:38:35 pm
content: Eclipse can do that for you within the workspace. No need to have seperate directories for that. Eclipse also has the tools to merge versions and resolve conflicts.