ARM Cortex M3, M4 ... where to begin?

[dotm]

So trying to overlook that enormous field of ARM microcontrollers, I'm getting more and more confused the more I read.
Now that it's christmas I have the chance to buy for my company some development kits to switchover to ARM microcontrollers.
Bad idea, since there are gazillions and I need to order in the next days from farnell (or similar).

The way I worked until now was programming 70% PIC18/16 and 30% AVR. The learning curve was quite fast because I had proteus to immediately simulate every step of my program , and therefore knowing exactly why my (very crippled at the beginning..) code was working or not.

My ARM beginnings may be a little bit tougher. No simulation in proteus for up-to-date devices, in fact no WYSIWYG simulators at all, several different development platforms, endless numbers of development kits and me, in the middle....

What I'm now looking for is a beginners solution with enough power (means high clockrate?) to start programming real-time applications, a working and good solution to debug, either in simulation and/or on the development board (what is the thing here? there are several different approaches from different manufacturers...)
AND a good IDE that handles the complete process from programming to compiling to debugging and simulating and so on...

Since KEIL-MDK seems to be the IDE that will work for me (correct me if I'm wrong), the choice of a development kit is yet to be made. Who can tell me simply what to buy? Help me to get as fast as possible from 0 to 100 by choosing the right ARM Tools.

Merry Christmas.  

[bigtoy]

Well, ask 10 people that question and you're going to get 20 different opinions! Let me give you my 2 cents, because I've transitioned from 8-bit micros to the ARM processors.

Over the past 18 - 24 months I've used Cortex M3 / M4 processors from ST, TI, NXP and Freescale, on a few different projects.

One thing I've learned is you'd really like a toolchain that allows you to switch from one processor family to another. Ideally you'd be able to move your code from one processor to another without it being an impossibly difficult task. Different processors might have different peripherals so of course that code might change, but a surprising amount of the core code can remain the same.

I like using GNU / GCC based tools, and an Eclipse based GUI. Pretty much all the vendors offer their flavor of that. Right now I'm using Freescale's CodeWarrior - it's GCC and Eclipse. Previously I used the GCC compiler within TI's Code Composer Studio (again, Eclipse based) for their Stellaris processor. Although the tools might be "different", they're much more the same than they are different.  (And they're free for small to medium sized projects.)

Right now I'm madly in love with the Freescale MKL25Z128 processor, the latest member of their Kinetis family. It's a Cortex-M0+ core, runs at 48 MHz, has 128 kB of flash, 16 kB of RAM, 16-bit A/D, a 12-bit DAC, lots of fast GPIO pins, etc, and it's cheap, just a couple of bucks. Freescale has a demo board called the Freedom board; only $13 for the board.

Simulating is an issue for any of these ARM processors. I've seen simulators, but none that really seem bulletproof. Consequently I'm not a simulator fan myself, but your mileage may vary.

You will have a learning curve moving from PIC / AVR to ARM. The biggest thing always seems to be that with any of these ARM processors, you need to "enable" a peripheral by turning on its clock before you can use it. Almost all peripherals will have their clocks turned off at power-up by default, to save power. So before using the ADC (for example) you need to turn on its clock before you can start accessing its registers, etc. The other newbie "gotcha" usually involves interrupts. Most interrupts on these ARM processors go through a logic block called the NVIC, which allows interrupts to be enabled, disabled and prioritized. So not only do you need to enable the interrupt in the peripheral, you need to enable it in the NVIC as well. These 2 things are pretty different to the PICs and AVRs, where most peripherals are ready to go at power-up, and interrupts only need to be enabled in the peripheral - there's no NVIC sitting between the peripheral and the CPU core.

Debugging with ARM is normally pretty good. All these processors, and their free tools, make it pretty easy to read the internal registers, step through code, do memory dumps, etc. ARM has a standard debug interface that appears on anyone's processor so you'll find it's well supported and well documented.

Good luck! It's well worth making the switch.

