Author
Topic: Inexpensive ARM Development Tools (Read 47268 times)

As a hobbyist, I don't have the budget for high-end ARM development tools like IAR and Keil. We use both of these tools at work, but I just can't justify paying $3-5K for a development tool for hobby use. I'd rather spend the money on a scope or other test equipment.

I'm always on the lookout for a better set of tools for doing development, and occasionally take a look at new tools, or older tools that I haven't looked at in a while. This week, I took time out from coding to look at three tools ranging from free to USD$89.

The first up is VisualGDB. This isn't an IDE in itself, but rather an add-on to Microsoft Visual Studio that supports compiling and debugging code for non-Windows targets. There are several levels available for developing Android, Linux, and embedded applications ranging from $89 to $349. I sprang for the $89 embedded version since I mainly work on embedded code for ARM Cortex-M MCUs. What really makes this an inexpensive proposition is that it works with Visual Studio Community Edition, which is a free download.

Downloading and installing VisualGDB is straightforward. I already had VS Community Edition 2015 installed, which saved some time, but when I first tried to create a project in VS using the VisualGDB plug-in, it needed to download a C++ package from Microsoft, which took about 20 minutes on my DSL connection. Once that was done, I was able to create a project targeting the STM32F407 on one of my development boards. This is where I started to run into issues. I'm not like the majority of hobbyist embedded developers--I don't use vendor peripheral libraries or frameworks, preferring to write my own code from scratch. All I look for in a development environment is a simple startup file that copies initialized data to SRAM, zeros the BSS, and jumps to main(). I do everything myself, including setting up the clocks and PLLs, initializing device drivers (which I write myself), etc. VisualGDB doesn't have the option to create a minimal embedded project via its project creation wizard. It gives you the option to create an LED blink project using a HAL, FreeRTOS, or a legacy peripheral library. I had to let it create one of these, and then go in and manually delete all of the unnecessary crap it pulled into my project.

Once I jumped through these loops, I was able to build my project and try downloading it to my board and running it. I use an ST/Link-v2, and VisualGDB supports this using a third-party tool called Texane/stlink. This tool works well enough, although it's somewhat chatty, informing me that everything is "jolly good" after it downloads an image to the board. I'm still trying to get my code to run under VisualGDB. There are some weird issues that are causing it to generate hard faults when I execute it. I haven't had the time to track this down yet, so I'm still somewhat in the dark about how well debugging an ARM board under Visual Studio works. Since it is Visual Studio, most of the commands will be familiar to anyone who has used VS to write Windows apps. My score for VisualGDB is a C+, but this may improve once I figure out why my code is faulting.

The next tool I tried was Atollic TrueStudio. Sometime late last year Atollic removed the code size limits from the free version and moved to a subscription model for the paid version. In addition, the free edition does not require any kind of registration, which is how it should be and Atollic deserves kudos for this. The paid version offers additional features, such as MISRA checking, interrupt tracing, profiling, and other things that the average hobbyist probably won't miss.

TrueStudio is your basic bog-standard Eclipse IDE, with all of the pluses and minuses that go along with it. Anyone who has used Eclipse in another guise will immediately feel familiar with it and shouldn't have any problems getting up to speed. I installed it and built the same application (home-grown RTOS + peripheral drivers + app code) that I used for the VisualGDB evaluation I described earlier in this post. I had no problems building the code and downloading it to the board via the ST/Link-v2, and the application ran first time with no changes other than one minor change due to the way the header files provided with TrueStudio define one of the GPIO registers.

As soon as I started to try out the debugger by downloading my code and single-stepping it, I was immediately reminded that this product is based on Eclipse. The code download and each step through the code took noticeably longer than my current gold standard for inexpensive IDEs (Rowley CrossWorks). If I was doing only occasional development work, the fact that TrueStudio is free and doesn't require registration would make it nearly ideal. But I don't think I could live with the slow downloads and slow single stepping. It'd drive me nuts very quickly. Overall score: B-, primarily due to the sluggishness of downloading and stepping code.

The last tool I tried was EmBitz. Some of you may be familiar with its predecessor: Em::Blocks. Em::Blocks is no longer available and EmBitz is its replacement. It's completely free and licensed under the GPL. The download is reasonably small (as far as IDEs go) and includes the ubiquitous GCC ARM compiler suite. It supports most of the ARM variants used by hobbyists, including NXP, ST, Atmel, Energy Micro, and Nordic. It also supports 8, 16, and 32-bit PICs and the TI MSP430.

Creating a new project and importing my code went very fast, and I didn't need to jump through any loops to get it to compile like I did on VisualGDB. Once again, I used the same code and same board as before, but this time the download went much, much faster than it did with TrueStudio. EmBitz is written in C++, not Java or .Net, and it shows. Single-stepping code happens as fast as I can click the mouse or mash on the keyboard. No lag at all, which was very refreshing after suffering through TrueStudio's slowness. The IDE itself, however, looks somewhat dated compared to TrueStudio or Visual Studio. For instance, debug windows such as CPU Registers, Breakpoints, and Watch Windows are floating and can't be docked. I haven't seen this in an IDE in over a decade. This may be a matter of taste, but like Han Solo said about the Millennium Falcon, "She may not look like much, but she's got it where it counts, kid." I'll take a fast, robust IDE any day over a gussied up prom queen. After all, you can put lipstick on a pig, but it's still a pig. Overall score: A- for being free and for its performance, with a few demerits for its dated look.

