Inexpensive ARM Development Tools

[richardman]

Sal, ImageCraft's (my company) JumpStart for Cortex-M also starts at $99, and if you purchase the JumpStart MicroBox, it even comes with the ST-Nucleo, a shield with "everything but kitchen sink", and even a C e-book. The non-commercial use debugger is $50. No complicated setup. Not based on Eclipse, nor GCC. PM if interested.

[Sal Ammoniac]

Sal, ImageCraft's (my company) JumpStart for Cortex-M also starts at $99, and if you purchase the JumpStart MicroBox, it even comes with the ST-Nucleo, a shield with "everything but kitchen sink", and even a C e-book. The non-commercial use debugger is $50. No complicated setup. Not based on Eclipse, nor GCC. PM if interested.

Hmmm... Looks very interesting. Especially that it's not based on either Eclipse or GCC. One thing's a showstopper for me however--your website says the compiler only supports Cortex-M0 and M3 with M4 and M7 support coming. I switched from M3 to M4 a few years ago and don't want to go back. When is M4/M7 support expected to be ready?

Does the demo version only include the compiler, or does it also include CodeBlocks and the debugger?

[nctnico]

Just to clarify, I really like the look and feel of Eclipse. I like its window layout and I like its editor. I like just about everything about it except its performance. That's always the stumbling block for me. It just feels so sluggish and unresponsive after using something like CrossWorks.

On Windows or Linux? Eclipse tends to be rather slow on Windows. When using Eclipse on Linux I get sub-second compile times on my machine for reasonably sized projects including a USB device stack.

I've tried it on both Windows and Linux and, while it performs better on Linux than Windows, it's still quite slow compared to CrossWorks or EmBitz. Compile time is not the issue--the issue is downloading code to the micro and debugging it (particularly single-stepping).

I never use on-target debugging. I gave up on that decades ago because it is always clumsy and there are faster alternatives.

[Sal Ammoniac]

I never use on-target debugging. I gave up on that decades ago because it is always clumsy and there are faster alternatives.

What are these faster alternatives you speak of?

[zapta]

Apropos inexpensive ARM development tools, LPCXpresso is free for up to 256KB, runs on all three OSs, a single package install installs  the IDE + toolchain, it support hardware debuggers (including a ~$20 link II), has the familiar (at least to me) eclipse UI,  generates project makefiles that you can also use from command line, is under active development. It is also supported by mbed  which can export an entire project in a single lpcxpresso compatible .zip file.

I have used it for a year or so and it works just great. Most of the time I use it with the the NXP usb/virtual_disk bootloader (a standard USB cable and a file copy command) and use the hardware debugger only in special occasions.

[nctnico]

I never use on-target debugging. I gave up on that decades ago because it is always clumsy and there are faster alternatives.

What are these faster alternatives you speak of?

Debugging code on a PC first and then use it in the microcontroller. Eclipse + GCC is a good combo because they also support the PC platform + very fancy debugging. It helps a lot if you start an embedded project with code which works because it has been through a series of tests already. Furthermore I have a command line interpreter in all my products which collects status information and allows reading various parameters or just dumps the status every X seconds (which could be based on a logging level).

[theatrus]

I never use on-target debugging. I gave up on that decades ago because it is always clumsy and there are faster alternatives.

What are these faster alternatives you speak of?

Debugging code on a PC first and then use it in the microcontroller. Eclipse + GCC is a good combo because they also support the PC platform + very fancy debugging. It helps a lot if you start an embedded project with code which works because it has been through a series of tests already. Furthermore I have a command line interpreter in all my products which collects status information and allows reading various parameters or just dumps the status every X seconds (which could be based on a logging level).

I always unit test all my algorithmic and non-driver code on a PC first.

It really helps to have the same compiler on both, and is a huge advantage for automated builds and regression suites as well.

As MCU complexity grows from the few K of code job, adopting practices from large scale software starts paying off.

[richardman]

Hmmm... Looks very interesting. Especially that it's not based on either Eclipse or GCC. One thing's a showstopper for me however--your website says the compiler only supports Cortex-M0 and M3 with M4 and M7 support coming. I switched from M3 to M4 a few years ago and don't want to go back. When is M4/M7 support expected to be ready?

Does the demo version only include the compiler, or does it also include CodeBlocks and the debugger?