[dotm]

I like using GNU / GCC based tools, and an Eclipse based GUI. Pretty much all the vendors offer their flavor of that. Right now I'm using Freescale's CodeWarrior - it's GCC and Eclipse. Previously I used the GCC compiler within TI's Code Composer Studio (again, Eclipse based) for their Stellaris processor. Although the tools might be "different", they're much more the same than they are different.  (And they're free for small to medium sized projects.)

I've been worried that an eclipse based toolchain may not be able to debug step by step with readout possibilities of all registers. How does this work?

Right now I'm madly in love with the Freescale MKL25Z128 processor, the latest member of their Kinetis family. It's a Cortex-M0+ core, runs at 48 MHz

Shouldn't I start with M3 or M4 to be at the edge?

You will have a learning curve moving from PIC / AVR to ARM. The biggest thing always seems to be that with any of these ARM processors, you need to "enable" a peripheral by turning on its clock before you can use it.

Well while using proteus I had several similar problems at first with PIC or AVR processors, choosing the wrong clock source , not having set the correct flags... The thing is that proteus MCU debugging features tell you exactly whats going on in the IC , that helped me immensely, especially with timing problems. Since ARM processors are only debuggable in the real world, i expect way more difficulties.. Is there an IDE that supports a DSO and a logicanalyzer to be readout and logged aside with the code steps? Or maybe even better: Synchronizing with Labview which is allready gathering all the data from my measurement equipment..

[jumulab]

Hi,
You can start with ARM Cortex M4,  ATMEL ATSAM4S. The IDE  is free (GNU) and directly supported by ATMEL , the
ATMEL STUDIO V6.0. This are charged with a boundle of examples, so you can start very quickly.
There are several demo and start pcb ... I suggest the ATMEL SAM4S Xplained.

Regards.

[Old_but_Alive]

I'd go with Rowley Crossworks.

superb IDE, supports most of the ARM  devices, and has good JTAG debugger support

http://www.rowley.co.uk/arm/index.htm

am I gonna get muted for the link, I hope not

[dotm]

You can start with ARM Cortex M4,  ATMEL ATSAM4S.

Unfortunately , there is no development kit on stock at the moment.

I'd go with Rowley Crossworks.

Which debugger do you use?

[jumulab]

Hi,
at our labs, we are usign the ATMEL SAM-ICE debugger.
Internally is an SEGGER  JTAG debugger device. Connector to PC by USB.
There are a lot of vendors ( in ebay) for these  debugger.
It connects directly to ATMEL Studio for debugging/programming ARM chips.
I suppose it works with any other IDE with JTAG capable debugger.

Regards

Posted on: December 21, 2012, 02:32:54 14:32 - Automerged

Hi,
at our labs, we are usign the ATMEL SAM-ICE debugger.
Internally is an SEGGER  JTAG debugger device. Connector to PC by USB.
There are a lot of vendors ( in ebay) for these  debugger.
It connects directly to ATMEL Studio for debugging/programming ARM chips.
I suppose it works with any other IDE with JTAG capable debugger.

Regards

Hi,
about the kit , you can find / purchase at FARNELL:
http://es.farnell.com/atmel/atsam4s-xpld/eval-sam4s16-xplained-kit/dp/2215343?ICID=I-ATM-1000082-HPBLOF-0125&Ntt=2215343
the cost is about 15 €.
You can take a view at Atmel www :
http://www.atmel.com/products/microcontrollers/avr/xplain.aspx
This board has included the Segger/Atmel debugger , so, you can connect by USB to PC directly

[Old_but_Alive]

@dotm


Quote from: Old_but_Alive on Today at 10:23:49 am
I'd go with Rowley Crossworks.

Which debugger do you use?

olimex ARM-USB-TINY and Amontec JTAG key

[digitalmg]

