contemplating a arm dev board.

[blewisjr]

Like the title says.  I have been hearing great things about the cortex m micros.  Some people say they are great for any project large or small.  How easy would it be to setup a Linux toolchain for one of these boards a la gcc, gdb, openOCD.  I am talking bare metal dev as in no is maybe just a boot loader to get the code on there as I don't know of anything like the pick it for arm.  Also is the general consensus these are the uC future or are they just overkill.

[c4757p]

Also is the general consensus these are the uC future or are they just overkill.

People saying "X is the Y future" are seldom correct, and more seldom for the right reasons. At current rates 8-bit MCUs aren't going anywhere any time soon; by the time they finally disappear ARM will too.

Just like everything, they have appropriate and inappropriate applications. I think they're a good addition to your toolbox, personally.

[blewisjr]

I agree. I have 8bit pics and avrs.  I like both for different reasons.  I would like to tinker a bit with the arm ucs but finding a devboard that will work with my is is another story.  I also find it difficult to justify with the scale of some of the project I want to do just seems overkill.

[andersm]

Many Linux distros already have the tools in their package repository, so check there first. You can get the chip-specific headers and libraries from the vendor (though some still only distribute these as Windows installers.)

[blewisjr]

No issue with building the tools if I had too the header installers would be.

[andyturk]

Here's a toolchain you can try: https://launchpad.net/gcc-arm-embedded

The compiler/linker stuff is usually pretty easy to get going. It takes a little more time to get your debug/programming tools set up (e.g., openocd) since there are vendor specific hardware issues. I usually recommend one of STM's Discovery boards because they're cheap, and they have a built-in debugger interface that works well with openocd.

[nctnico]

Like the title says.  I have been hearing great things about the cortex m micros.  Some people say they are great for any project large or small.  How easy would it be to setup a Linux toolchain for one of these boards a la gcc, gdb, openOCD.  I am talking bare metal dev as in no is maybe just a boot loader to get the code on there as I don't know of anything like the pick it for arm.  Also is the general consensus these are the uC future or are they just overkill.

Nowadays I'd just go for ARM. They are available in many speed and low power options for prices that make it hard to justify using an 8 bit controller. You could say its overkill but having more processing horse power allows to do more in software and less in hardware. Besides who is still using an old fashioned screw driver instead of a cordless drill?

[blewisjr]

Depends on the job NC sometimes a cordless drill is overkill . I only have $170 ish invested between pic and avr.  If it is indeed true with what you say it is not killer for me to invest time in arm.  The issue is the justification that it is worth the effort and little bit of cash.  Maybe some examples of uses and advantages over various scales will help.  Not to mention dev board suggestions.

edit:

maybe this will help some project I want to do.
alarm clock
waveform generator
8bit game handheld

of these three a majority can be done with a 8bit micro.

my issue is choosing a chip to learn well.  I bought pic and avr because of this.  Turns out I like both for different reasons so when I go to start a project I find it hard to choose and change back and forth and get nowhere.  Ugh.

[c4757p]

Besides who is still using an old fashioned screw driver instead of a cordless drill?

That depends totally on what you're doing! You wouldn't build a house with a screwdriver, but would you disassemble delicate electronics with a cordless drill?

ARM vs 8-bit is the same thing IMHO.

[Short Circuit]

...
People saying "X is the Y future" are seldom correct, and more seldom for the right reasons. At current rates 8-bit MCUs aren't going anywhere any time soon; by the time they finally disappear ARM will too.
...

8-bit will stay for quite a while indeed, but many new products are designed with 32-bit.
Take a look at this recent market research; 8-bit is fairly steady over the past few years, while 32-bit is growing.
I'd say this implies 8-bit only goes into existing products and new products are more and more based on 32-bit.
http://www.icinsights.com/news/bulletins/MCU-Market-On-Migration-Path-To-32bit-And-ARMbased-Devices/

...  I would like to tinker a bit with the arm ucs but finding a devboard that will work with my is is another story.  I also find it difficult to justify with the scale of some of the project I want to do just seems overkill.

