Inexpensive ARM Development Tools

[Sal Ammoniac]

it does 16 full loops under 30 seconds (each loop has 4 steps). So that is over two steps per second.
Mind I did not state the are no faster stepping IDEs but OP's 2s sounds impossible (or OP has messed up something badly with setup).

OP here... If something in my setup is messed up, then it's the fault of the IDE vendor because this happens on a default install of the tool with no modifications done to the setup by me.

The stepping speed you quote is nothing to brag about. Two steps per second is still 1/2 second per step, which is crawling. Rowley CrossWorks can easily do >10 steps per second with an ST-Link/V2.

[Godzil]

Oh no worries I've done that, all the memory stuff, and guess what? All the version of eclipse I've use, the indexer just crashed in a dead loop hogging CPU, I've let it run for hours and even day without it to recover.

Sorry, but on that Netbeans worked better; far from perfect, but better.

As usual, it's not because a product is used by a lot it's mean that it's a good product (or the best).

Can I remind the VHS?

[Sal Ammoniac]

Eclipse is (among) the most used IDEs in the world; do you really think that so many people will want to use an IDE which is slow?

See http://www.ihateeclipse.com/

In my case, I don't run any anti-virus software or anything else what could have a similar effect on my machine's ability to run Eclipse. In fact, I keep my development machine pretty pure. All I have on it are my IDE, GCC and Clang, another editor (Notepad++), a serial port emulator, the drivers for various USB interfaces (FTDI, etc.), Adobe Reader (to read datasheets), and a browser. My experience with Eclipse lameness isn't just limited to one example. I've tried several (Atollic, LPCXpresso, and another one I forget the name of) and they all perform like dogs. Granted, performance tuning may be necessary to make Eclipse perform at its best, so why don't vendors like Atollic and NXP do this? Why don't they distribute a fully tuned IDE rather than relying on users to have to do this tuning?

[Brutte]

How can you compare an "hello world project" with less than 10 lines of code, with a Multi GB project?

a Multi GB project

where did OP mention stepping through multi GB project?? Reference please.
I am comparing that / referring to the Cortex-M test project OP stepped through under Eclipse.

[Lukas]

This is exactly what Microchip does with their PIC16/32 compilers - for an extra $1k you gain back the optimizer settings in GCC. Dubious at best.

Since their compilers are based on GCC, there's nothing stopping anyone from downloading the source from the Microchip site, removing the licence manager code, and compiling it.

I'm not kidding, I tried but I failed with very obscure build erros, like invalid parameters being passed to cc1 during compilation. Spent one or two evenings on it and walked away frustrated. Looking in the build info of the binary, they are building the already ancient GCC using a even more ancient one (4.1 iirc, which is like 10 years old). Their PIC support is sort of 'tacked' on just to make it work, really dodgy. Even if you've managed to build the gcc, it will generate calls to functions from their proprietary libc/libgcc for multiplication, soft float etc. I haven't found anyone being successful with building the PIC gcc from source. Even if you manage to build it, you're still left with an older/inferior compiler than you'll get for AVR, MSP430, RL78 or ARM. For these ones, I can use that latest GCC that I also use for building software on x86.

[nctnico]

IMHO Microchip really shot themselves in the foot by making a proprietary GCC for their PIC32 microcontrollers because they will always be behind with the mainstream GCC development. GCC for ARM (maintained by ARM!) is much more up to date and the latest upgrade I did resulted in a healthy improvement of code density.

[dannyf]

I have been trying DS-5 for a while.

[c4757p]

IMHO Microchip really shot themselves in the foot by making a proprietary GCC for their PIC32 microcontrollers because they will always be behind with the mainstream GCC development. GCC for ARM (maintained by ARM!) is much more up to date and the latest upgrade I did resulted in a healthy improvement of code density.

Personally I can't imagine why anyone would choose a MIPS microcontroller when there is ARM. And having to deal with Microchip's bullshit on top of that? No thanks.

[theatrus]

IMHO Microchip really shot themselves in the foot by making a proprietary GCC for their PIC32 microcontrollers because they will always be behind with the mainstream GCC development. GCC for ARM (maintained by ARM!) is much more up to date and the latest upgrade I did resulted in a healthy improvement of code density.