From my experience with ARM Cortex M,the best choice would be:
Compiler:
1.Keil - with Ulink2 debugger
2.IAR - with Jlink debugger
uC:
1.STM32Fxxx from ST,has full range of Cortex M, from Cortex M0 to Cortex M4,the price are OK and find the best documentation.
You can start with STM32F0DISCOVERY have on board ST-LINK/V2 debugger and cost 10$.
2.LPC1XXX from NXP,also has the full range of Cortex M.

[dotm]

From my experience with ARM Cortex M,the best choice would be:
Compiler:
1.Keil - with Ulink2 debugger
2.IAR - with Jlink debugger

so those debuggers are as universal as possible i guess?

[WhiteKnight]

At least Keil shows that ST-link supports microcontrollers made by other vendors (atmel, ti, nxp). I have not prove it yet as I am more engaged to ST now. It looks like you should select a flashing template.

[dcsmrgun]

hi dotm,

I'm a recent newcomer to the ARM platform and it's pretty much been the only embedded platform I've ever worked on, save a few crude Arduino sketches.

My take on it is this:

The core concepts are pretty much universal across the chip line so it won't really matter which board you opt for. Which vendor you choose will depend on whether or not you want to use their pre-packaged driver library to make development easier, or whether you are comfortable going directly to registers on the uC themselves. Personally I opted to learn ARM development by foregoing any specific vendor libraries and relying on just CMSIS and register access to get my code written and I've had very few problems porting my little apps from my LPCXPRESSO1789 to my STM32F3DISCOVERY board and now to my TI Stellaris board. About the only difference between these is just figuring out the register layouts for peripherals and after that you're good to go.

In fact I learned most of my ARM development by watching AVR tutorials on Youtube, which should go a long way to my argument that the differences between the chips aren't really as great as the similarities. The core concepts remain the same across

As for an environment, I have several: I'm primarily a MacOS user so I tend to write my code in Eclipse and debug with OpenOCD. I won't say it wasn't a pain in the ass to get that setup running, but I like to think that not having to fire up a Windows VM in VMware every time I want to crank out some code is worth the effort I put into it. On the Windows side I think you have much more freedom in what you run. I think most of the IDEs you have access to are brilliant so really just picking one becomes difficult. In my case it all comes down to which IDE supports OpenOCD and the debugger I purchased (DangerousPrototype's Bus Blaster) and there are several.

So I guess that's a lot of text to say that I don't really think it matters what you choose to start off with. If you're like me you spent a lot of time researching every little bit of ARM development and all that time could have been spent actually DOING development instead of worrying about everything. The conclusion that I came to is that worrying about picking the perfect IDE/board/chip combo is really a fool's errand -- Pick a chip that has the GPIO/peripherals/performance that you need, then pick an IDE which will both debug and support that chip. Don't use vendor libraries (StellarisWare, STM's driver lib, etc) unless you want to stick to that line of uCs for a long time. If you end up going with a board like lpxcpresso or stellaris, you can download TI's code composer studio or NXP's lpxcpresso IDE which will both let you develop code and debug it since both boards have on-board debuggers. Unless you have a pressing need to use a more standard IDE then you may as well just use that until you outgrow it.

I realize that's a little rambling but I think the gist of what I'm saying is that it doesn't really matter what you pick as long as you get started and you can always tweak your development environment along the way as you learn more about the process


Also: On chip debugging is a fantastic resource in lieu of simulation. Step through your code while it's running on hardware and I think you'll be very happy with what you can learn!