That's it, folks. I was really disappointed with how difficult it was to get my code going with VisualGDB, although I really need to put more time into it. It may yet be a reasonable environment once I work through all its quirks. I wasn't really surprised by TrueStudio's performance--I've used several other Eclipse-based IDEs in the past and they all felt like I was wading through a pool of molasses. EmBitz was the real eye-opener. It was by far the easiest to get my code up and running under and its performance was head and shoulders above the other two. It won't replace my current IDE, Rowley CrossWorks, but it's certainly a viable alternative.

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.

I use Rowley CrossWorks, and I'm satisfied with it. I occasionally look to see if anything better comes along. I don't want to bother taking the time to put together something from open source. Been there, done that, and once was enough.

And only two families. Basically ST did a promotion cross deal with ARM.

I'm generally only upset when vendors don't ship ld linker files and assumes everyone must use IAR or Keil. The actual IDE in both of those is honestly not competitive, and the compilers are quirky on things gcc and clang are both much better at. I do *use* Keil, but mostly grudgingly because vendors only made one "easy" path.

(Really, building a native AOT compiler on anything but LLVM these days is basically relegating you to obsolescence)

I use Rowley CrossWorks, and I'm satisfied with it. I occasionally look to see if anything better comes along. I don't want to bother taking the time to put together something from open source. Been there, done that, and once was enough.

Me too. For personal, non-commercial use it's just $150, and doesn't get nearly the forum coverage that it should, IMHO.

I'm generally only upset when vendors don't ship ld linker files and assumes everyone must use IAR or Keil. The actual IDE in both of those is honestly not competitive, and the compilers are quirky on things gcc and clang are both much better at. I do *use* Keil, but mostly grudgingly because vendors only made one "easy" path.

Is it the silicon vendor's responsibility to produce those? I was thinking that compiler vendors made their own suited for their toolchain?

I'm using Eclipse for everything that smells like sourcecode; Eclipse is also very good at helping to keep an overview of a complex project which keeps my productivity high. In case of microcontroller projects: setting up a new project to compile with GCC and the LD files is peanuts once you have done that a couple of times. Every now and then I need specialised LD files too so having that knowledge pays off quickly.

Logged

There are small lies, big lies and then there is what is on the screen of your oscilloscope.

That's it, folks. I was really disappointed with how difficult it was to get my code going with VisualGDB, although I really need to put more time into it. It may yet be a reasonable environment once I work through all its quirks. I wasn't really surprised by TrueStudio's performance--I've used several other Eclipse-based IDEs in the past and they all felt like I was wading through a pool of molasses. EmBitz was the real eye-opener. It was by far the easiest to get my code up and running under and its performance was head and shoulders above the other two. It won't replace my current IDE, Rowley CrossWorks, but it's certainly a viable alternative.

Well as mentioned in your previous thread qoute: neat, small and tidy, bare metal with STD lib if you like. Now send Gerhard a coin or two, he needs it!

Embitz is all about being small and productive rather then a big bloathed pool of molass'ed bling!

I stay with keil / iar, and occasionally coide, because they just work. Sure, the ides don't make coffee for me, or wow me with fancy features but on the only thing I desire out of them - get the shit done - they are fully capable of doing it, day in and day out.

Or does Atolllic = Eclipse + GCC + a great deal of time consuming, error prone setup and configuration already done?

I don't see how much error prone configuration needs to be done to get a project going in Eclipse. Select the embedded GCC compiler, set the include path, library path and setup the LD and you are ready to go. Most can be copied from an existing/previous project.

Logged

There are small lies, big lies and then there is what is on the screen of your oscilloscope.

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.

For anyone who hasn't tried CrossWorks, I recommend they do. It's just so much faster at downloading and debugging code compared to anything Eclipse-based that it's just rediculous. Sure, it may not have the fancy editor Eclipse has, but it has it where it counts: performance. And I'd also place CrossWorks in that category of tool that "just works".

Overall score: B-, primarily due to the sluggishness of downloading and (...)

You can try my SplitCode.It replaces a standard makefile and results in a partitioned binary where frequently edited source file output is placed in one part of memory and things you have not edited recently (like OS, libs, peripheral driver etc) sit in the other part of the memory. This way only the tiny memory part (the one that results from recent editing) needs to be uploaded. The tiny upload size and time does not depend on the size of final application - even the 1MB app update takes 3-4 seconds.

The project is not complete, just a proof of concept and of what is possible.

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.

Logged

There are small lies, big lies and then there is what is on the screen of your oscilloscope.

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).

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).

If you're using OpenOCD that could be the reason - I prefer using the Segger tools directly.

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).

If you're using OpenOCD that could be the reason - I prefer using the Segger tools directly.

I don't use OpenOCD. I either use a Segger J-Link (a real one, not a counterfeit) for NXP ARMs or an ST/Link-V2 for STM32s.