Personally I can't imagine why anyone would choose a MIPS microcontroller when there is ARM. And having to deal with Microchip's bullshit on top of that? No thanks.

Agree. The only reason I'd consider Microchip is for an absolute bottom of the range part, where I need a the cheapest possible low pinout MCU.

Even some of their earlier advantages, such as peripherals being available at (nearly) any pin switch matrix are available in other vendors now.

[Sal Ammoniac]

Personally I can't imagine why anyone would choose a MIPS microcontroller when there is ARM. And having to deal with Microchip's bullshit on top of that? No thanks.

The PIC32 parts are actually not bad. The PIC32MX series compares favorably with the Cortex-M3 and the PIC32MZ compares favorably with the Cortex-M4/M7. They have a free IDE (MPLAB X; based on NetBeans) and a free C compiler (without optimizations; you can pay for optimizations or build it from source). The IDE works well (e.g. better than your average Eclipse-based ARM IDE) and is updated frequently.

The core is based on MIPS32, which is quite a nice architecture. Simpler in many ways than the Cortex-M architecture, but just as capable and fast. The latest iteration, the PIC32MZ runs at 200 MHz and has hardware floating point and DSP instructions. Microchip released it too early and the initial silicon had nasty errata, but most of them have been fixed now and it's no more buggy than your average Cortex-M part. The peripherals are simpler than some of the "kitchen sink" peripherals seen on some Cortex-M parts, but they get the job done and they're implemented in a consistent manner.

For a hobbyist, the biggest Microchip shortcoming is the lack of good, cheap development hardware. The PICKit 3 is relatively cheap at $48, but it's not good (it's slowwwwwwww). The next step up the line is the ICD-3, which is about as fast as an ST-Link/V2, but it's $200.

Overall I like the Cortex-M parts better, but PIC32 is certainly a viable option, especially for someone coming from the 8-bit or 16-bit PIC worlds.

[westfw]

a Multi GB project?

Perhaps we can start by agreeing that just maybe the people writing multi-gigabyte multi-core 64-bit ARM projects might be selecting development tools based on different criteria than the people trying to squeeze code onto one of those Cortex M0 microcontrollers with 16k of program space?