(so honestly my actual hardware suggestion is just go buy an NXP LPCXpresso1769 board, use the free IDE to code and debug for it until you need more, and don't use any driver libraries unless you plan to stay with NXP forever). Once you outgrow lpcxpresso's IDE you'll probably be in a great position to decide which "big boy" package to switch to. I'm planning to switch to CrossWorks once I can justify the $150 personal-edition license fee

[bigtoy]

Looks like you've had lots of great replies. To answer one of your questions:

Shouldn't I start with M3 or M4 to be at the edge?

Not necessarily. It depends upon what you're doing with the processor. M3 and M4 are higher performing than M0+, but they also cost more. If this is a one-off hobby project it makes no difference. If this is going to become a sellable product, then of course cost should be considered. The way these ARM "M" processors are structured is pretty simple. For the CPU core, M0 has a certain set of instructions it supports. Then M3 supports all the M0 instructions plus some extra instructions. And M4 supports a few additional instructions again. So they're all just subsets / supersets of each other.  (There's also differences in the internal bus architectures.)

For the product we're using the M0+ for, we've found the M0+ is actually outperforming a NXP Cortex-M3 we started with. Reason being that our application does a lot of bit-bashing GPIO pins I/O. This new Freescale M0+ has hardware support for single-cycle GPIO I/O, whereas the older M3 does not. So despite the somewhat slower clock speed of the M0+, it's actually giving us excellent performance in our application. Horses for courses, as the English say.

[CrankCase]

Shouldn't I start with M3 or M4 to be at the edge?

There is something to watch out for - for instance TI and others are in the process of dumping a lot of their Cortex M3's right now - you spend months of labor time getting a project ready to go only to find there ain't no parts available.  For instance the TI Stellaris stuff (LM3Sxxxx) is suddenly unobtanioum, or can be months away for factory stock.  And one ARM M3 from one supplier is not like a drop-in replacement from another supplier, be aware.  Or you might find that chip you designed code on is a BGA, and the only parts that are available are qfp, etc.

Really, for the amount of labor time involved to move away from a pic - you have to look at your Return on Investment.  There may be applications where a pic is just fine, and other apps where moving to an ARM device is fine.  Just make sure the labor time is worth it.  There are applications for each type of device.

[dcsmrgun]

Yeah, there's something to be said for an established solution, especially when you're working on a large scale project. For hobbyists it's more of a tossup. It would be more hassle for me to switch to PIC right now simply because I've got a working environment up and running and it's easier for me to use an M0 or M3/M4 for a tiny baby project even if they are 100% overkill.

Starting with M3/M4: It depends on what you need to do. If you have an application that take advantage of a floating point unit then an M4 would be a great place to start. If you need a 120mhz clock speed then an M3/M4 is what you want. If you just want to drive a seven segment LED display then you CAN use an M3/M4 or really any ARM (or any lesser chip too).

It depends on whether you want to buy a chip for a purpose or just have a test environment. If you want to LEARN to develop for ARM then you might as well get something like the LPC1769 LPCXpresso which has support for Ethernet, USB, CAN, etc. That way you'll be able to prototype anything you want, to a point (it has no FPU). If you're building a product then you'll likely want to select a more affordable chip that only has the components you want. Nobody can really answer whether you should start with an M3/M4, but like I said before: coding for these chips is pretty similar on the surface so if you start with an M0 you will easily be able to port your code to run on an M4, and if you start on an M4 there is a good chance that if you don't use a lot of assembler you'll be able to straight up port your code to an M0 so moving back and forth doesn't seem to be a problem.

I'll definitely defer to someone with more experience, but that's my world view on the ARM thing right now. I'm still very much a beginner so obviously there is much more to be said on the subject that I don't know about

[Al-Amoudi]

Hi
All ARM Cortex M3/M4 based microcontrollers from the different manufactures (st, ti, nxp ...) use the same core processor from ARM.
The differences can be summarized as follows:

1- Core options implemented in the chip (memory protection unit, debugging options, number and priorities of interrupts ...)
2- The internal bus structure of the chip and the maximum clock
3- How and what peripherals the chip manufacture included in the chip

I use development boards based on chips from ST. In fact there are more ST based development board int the market than the others.

For development I use Keil. IAR is another good development environment.

ARM Cortex is optimized to be programmed by C language. I rarely use Assembly Codes in my projects

[alexxx]

so those debuggers are as universal as possible i guess?

I just got into Cortex-M world, started with LPC1227 by NXP (M0 core).
I had no problems developing my first Cortex-M application, using IAR.
The switch from AVR was not so difficult, since I also used IAR compiler for AVR.
It is worth to learn Cortex-M0 core, since it's newer, 32-bit and much more advanced than AVR. Surprisingly it is also cheaper compared to "big" AVRs like ATmega128 or even ATmega644. 

If you decide to go with IAR, development kits are available.
http://www.iar.com/en/About/Pressroom/Press-releases/2011/2/IAR-Systems-first-to-launch-development-kit-for-NXP-LPC1227-microcontroller/

[Ichan]

My suggestion is STM32F4 - it is just like a pretty girl to me.. 

Buy a STM32F4Discovery for about 10 bucks or so, you can choose IAR EWARM or KEIL MDK ARM, then download all technical sources from ST site - nothing else to spend.

-ichan

[dotm]

The problem is availability.

Since the ATSAM4S-XPLD has 114 days shipping delay, i got me some lpcxresso and a base board for them.
Still waiting for these items to arrive.

Thanks or all your help.

[dcsmrgun]

I think you'll be happy with the lpcxpresso, especially if you're just learning. I've had great success with mine, and NXP's documentation is second to none (800 page manual for the LPC1769 chock full of detailed info). Check out the Insider's Guide to the STM32 which has a lot of useful info regarding the Cortex processor in general (though the registers may or may not be different since the document is STM specific):

http://www.hitex.com/fileadmin/pdf/insiders-guides/stm32/isg-stm32-v18d-scr.pdf

LPCXpresso IDE is pretty friendly and Eclipse based so you can add your own plugins, etc. You can also upgrade to the full Code Red Suite and the interface will be pretty much the same so you've got a bit of an upgrade path (even if Code Red isn't really one of the go-to packages everyone talks about) to a better software. You can even use your LPCXpresso lpc-link board to develop on other chips using Code Red down the road.

Good luck and feel free to ask any questions you may have. I'm definitely still learning but I'm sure there are plenty of people here who can advise

[Ichan]

I like LpcXpresso but not too happy with it  - Start learning using it's own IDE then later have to choose another one (iar/keil/etc..), learning twice!

On the other side, with STM32xxDiscovery we choose iar/keil/attolic from the beginning.

NXP is a winning party on LPC2xxx era, but then make a wrong policy with Cortex generation - Just my fractional cent.

-ichan

[Chuleo]

I really like the Freescale Kinetis Series. The tower module is not the cheapest but it has some excellent functionality. One can simply add almost any daughter board to increase funktioality. I've been using it with Keil IDE and an Ulink-Me. I'm still at the bottom of the learning curve, but II get used to it.

Btw. Does anybody have experiences with The RL-ARM Ethernet Network Interface from ARM? It seems to have an extremely low throughput if packets are sent via TCP.

[metal]

Chuleo:
You meant this link?

[Chuleo]

Chuleo:
You meant this link?

Yes this is exactly the one I meant. I personally have the TWR-K60F120M

[dcsmrgun]

I like LpcXpresso but not too happy with it  - Start learning using it's own IDE then later have to choose another one (iar/keil/etc..), learning twice!

On the other side, with STM32xxDiscovery we choose iar/keil/attolic from the beginning.

I definitely don't disagree, though learning the tool is secondary to just learning to develop for the uC in my opinion. I've bounced around between lpcxpresso and code-red on my mac and Keil on my PC and really I haven't had too much trouble. I'm for sure not saying that it's not worth having in-depth knowledge of your IDE, but as a beginner I think it's a workable solution. Plus if you don't want to tie yourself down to one chip vendor you'll probably want to buy an external JTAG probe anyway which you should be able to use in Keil or whatever you want to use, for not TOO much more money

But I agree that if you're looking to use Keil primarily from the get-go then STM32 Discovery boards are probably more what you want if you're not looking to invest in a third party debugger.