ARM IDE recommendation for development with different vendors chips.

[exapod]

After this post https://www.eevblog.com/forum/microcontrollers/arm-begginer-questions/ i installed CoIDE and started using it for some STM32 projects without big problems but now i'm faced with a small dilemma.
For an university project (already exsisting board) i'm forced to use a nxp ARM and just for the sake of experimenting and not be stuck with only one vendor in the future i want to try some freescale and Energy micro chips.
The nxp ARM that i have to use, most of Energy micro and some Freescale chips are not supported by CoIDE and there are no news of when the new devices will be supported so i'm thinking of abandoning CoIDE for a more professional IDE.
Right now i think have two options:

1. Use for each chips its own free IDE with limitation  :
     -lpcxpresso (NXP) with 256 k limit that i have to use for the university project.
     -codewarrior (Freescale) with 64k limit.
     - IAR or KEIL (ST) with 32k limit.
2. Buy a personal license for rowley's CrossWorks for ARM that is 100 USD. I'm a student so IAR and KEIL are too expensive.

What do you suggest me to do?
Thank you all for the answers and sorry for my bad english.

[han]

if I in your position, I will ask my friend around me what program he/she use.
(so i can gen easy quick free live tutorial) 

[andersm]

How much support do you need from the development environment? With Eclipse, ARM-GCC and OpenOCD you can develop code for any manufacturer's chips, but it can take more work to set up.

[Codemonkey]

lpcexpresso is Eclipse with arm-gcc already set up for you, it just uses the red-link stuff for debugging with the lpcexpresso boards built in jtag debugger rather than using openocd.

[free_electron]

Get a Keil student licence.

Keil is owned by ARM... Doesn't get any better than that

[nctnico]

How much support do you need from the development environment? With Eclipse, ARM-GCC and OpenOCD you can develop code for any manufacturer's chips, but it can take more work to set up.

I agree. Eclipse is a good choice and the newer versions are much easier to setup because they allow for selecting a cross-compiler toolchain. Then again adding support for a chip to CoIde may be just a matter of editing a simple text file.

[andyturk]

What do you suggest me to do?

Use this without an IDE.

1. It's free.
2. That's the compiler you'll be getting in most of those other IDEs anyway.
3. Since you're in school, now's the time to learn how to work with a bare toolchain (and your favorite text editor).

[Jeroen3]

I use Keil uVision 4. Not 5, they've removed all flash programming algorithms . And using the extended trial for hobby&student license I can flash upto 256k.
I think it's the best compiler/debugger available, the editor can be improved though...

I've looked at co-ide, but using that gcc DIY stuff keeps distracting you from the purpose of the tool.
Eclipse (lpcxpresso) was just too slow a year ago, did it get any better yet?

Bare toolchain and gdb for arm is only for the sacred few.

[Lukas]

What do you suggest me to do?

Use this without an IDE.

1. It's free.
2. That's the compiler you'll be getting in most of those other IDEs anyway.
3. Since you're in school, now's the time to learn how to work with a bare toolchain (and your favorite text editor).

I can highly recommend that. I've built my own development setup for the STM32 mcus using make, the gnu toolchain and openocd. Switching to another ARM mcu is just a matter of swapping out startup files, linker scripts and register definitions. Since I've dealt with them, I know how they work. In the way of writing the makefile and tweaking compiler flags and so on i learned a lot about the toolchain, much you can ever learn by clicking buttons and checkboxes in your IDE. Makefiles are easily managed by a version control system of your choice, can't say that about proprietary IDE project files.
Let's say, you've got two projects, one works, the other one doesn't and you suspect, there's something wrong in the 'project settings'. With an IDE you're left with visually comparing checkboxes, with Makefiles, just throw them at your favourite diff tool and the difference is evident.

Another great thing about the gnu toolchain is, that it's available for an unparalleled of targets (both operating systems and architectures): x86, ARM, AVR, MSP430, PowerPC, Mips? The gnu toolchain got you covered. No matter whether you're writing C code for your PC or for your MCU, you've always got the same compiler with the same error messages and flags. No need to say, that Makefiles always work the same (even if you're not building programs with then).

One major drawback of not using an IDE are inferior debugging capabilites. You've got the Gnu debugger, which has a pretty decent CLI and suffices my everyday debugging needs. (Breakpoints, watchpoints, backtrace, etc) As with the rest of the gnu toolchain, GDB is available for almost any platform, so I've been able to leverage my GDB skills from x86 to ARM.

It may take you longer to get started, you'll learn a lot (sometimes too much), but on the long run it'll make software development much more understandable. So come and join the circle of

the sacred few

If your main objective is 'getting things done' and you don't have a problem with learning a new (often low-quality) IDE for every new task, go the IDE way.

[ctz]

I also moved to using bare arm-gcc+gdb from proprietary IDEs. You can use CMSIS or libopencm3 if you need code-level portability between vendors. You have a free choice of build systems and version control.