Hi Sal, we are finishing up the M4 FP instructions support, but you can use it already, as a fast M3. In fact, one reason we are late with the FP instructions is because we are working on a couple M4 based products, which hopefully will be disclosed within 2 weeks. We have our JumpStart API  working great for M0 and M4 now. Check out the JumpStart API doc our our site, it's far easier to use than the ST StdPeriphLib or HAL, and will continually be extended (see the abovementioned "new products").

Indeed, we only have a couple M0 Nucleo left. After thay are gone, we will switch to M4 Nucleo as part of the JumpStart MicroBox kit.

The "compiler" includes the IDE and compiler, and the debugger. For purchase, you pay $99 for the non-commercial sue license of the compiler+IDE, and $50 for the debugger license. The debugger is of course optional so $99 will get you going.

The debugger is our own also, and works great with ST-LINK and Segger Jlink.

[bson]

If you're rolling your own RTOS and writing your own startup routines, you ought to be able to get by with a completely open source toolchain like GCC ARM Embedded.

There's just something incredibly simple and liberating just using emacs, Makefiles, etags, and M-x gdb.  It's so much easier to just type a cast or array index like ((struct _foo*)foo)[bar*7] than try to figure out how to make a GUI IDE do the same.  Or make a breakpoint conditional on having been called a certain number of times, or such.  VS is a little easier than Eclipse based ones, but in general what should take ten seconds to type becomes along tedious hunt.

[miguelvp]

I haven't tried this yet and not sure if it fully applies to MCUs

But Visual Studio has a GDB Debugger extension
https://www.eevblog.com/forum/microcontrollers/whatever-happened-to-coocox/msg802965/#msg802965

Link of the announcement in the post. An excerpt of the announcement states:

Earlier this year I wrote a post on how you could debug C++ code on Linux from Visual Studio. It was a bit cumbersome, but it was doable. Today we are releasing the Visual Studio GDB Debugger extension preview. This will enable debugging remote Linux targets including IoT devices.

Edit: From the comments, just this pass November 19th

Great extension!

Could you please extend this to MCUs such as MSP430, STM32F4 and support for C and you'll have an awesome IDE.

I can't wait to start using VS to debug my microcontroller and .NETMF projects.

Good job.

working on it! :-)

Myself I use Creator but that's specific to Cypress PSoC family.
No code limits and free.

[Sal Ammoniac]

There's just something incredibly simple and liberating just using emacs, Makefiles, etags, and M-x gdb. 

It's probably simple and liberating to build your own house from scratch too, but that's just not for me either.

[theatrus]

There's just something incredibly simple and liberating just using emacs, Makefiles, etags, and M-x gdb. 

It's probably simple and liberating to build your own house from scratch too, but that's just not for me either.

To be honest, the GNU tool suite is all integrated and just as easy to learn 

[westfw]