Personally I favor the STM32 families from ST, for which very low cost dev boards are available, Google "STM32 DISCOVERY".

Overkill is relative. These Cortex MCUs are so friggin versatile in periperals and such that 90% of their features remain unused in 90% of projects 

[c4757p]

Overkill is relative. These Cortex MCUs are so friggin versatile in periperals and such that 90% of their features remain unused in 90% of projects 

I'd argue that with a microcontroller or PLD, it's only overkill if there's an advantage to using a smaller one. It's not like some factory worker had to hand-craft the PWM module in my microcontroller - if it's the best option for some other reason, I don't care if you're not using a single one of its million really cool peripheral features.

[c4757p]

Take a look at this recent market research; 8-bit is fairly steady over the past few years, while 32-bit is growing.
I'd say this implies 8-bit only goes into existing products and new products are more and more based on 32-bit.

1) They're quite new still - there are of course many engineers choosing them because they are new, at least in products that aren't supposed to have a very long lifespan. I'm sure that will die down.
2) The number of units shipped is still increasing for all types.
3) They have lumped 4-bit and 8-bit together. 8-bit is not dying but I'm willing to bet 4-bit is. That will skew the trends, of course.

[blewisjr]

I hear good things about both the atm discovery and to launch pad but again both do not seem to have good Linux support through gcc everything I googled mentioned the ccs compiler which is not free and also all information I found was a year old or more filled with hacks and workarounds.

seems the situation is just like avr on linux poor chip programming and hardware debug support.

[andersm]

GCC supports cores, not individual chips. For Cortex-M4 support you need GCC 4.6 or newer. Cortex-M3 support was added in 4.3.

[blewisjr]

Oh I am sure gcc 4.8 arm targeted will compile successfully for every cortex m chip out assuming you do the work to get all the perif/pin addresses out of the datasheet if the company does not have headers for you.  The issue still exists debugging said code as well as getting it on the chip for one of the dev boards if there is no front end for gdb to connect to remotely.  That is the biggest headache I have come across for avr.  Lilly pic had stuff for that.  Sadly I had to use asm ultimately because xc8 sucks in free mode.

so if the devboard does not work with Linux properly it is not worth the money for me.  Right now it would look like I would have to go with NXP chips as they have the tools in place.  Not sure about the price tho.

[nctnico]

Oh I am sure gcc 4.8 arm targeted will compile successfully for every cortex m chip out assuming you do the work to get all the perif/pin addresses out of the datasheet if the company does not have headers for you.

Most chip vendors (like NXP) have code packages with example code for every peripheral including C headers files which will work with GCC because its a C compiler.

[blewisjr]

All depends if the code packages are zipped or if they are installers.  Might be able to hack the installers to work but NXP provides a full IDE + GCC compiler toolchain for their chips based off eclipse.  From what I see now so does TI but it is limited in what chips it supports.  But that is really not my concern if I can get headers and it is supported by openOCD essentially you are good.  None of these dev boards seem to be bread board plugin friendly sadly which is a huge advantage to the 8bit micro's.   It is really hard to see an advantage outside of power besides the better debug support over avr chips under Linux.  That is a good thing I guess.  The LPCXpresso has a nice base board you can buy for prototyping efficiency.  Which sets its cost from $30 up to $165 which is not too bad but outside of the base boards capabilities can be tricky.

Anyone know anything about Linux and the other dev boards?

[jmole]

I know it's cliche, but the Arduino Due has Linux support via the Arduino IDE, and there's a huge community behind it, making it very likely someone has worked on an Eclipse port as well.

[poorchava]

Setting up an open-source development environment is not that bad, although you will never get the sort of functionality you can get from a commercial IDE. I was setting up an environment for STM32 like a week ago under windoze.

