PIC ATMEL ARM IDE (Compiler+Editor+Programmer)...

[granz]

IAR and Keil are both very good. IAR's user interface is more minimalist and to my liking.

Of the free ones, CoIDE does an excellent job supporting STM chips. Pretty much all existing STM32F chips are supported and many on real time basis. The project wizard is top notch (far better than IAR's and Keil's for example), and there is no code size or time limits. It also supports stlink and other manufacturers' chips.

However, its support for jlink is non-existent - segger's fault.

Right, we didn't want to purchase IAR or Keil stuff.  Looks like CoIDE is fairly new?  This is the first I've heard of it.  Thanks for the mention--I'll have to give it a try, I already have the hardware so it's a no-brainer.

[os40la]

I use PIC32's quite a bit also, and they are also quite nice (but are a MIPS core, not ARM).

I thought PICs are based on a modified Harvard RISC instruction?    Just to add to the confusion... ARM = Acorn RISC Machine.   

[granz]

I use PIC32's quite a bit also, and they are also quite nice (but are a MIPS core, not ARM).

I thought PICs are based on a modified Harvard RISC instruction?    Just to add to the confusion... ARM = Acorn RISC Machine.   

Right.  MIPS is a RISC architecture as well.  ARM is a type of RISC, but ARM is not the only RISC.     Alpha, SPARC are other examples, and there are many more.  Just like ARM, there have been several versions of the MIPS instruction-set as well, just to add to the confusion.

MIPS is actually older than ARM, and was created by the pioneer of RISC architecture.

[astra]

On Basic, I think it will be a waste of your time.

On assembler, unless you will do just extremely simple or extremely complex stuff AND you have lots of resources at your disposal, it too is a waste of your time on those chips.

You are right..
I'll try with C...
Astra.

[Kremmen]

On Basic, I think it will be a waste of your time.

On assembler, unless you will do just extremely simple or extremely complex stuff AND you have lots of resources at your disposal, it too is a waste of your time on those chips.

While i fully agree, let me just pick one nit: "extremely complex" would by definition be an anti-candidate for assembly. I think you rather mean extremely low-level stuff where you need detail level control of specific hardware beyond what an higher level language can provide.
Even in that case one should encapsulate such functionality inside a library an use it from there.