(This is actually a weakness of the ARM target.  Since it does span from 4k to 4G (and larger) configurations, it's really easy to find tools that are inappropriate for your particular need.  My "newlib" complaints are an example.  The currently-poor CM0 libgcc soft floating point routines are another.)

("maybe" is quite accurate, too.  I'm pretty much a "legacy editor and CLI tools" kinda person regardless of project size, but I've seen people come into a multi-GB environment and say "where's my Eclipse?  I can make it work; just because it'll take 30 minutes to start up is no big deal - I only do that once a day anyway."  In fact, one of the things I look for in a set of development tools is portability.  I don't want to get stuck loving an environment that only runs on one OS and only produces code for a couple of CPUs...)

[zapta]

I am using eclipse professionally on large software projects. When I say large I mean really large, not measly binaries with just a few tens of MBs, and it works just great. Same goes when I use it for small hobby LPCXpresso M0 hobby projects on a low end 11" Macbook Air.

Yep. YMMV. I've often found that people who use Eclipse on embedded projects think it works great because they don't have anything to compare it to.

The old people-that-disagree-with-me-must-be-ignorant.

[Sal Ammoniac]

The old people-that-disagree-with-me-must-be-ignorant.

More like "this TV is so old I no longer notice that grass looks orange when I watch football games".

[jaromir]

IMHO Microchip really shot themselves in the foot by making a proprietary GCC for their PIC32 microcontrollers because they will always be behind with the mainstream GCC development.

And that's why I'm using vanilla MIPS GCC for PIC32. I used also GCC from MPIDE. Both normally usable compilers.
MIPS is well established platform and GCC compiler for it has a long history.

[andyturk]

I have been trying DS-5 for a while.

How does the royal shiznit compare to the open source militia?

[bson]

IMHO Microchip really shot themselves in the foot by making a proprietary GCC for their PIC32 microcontrollers because they will always be behind with the mainstream GCC development. GCC for ARM (maintained by ARM!) is much more up to date and the latest upgrade I did resulted in a healthy improvement of code density.

...instead of making MIPS32/64 support first-tier in gcc to begin with.   

[bson]

For a hobbyist, the biggest Microchip shortcoming is the lack of good, cheap development hardware. The PICKit 3 is relatively cheap at $48, but it's not good (it's slowwwwwwww). The next step up the line is the ICD-3, which is about as fast as an ST-Link/V2, but it's $200.

I have both and don't see any speed difference; for small projects it's all dominated by MPLABX having to run its Java 200MB bloatware helpers.

[bson]

The old people-that-disagree-with-me-must-be-ignorant.

More like "this TV is so old I no longer notice that grass looks orange when I watch football games".

Or too old to have an app for that.  (Read: predates TVs with dual-core 1.5GHz Cortex-A's/MIPS64 with gigabytes or RAM and NAND flash, ethernet, wifi, and running embedded Linux systems that take hours to cross-compile.  And days if not weeks to get to properly build and DHCP boot with X509 certs and whatnot.  With video pipelines capable of 4k scaling and compositing...)

[Godzil]

It may takes a few hours, but clearly not day or weeks to build an embedded linux with all the thing you cited.

I may even takes less than one hour if it's done correctly.

[bson]

It may takes a few hours, but clearly not day or weeks to build an embedded linux with all the thing you cited.

I may even takes less than one hour if it's done correctly.

Yeah, but figuring out how to do it correctly can take that long.  Especially parts where you have to install keys in the chip for the boot loader to be able to boot even an unencrypted image in the first place.  I'm under NDA gag so can't name names (and shouldn't really mention this much either), but it's very easy to brick these devices if you're not careful.  The reference systems used for development are fairly expensive (five figures per unit) and in very sparse supply and/or long delivery times, so if you brick one it needs to go back to the chip maker.  The last time a junior engineer did this and we got it back it looked decidedly reflowed, so my guess is they swap out the main monolithic system SoC BGA.  (They also set it up for this engineer's keys while at it to save the risk of having to do it again.)

[Godzil]

It may takes a few hours, but clearly not day or weeks to build an embedded linux with all the thing you cited.

I may even takes less than one hour if it's done correctly.

Yeah, but figuring out how to do it correctly can take that long.  Especially parts where you have to install keys in the chip for the boot loader to be able to boot even an unencrypted image in the first place.  I'm under NDA gag so can't name names (and shouldn't really mention this much either), but it's very easy to brick these devices if you're not careful.  The reference systems used for development are fairly expensive (five figures per unit) and in very sparse supply and/or long delivery times, so if you brick one it needs to go back to the chip maker.  The last time a junior engineer did this and we got it back it looked decidedly reflowed, so my guess is they swap out the main monolithic system SoC BGA.  (They also set it up for this engineer's keys while at it to save the risk of having to do it again.)

Oh yes I completely understand that, it's not as critical as it was possible to recover, but on the OMAP3 line for exemple, booting from an SD or eMMC chip, a wrong step on the /boot partition and your device is basically bricked (and the OMAP3 bootrom is particularly picky on that partition.)
And yes, even complex ARM chip with encrypted boot sequence, just take any microcontroler with (e)Fuse with some that could lock the chip JTAG, if you burn it mistakely, and still need jtag, you chip is good for the trash..

[Sal Ammoniac]

For a hobbyist, the biggest Microchip shortcoming is the lack of good, cheap development hardware. The PICKit 3 is relatively cheap at $48, but it's not good (it's slowwwwwwww). The next step up the line is the ICD-3, which is about as fast as an ST-Link/V2, but it's $200.

I have both and don't see any speed difference; for small projects it's all dominated by MPLABX having to run its Java 200MB bloatware helpers.

Then count yourself as lucky. I see a huge difference speed-wise between the PICkit-3 and the ICD-3. The PICkit-3 is unusable for debugging on a PIC32 while an ICD-3 is reasonably responsive (although not as fast as an ST-LINK/V2 or Segger J-Link on an ARM using CrossWorks).

[Godzil]

By the way, is there anyone having an experience with the Rowley CrossConnect?

[Sal Ammoniac]

By the way, is there anyone having an experience with the Rowley CrossConnect?

I don't have personal experience with it, but as far as I know it's the only debugger currently capable of debugging both cores of an LPC43xx under CrossWorks.

[AndyC_772]

I've been using a CrossConnect with STM32 for the last couple of years.

It works fine, but so does an ST-LinkV2. There's really nothing to choose between them, other than about £300.