I moved mainly because although Eclipse is the common base to all the IDEs which came with the devboards I was evaluating (by NXP, TI, STM and Freescale), they come as entire Eclipse distributions (rather than Eclipse add-ons which could coexisting in one IDE).

That means you get 4 different copies of Eclipse to configure, and each has a different hand-holding layer on top (the worst of these is Freescale "Processor Expert" which only reduces the time it takes to misconfigure chip peripherals, in my experience).

They also seem to have fairly crazy ideas about what parts of the libc and support libraries should be necessary to write 3 lines which configure a GPIO pin and blink a LED. That binary was 31KB text + 4KB data with Freescale CW. In comparison, the same thing with libopencm3 (using its link script and early-boot code) is 1176B text + 0B data.

I definitely wouldn't recommend the bare-metal approach if you're new to programming and debugging, though. You need to be comfortable with C and gdb for this to work well. But if you are, I think the results are more efficient and easy to manage, and the skills you learn easier to transfer.

[Jeroen3]

With an IDE you're left with visually comparing checkboxes, with Makefiles, just throw them at your favourite diff tool and the difference is evident.

Tools that store project setting as binary dump should be avoided. Luckily there is XML.

[Lukas]

With an IDE you're left with visually comparing checkboxes, with Makefiles, just throw them at your favourite diff tool and the difference is evident.

Tools that store project setting as binary dump should be avoided. Luckily there is XML.

Yeah, but it's still undocumented
448 lines of XML (KEIL) where nobody can tell me anything vs. 112 lines of Makefile, all of which can be understood by the documentation of make (or Stackoverflow) Surely, make is almost 40 years old by now and has its quirks, but it's still the de-facto standard in the open source world.

For refrence: my build environment: https://github.com/carrotIndustries/stm32-template

[DD4DA]

Checkout  "EmBlocks V1.45". That's a GCC and the common utilities thats neededto build your Project. Hope this helps you.

de DD4DA

[dannyf]

For cross vendor support, nothing beats keil and iar. I also like the rte in uvision 5 - very coide like.

if it is for learning and you are short on money, go with gcc.

[Emil]

Are there any good resources for getting started with gcc-arm-embedded (without an IDE)? Any recommended books or tutorials?

[Psi]

Checkout  "EmBlocks V1.45". That's a GCC and the common utilities thats neededto build your Project. Hope this helps you.

de DD4DA

+1 for emblocks

[Lukas]

Are there any good resources for getting started with gcc-arm-embedded (without an IDE)? Any recommended books or tutorials?

http://www.triplespark.net/elec/pdev/arm/stm32.html
It depends on what you already know about make and the gnu toolchain. If both are new to you, I can recommend familiarizing with them first on your host PC. 
Just take a Makfile (e.g. mine: https://github.com/carrotIndustries/stm32-template/blob/release/Makefile ) and try to understand it using google and the documentation of the tools used. It's not rocket science.

[exapod]

Thanks for the answers. I'm trying to setup a GCC toolchain with this guide http://mcuoneclipse.com/2014/05/18/constructing-a-classroom-ide-with-eclipse-for-arm/ .

[dannyf]

In case it is not already mentioned, CoIDE is Eclipse. So whatever you do with that link you just posted, you can do it through CoIDE.

[bingo600]

With an IDE you're left with visually comparing checkboxes, with Makefiles, just throw them at your favourite diff tool and the difference is evident.

Tools that store project setting as binary dump should be avoided. Luckily there is XML.

Yeah, but it's still undocumented
448 lines of XML (KEIL) where nobody can tell me anything vs. 112 lines of Makefile, all of which can be understood by the documentation of make (or Stackoverflow) Surely, make is almost 40 years old by now and has its quirks, but it's still the de-facto standard in the open source world.

For refrence: my build environment: https://github.com/carrotIndustries/stm32-template

Lukas

Your : epm ir required.epm 

On my linux mint says :

epm: Expected whitespace after file type - cmsis
epm: Expected whitespace after file type - hal
epm: Expected whitespace after file type - bsp-f4discovery
epm: Error - missing %product, %copyright, %vendor, %license,
     %readme, or %version attributes in list file

I might not understand the system , (haven't read up on epm) , but it won't work out of the box

/Bingo

[dannyf]

Out of curiosity, I took down the lpcopen library for 4078 and compiled it in CoIDE.

5 minute exercise and the code compiles just fine - a few warnings because the folks at NXP used "unsigned int" instead of "uint32_t" in the code. Didn't seem like that they used stdint.h.

[tipofthesowrd]

I'm actually in the same situation except I'm using an LPC board which comes with the MBed bootloader.
Next to that I'm experimenting with some Freescale ARMs.

I setup the main (and not emIDE) branch of Code::Blocks for compiling gcc-arm programs.
Most of the setup is quite straightfoward. The most anoying encounter was with the linker that had required to have the -lmbed lib as first in the command line.

I'm also awaiting my busblaster so that I can interface it with openOCD for JTAG/SWD debugging