You need following stuff:
-Eclipse IDE for C/C++ development (google it)
-arm-none-eabi (so called 'bare metal') gcc. There's linaro, Yagarto, CodeSourcery and few others. Every package has compiler, linker, various converters, packers, splitters etc.
-openocd. Google it. Latest stable version is 0.6.1 available from official site. For windoze binaries you can go to a website of Polish colleague www.freddiechopin.info. He provides openocd binaries for windoze. If you aim for Stellaris Launchpad then you need 7.0.2 rc version.
-zylin embedded CDT plugin and GDH harware debug plugins for Eclipse

You can find tutorials on the net on how to put this all together. One thing you cannot typically do is looking at / editing peripheral registers. By default you only see ARM core internal registers. There is a plugin called embsysregview that overcomes that, although its support list is kinda limited.

For particular mcu you need to get following things:
-libraries and header files - obviously
-proper makefile OR compiler parameters that will inform GCC compiler that you are compiling for example for Cortex M4 and whether your controller has an FPU. This makes compiler spit out usable code
-linker script - this will tell the linker where in memory to put variables, instructions, functions pointers etc. It's vital for example for interrupt jump instructions to end up in proper memory cell. Those scripts can be downloaded or written by yourself if you're that hardcore
-startup file. A code file, usually asm, but c is also found, that sets up stack pointers and some other basic stuff

For ARM controllers I would say your best shot are either ST or NXP. ST sells stm32vldiscovery which contains stlink-v1 (swd mode only IIRC) which works with all STM32 controllers and works very well with openocd. NXP on the other hand has cheaper MCUs but those cheaper MCUs  - like for example LPC1111 - do not use JTAG, only SWD. And NXPs implementation of SWD state machine doesn;t go along with generic SWD dongles. And if it does they typically don;t work with openocd. NXPs LPClink debugger has proprietary encrypted interface which NXP refused to make available to openocd developers. TI's products are on an expensive side compared to NXP and ST. I think that ST's "discovery"  evaluation boards offer the best value for money. And ST makes very good silicon (especially if you know from your own experience what a mess that company is internally... )

[blewisjr]

Ok so ST looks like a solid Linux choice.  Anyone know anything about the freescale chips and boards?  Do they work with Linux I think the boards just use jlink and jtag but not sure.

I guess there is also an option to build my own board but never did that before and I am sure that would fall under the same issues with viewing chip perif registers.  Also not knowing anything about arm would make this a learning feat and a half but could be fun.

[alm]

For ARM controllers I would say your best shot are either ST or NXP. ST sells stm32vldiscovery which contains stlink-v1 (swd mode only IIRC) which works with all STM32 controllers and works very well with openocd.

I would rather buy a newer Discovery board (eg. STM32F0 DISCOVERY, STM32F3 DISCOVERY, STM32F4 DISCOVERY) with an ST-link v2 interface, which is a bit nicer (no dodgy mass storage emulation).

NXP on the other hand has cheaper MCUs but those cheaper MCUs  - like for example LPC1111 - do not use JTAG, only SWD. And NXPs implementation of SWD state machine doesn;t go along with generic SWD dongles. And if it does they typically don;t work with openocd. NXPs LPClink debugger has proprietary encrypted interface which NXP refused to make available to openocd developers.

The LPC Xpresso is not support by open source tools, but they do offer a (proprietary/code-size limited) IDE for Linux.

[nctnico]

Programming the NXP devices always works fine using the serial port and the Flash magic tool. So Openocd support is not really necessary for programming. IMHO debugging software on a microcontroller is of limited use anyway.

[blewisjr]

I don't know I think debugging is important especially for someone new to the realm even if it is just a simulator.  Easy to make errors when new to something.

[blewisjr]

Just got a lot of recommendations for the Ti stellaris on stack exchange so I guess I will look into it in more detail.  No rush as I got plenty of pics to use for now going to go hands off avr as the debugger quality is pissing me off as I like to see what is going on.

[nctnico]

I don't know I think debugging is important especially for someone new to the realm even if it is just a simulator.  Easy to make errors when new to something.

There is a simple solution for that: Take a working example and modify little bits. If it stops working, the last change messed things up. It also helps a lot to debug / verify code on a PC first. Debugging on a PC is infinitely faster and comfortable than debugging on a microcontroller.