Inexpensive ARM Development Tools

[Godzil]

CrossConnect cost only $150 when buying a new license ^^ (Or you can say that by buying the CrossConnect you also get a non commercial licence of CrossWorks )

[sca]

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

Haven't compared for some time, but I found a Cross Connect substantially quicker on largish downloads than a J link using standard JTAG on LPC2k devices.

Not noticed much difference using SWD on STM32.

sca

[VEGETA]

So what is the industry standard IDE for ARM MCUs today? I mean, what the professionals use for designing products.

Keil and IAR. Both of these are in the USD$4-5K range, however, so they are not used much by hobbyists unless the code size limitation imposed by the free versions isn't an issue.

So when I want a free tool to begin learning ARM in order to get into it to work in that field in the future... what is the suitable IDE? what is the route to be taken?

[AndyC_772]

Have a look at Atollic True Studio; I believe the code size limit on the free version has been recently removed.

[Godzil]

Rowley CrossWorks is also an IDE to be evaluated, the "free" version is for non commercial and size limited, but that give a really good view of what the IDE is capable of (it clearly inspired from VisualStudio, and it's done quite correctly) and the non commercial license is really cheap ($150) even the commercial one is cheap ($1500) when you compare with other commercial solutions.

[bson]

But then you want to reuse your code on an MSP430 and will end up paying another $1500.

[Sal Ammoniac]

But then you want to reuse your code on an MSP430 and will end up paying another $1500.

For a commercial user $1500 is a pittance. Not even worth discussing.

[westfw]

For a commercial user $1500 is a pittance.

It exceeds the limits for discretionary spending, therefore requiring approval (possibly through several layers of management), careful accounting of depreciation, and hopefully prior inclusion in this years budget.  True, it is dwarfed by the cost of a programmer, and if it's known ahead of time to be required for a product design, it shouldn't be a significant part of the overall budget, but "pittance" is a bit of an understatement.  (I spent about $1200 on a computer for work once.   The CFO was NOT HAPPY with me.)
(and this gets even more complicated if you're a moderately large company, and have to start worrying about $1500 per seat instead of just $1500.  Or a license complaince scheme that may or may not be compatible with your infrastructure or culture.)

I had this epiphany recently.  A professional software or microcontroller developer is essentially indistinguishable from a hobbyist when presented with a brand new chip architecture.  This hypothetical time period where your 6-figure-salaried expert gets to order half-a-dozen different "eval boards", each with their own development environment and $1500 price tag, so they spend a couple months figuring out which one is going to "best fit" the project?  It doesn't usually exist.  Chip selection is more likely to be made based on "prior experience" (corporate or individual.)  So a manufacturer needs to get a $30 eval board with free development tools to the people who might use them well before product development starts.  So that they can buy it from petty cash, or with their own funds, and when the NEXT product cycle comes along they might think "I was playing with X using the Y IDE and it was pretty neat; add it to the list of "possibles.""

[AndyC_772]

I'd go with 'irrelevant' rather than 'pittance'.

When was the last time you ported a project from an ARM CPU to an MSP430?

How, if at all, did the possible future need to port to MSP430 affect your choice of ARM tools?

[VEGETA]

I'd go with 'irrelevant' rather than 'pittance'.

When was the last time you ported a project from an ARM CPU to an MSP430?

How, if at all, did the possible future need to port to MSP430 affect your choice of ARM tools?

Using different IDEs (and compilers) will result in a different context.. like porta.bit0 vs porta_bit0 or anything similar (you get the idea  ). How is this solved? If I used GCC with Eclipse, it will be the same context so I won't need to do "porting"?

This is one of the reason one is confused about when dealing with ARM-MCUs. However, MPLab X + XC8 is always the standard with PICs except for those who use other compilers (which they need to deal with it).

[dannyf]

"Using different IDEs (and compilers) will result in a different context"

The compilers (and associated headers) may be the root cause of that.

[AndyC_772]

Anything involving 'port A, bit 0' will be completely hardware specific anyway, and would need changing to target a new board with a new CPU regardless of the IDE.

[nctnico]

Anything involving 'port A, bit 0' will be completely hardware specific anyway, and would need changing to target a new board with a new CPU regardless of the IDE.

First of all that kind of code is 0.01% of the total firmware. Secondly it is a good idea to wrap settings bits in macros (like I do) so porting a piece of code (even if it is bitbanging I2C) is easy because only the macros need to be changed.

[Godzil]

First of all that kind of code is 0.01% of the total firmware. Secondly it is a good idea to wrap settings bits in macros (like I do) so porting a piece of code (even if it is bitbanging I2C) is easy because only the macros need to be changed.

0.1%? That's strictly depends on your code, and would not assume that for all possible project. And even in C code is generally quite difficult to port from one microcontroller to another, and for various reason, the hardware could behave really differently, does not have the same memory constraint etc..

[coppice]

And even in C code is generally quite difficult to port from one microcontroller to another, and for various reason, the hardware could behave really differently, does not have the same memory constraint etc..

Code interacting with peripherals obviously takes serious effort to port. If the rest of your C code is hard you must be doing something wrong. Even when you need to deal with the unpleasantness of something like an 8051 core, and a mass of variables with poorly defined word lengths, it shouldn't be  that hard.

[nctnico]

And even in C code is generally quite difficult to port from one microcontroller to another, and for various reason, the hardware could behave really differently, does not have the same memory constraint etc..

Code interacting with peripherals obviously takes serious effort to port. If the rest of your C code is hard you must be doing something wrong. Even when you need to deal with the unpleasantness of something like an 8051 core, and a mass of variables with poorly defined word lengths, it shouldn't be  that hard.

Actually it isn't that hard. I'm still using the UART interrupt routines/buffering/API I developed on the 8051 initially. Since then it has been ported to many other microcontrollers. UARTs, timers, SPI, I2C, etc interfaces all do the same function no matter what microcontroller they are in so porting their control software isn't that hard either.

[VEGETA]

"Using different IDEs (and compilers) will result in a different context"

The compilers (and associated headers) may be the root cause of that.

Well, I meant the exact same microcontroller but with different compiler... like PICC vs XC8 for PIC MCUs. Is that the case for ARM MCUs too?

when you develop a project using an ARM MCU like Renesas or STM32, do you _always_ use a dev board then use the specific MCU with your own board? or do you put the MCU itself on a breadboard (I know you need to put it on a PCB to do that) and start programming it directly? I still find getting started in ARM foggy xD.

Anyway, maybe you missed Mikro C PRO for ARM (http://www.mikroe.com/mikroc/arm/ide/). It is 300$ and full-featured. Did anyone use it? I really don't aid using a third-party tool for these stuff.. especially that you will be forced to use their own debugger rather than a normal one.

[Sal Ammoniac]

I had this epiphany recently.  A professional software or microcontroller developer is essentially indistinguishable from a hobbyist when presented with a brand new chip architecture.  This hypothetical time period where your 6-figure-salaried expert gets to order half-a-dozen different "eval boards", each with their own development environment and $1500 price tag,

Professional users most likely are already using Keil or IAR and these tools support pretty much all of the ARM variants on the market, so there's no $1500 cost to evaluate each chip vendor's parts. The most expensive ARM development board I've seen is around $300, and that's the exception rather than the rule. Most simple boards are less than $100, sometimes much lower.

When we do evals here before deciding on a particular ARM MCU, we start by reviewing data sheets and can rule out the majority of the contenders on that basis alone. Once we've whittled the list down to the top prospects, we only need to buy 2-3 eval boards to test at that level.

I stand by my opinion that $1500 for a development license is a pittance. I don't know where you live, but in my area the burdened cost of an embedded developer is ~$150/hr. That's $6000 a week, or 4x the cost of a $1500 license. One can easy burn through several times the cost of a license arguing the details in a meeting. If your CFO is making your engineers jump through hoops justifying expenses such as this, then he's penny wise and pound foolish.

[nctnico]

And yet I have never worked for a company (several with multi-million turnovers) where we (the firmware engineers) used paid compilers. During the past 25 years I have used Keil's uVision, IARs workbench, Analog Devices dev.... yadda yadda, Freescale's Codewarrior, etc only in very rare occassions where an existing project needed some quick hacking. The reason: all those IDEs suck big time and offer no increase in productivity. Notepads with a compile button stuck on them. Nice to get blinky projects going quickly but for real programming work? No thanks! Also: if a manufacturer wants me to use their chips they should provide a good compiler for free. Otherwise I just say NEXT! Some salesmen still hate me and co-workers for that. Take that $1500 figure and divide that by a production run of 1000 pieces. Suddenly the price of the BOM goes up by $1.50. Or that $1500 can also go towards buying a piece of test equipment or pay someone's salary for a week or more. Multiply that $1500 by several seats and suddenly it makes sense to standarise development around a fixed set of tools and look for solutions which fit into that model seamlessly. It is easy to say the $1500 gets dwarfed by other expenses but that still doesn't mean it is money well spend. Usually it isn't when it comes to microcontroller IDEs because they are not the core business of compiler makers.

[Sal Ammoniac]

And yet I have never worked for a company (several with multi-million turnovers) where we (the firmware engineers) used paid compilers. During the past 25 years I have used Keil's uVision, IARs workbench, Analog Devices dev.... yadda yadda, Freescale's Codewarrior, etc only in very rare occassions where an existing project needed some quick hacking. The reason: all those IDEs suck big time and offer no increase in productivity. Notepads with a compile button stuck on them. Nice to get blinky projects going quickly but for real programming work? No thanks!

My experience is opposite yours. I've worked in companies that exclusively used tools like Kiel and IAR because these tools come with support and a phone number to call. We've always gotten excellent support from these companies that helps us quickly get past issues that would otherwise take lots of time to solve. What happens if you have an issue with GCC? Who are you going to call? Richard Stallman?

I personally have found IDEs very useful and would never go back to the days of using a compiler with Make, Emacs, and GDB. Sure, all IDEs suck in some way (some more than others), but overall I've found the productivity to be worth it.

[Godzil]

Using the price of a licence to the BOM cost of a product is silly. You device will not be the only one you'll make using that software.this is clearly not something which is related to the BOM cost of a product...

And even $1.5 unless you make <$10 product is just.. nothing..
I really hate people that don't want to reduce their margin for even a penny just to add an important feature.. Been there in the past where they didn't wanted to add a gas gauge to track battery charge, the result is a device that have an absolutely shitty battery level indicator, because as we all know, voltage is NOT an accurate information.

[VEGETA]

I personally have found IDEs very useful and would never go back to the days of using a compiler with Make, Emacs, and GDB. Sure, all IDEs suck in some way (some more than others), but overall I've found the productivity to be worth it.

so you suggest/recommend any beginner in ARM MCUs to just go with Keil from the start and build his experience using it?

For me, I consider buying an STM32 discovery board to learn ARM MCUs, there is an IDE by ST that is good according to what I read. What to do?

[Godzil]

You could also go to the TI launchpad, especially the Tiva/Stellaris one, you can either use the Energia environment which is basically the same as the arduino, the  IDE provided by TI or any other tools. I do like the LaunchPad board to be honest, and there are a lot of variants like one with Ethernet

And don't be fooled by the arduino environment, as its in fact C/C++ programming

[mtdoc]

I personally have found IDEs very useful and would never go back to the days of using a compiler with Make, Emacs, and GDB. Sure, all IDEs suck in some way (some more than others), but overall I've found the productivity to be worth it.

so you suggest/recommend any beginner in ARM MCUs to just go with Keil from the start and build his experience using it?

For me, I consider buying an STM32 discovery board to learn ARM MCUs, there is an IDE by ST that is good according to what I read. What to do?

Take this free course.  If you're an experieinced coder it will start out a little slow but it quickly picks up. It will teach you ARM. It uses the TI Tiva C launchpad and Keil. 

[Godzil]

I personally have found IDEs very useful and would never go back to the days of using a compiler with Make, Emacs, and GDB. Sure, all IDEs suck in some way (some more than others), but overall I've found the productivity to be worth it.

so you suggest/recommend any beginner in ARM MCUs to just go with Keil from the start and build his experience using it?

For me, I consider buying an STM32 discovery board to learn ARM MCUs, there is an IDE by ST that is good according to what I read. What to do?

Take this free course.  If you're an experieinced coder it will start out a little slow but it quickly picks up. It will teach you ARM. It uses the TI Tiva C launchpad and Keil.

Oh the MOOC from UT, I enjoyed it a lot, was really fun, even if not really needed in my case..