Don't forget libc, which is not strictly part of gcc itself, and you probably don't want to do without.
A good, non-bloated, bare-metal friendly, version of libc is pretty rare :-(  (a lot of ARM packages ship with "newlib" which is desktop-derived and will do things like pull in a bunch of filesystem code just to support printf()  "newlib nano" is better, I think.

the current arm gcc softwarefloating point libraries for M0 are also not optimized, making them much bigger and slower than the M3/M4 SFP libraries.

[stmdude]

There's just something incredibly simple and liberating just using emacs, Makefiles, etags, and M-x gdb. 

It's probably simple and liberating to build your own house from scratch too, but that's just not for me either.

To be honest, the GNU tool suite is all integrated and just as easy to learn 

GCC + Whatever you're comfortable with, all the way.  This way, I have the same development environment for STM32 (F0->F7), Nordic nRF51, TI CCxxxx, Ralink MIPS, ESP8266, etc..

No commercial IDE even comes close to offering something similar.

[TheDirty]

Thanks for this, and interesting conversation.  I also use Crossworks, but am open to find anything that's free and comparable.

Debugging/programming speed is pretty crucial to me as a hobbyist.  Different development process definitely.  I'm not making commercial products; I'm just playing around.  Most of my projects I can see the results of immediately, so I simply program run/debug, edit, run/debug, and repeat until I have the results I want.  Not coordinating with anyone and no quality process to work with.  Most of the debug issues I have is the sensors/lcd's, other modules I'm communicating with don't work the way I expect so edit, run, repeat and put on the scope or logic probe if it's really tricky.

The below project I pieced together this weekend when this LCD just came in.  So I plug everything together load up the programmer and start writing code for one piece at a time.  Again, program, run, see the results, repeat...

[Lukas]

Don't forget libc, which is not strictly part of gcc itself, and you probably don't want to do without.
A good, non-bloated, bare-metal friendly, version of libc is pretty rare :-(  (a lot of ARM packages ship with "newlib" which is desktop-derived and will do things like pull in a bunch of filesystem code just to support printf()  "newlib nano" is better, I think.

There's no filesystem code. I guess you're referring to the _write, etc. stubs. By implementing the _write stub, you can make printf print to UART, display, you name it.

Newlib also has the advantage that it's portable between many MCUs: https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libc/machine;h=cd58736e22539f182caa7cd1ad32bceff8f66cf5;hb=HEAD

Regarding the 'building your own house; stuff. It's not a fault of GCC, make or the editor. It's the fault of the manufacturer not to provide a simple non-bloated Makefile-based example project.

[Brutte]

A good, non-bloated, bare-metal friendly, version of libc is pretty rare

Besides, does it matter how bloated libc is when it is not used in release firmware? Just buy the biggest package, biggest flash size uC, do your development job and then strip everything wasteful for release with cheapest uC on the market.
The newlib-nano is 9k without floats, with full semihosting support. That includes sbrk. If you want something faster than semihosting, you should either redirect write to USB Hi-Speed pipe or wire up ETM pins to a tracing dongle.

[nctnico]

A good, non-bloated, bare-metal friendly, version of libc is pretty rare

You don't have to use the compiler's provided C library. I have been using the micro C library which came with an ancient version of MSPGCC (MSP430 GCC) for over a decade in my ARM projects. And if printf becomes too large you can always write a micro-printf which is a much better method to save space than trying to re-invent the wheel by having your own string/number output functions.

[theatrus]

GCC also has good support for full LTO now, which is the ideal for cross translation unit in lining and removal of dead code. 

[Sal Ammoniac]

GCC is so 1980s. Clang/LLDB is the way to go today.

[theatrus]

GCC is so 1980s. Clang/LLDB is the way to go today.

I can totally agree with this, except for the CM targets not being up to snuff in LLVM quite yet.

[photon]

GCC is so 1980s. Clang/LLDB is the way to go today.

I can totally agree with this, except for the CM targets not being up to snuff in LLVM quite yet.

Please tell me why as I'm curious and don't know much about Clang.

[Sal Ammoniac]

Eclipse Performance...

Are there any Java gurus around here who can explain why Eclipse performs as sluggishly as it does? I'm using the standard Java SE8 download from Oracle--is there another Java VM with better performance that would improve Eclipse performance? My development machine is pretty capable--it's a Core i7 Haswell-E running at 4 GHz with 32 GB of RAM and an SSD as its C: drive, so I doubt that's the cause.

As a point of reference, I also use Microchip's MPLAB X to do PIC32 development. MPLAB X is based on Netbeans, which is also written in Java. I find MPLAB X performance to be much better than Eclipse on the same machine. I wonder why this is?

[nctnico]

Play a bit with the appearance settings. Some themes are significantly slower than the other.

[theatrus]

GCC is so 1980s. Clang/LLDB is the way to go today.

I can totally agree with this, except for the CM targets not being up to snuff in LLVM quite yet.

Please tell me why as I'm curious and don't know much about Clang.

For a long time, GCC (and EGCS and back to GCC) was the only serious open source compiler on the block (and even commonly better than the commercial variants, including ICC and MSVC - blows were traded). However, GCC actively fought several key measures such as modularization of the compiler ("plugins") which was seen as a threat to the pure GPL version.

Apple needed a compiler which they could integrate into their developer suite after dragging along with GCC and even Metroworks for years, and found some hope in a project called LLVM. LLVM was a non-GPL, open source compiler-framework of sorts. After pouring years of R&D into it, LLVM and the new Clang matured in new ways that the more conservative GCC never bothered to adopt. Clang had much better programmer ergonomics (compare a clang C++ template error to a GCC one at the time frame, or even C missing close block syntax errors), and more importantly was very modular and pluggable as LLVM had been grown as a framework instead of a monolith. This allowed people to create a very large number of tools re-using parts of the Clang+LLVM pipeline, such as top end semantic analyzers, refactoring tools, source to source translators, and on the backend new and unique optimizer passes.

In short, LLVM had a lot of very smart people on it providing a ton of competition to GCC, and GCC is playing catch-up now. Clang+LLVM+LLDB are projects which are mostly programmer-compatible with GCC+GDB, but provide a "fresh perspective" and are as good or better than GCC, plus substantially easier to integrate into an IDE or generate new tooling around.