How do I go about picking an architecture ? My first thoughts suggested Cortex M3 but the more I look into it the less sure I am.
Obviously I don't to go to the trouble of learning a new technology only to find that I've made a bad processor choice (ie nearly end of line). I've spent many hours looking at many websites and have yet to find any high-level stuff on choosing my first ARM device.
If there's one thing wrong with ARM its the almost infinite number of devices
I'm an embedded developer wanting to undertake my first ARM project, so I'm completely new to the ARM architecture. I want a low power device with serial, USB and some ADC channels.
The Cortex M3 is supposed to be an "easy (easier?) to use" ARM - so I guess that would be the one to start with?
Being quite new, the manufacturers & distributors are pushing it quite hard - so you should be able to find some introductory seminars/workshops (probably free) without too much trouble...
Personally, I would recommend a Luminary Micro (now TI) kit to start with: they are cheap, and you get a complete, ready-to-go kit - including tools - all in the box.
Thanks Andy, I am extremely grateful that you took the time to reply. I was beginning to lean towards the Cortex M3 and I think your reply seals the deal. I am now confident to press on ahead with my first ARM project.
Best wishes from UK,
John
You're welcome.
From England!
I don't think Cortex or normal ARM kernel is too important.
Look for a reasonably recently release. Each new release tends to either be cheaper or add more goodies. And being new means the manufacturer (still) believes in it.
Having so huge number of choices, you must really make a list of your requirements. Besides the obvious (number of UART, ...) you should go a bit more into details.
Do you require FIFO or DMA for the UART? Do you require FIFO or DMA for SPI? Do you require battery-backed RAM? Do you require low-power sleep modes? Do you require the family to have big brothers with lots of flash or RAM, in case your code grows larger than planned? Do you require the family to have big brothers with more I/O pins, in case you want to later build a deluxe edition of your product? Does Keil simulate all the peripherials you need, or do they just simulate the core? If you call a distributor - what chips would they recommend? Is it 5V-compliant in case you need to mix 3.3V and 5V logic? Can it produce the low core voltage internally, or does it require dual voltage sources? Does the manufacturer (or someone else) have a good set of sample code that makes use of most of the peripherial functions of the chip? Do you have special needs for ISP and IAP? Speed of erasing flash sectors? Suitable sector sizes? Built-in boot loader, or requirement that you write one? Does it seem "popular" if you surf around a bit?
If all you want is to learn to use ARM chips, then you should probably give the biggest priorities to "popular", and good availability of sample code. Then go for the evaluation board that has the coolest surrounding electronics (display, USB connector, temperature sensor, ...) for a reasonable price.
Beware of "evaluation boards" that have loads of "goodies" on them.
Very often, these "goodies" can just get in the way of your own requirements.
And, these days, disabling the "goodies" is not just a question of fitting or removing jumpers - you have to fit or remove tiny, surface-mount zero-ohm resistors...
They can be great if you just want to "play" with what's there - but can be a real pain if you have an actual aapplication in mind...
This is general across the board - by no means specific to any kind of ARM.
Lots of goodies is nice, but should be completemented with lots of jumpers so that you can decide if they will consume processor pins or not. A board requiring (de)soldering to deactivate the goodies is lousy. It must be quick and easy to switch between the evaluation-board hardware and own hardware and then back again, in case the software (or the own hardware) doesn't work as expected.
But note that my recommendation to look for a evaluation board with lots of goodies was for someone interested in learning how to use a processor - not someone interested in designing their own products around an ARM chip. If the goal is to develop own products, then it is often better with a evaluation board with pin headers allowing the processor to be mated with prototype boards. A big prototyping area can be nice, but are best if you can afford to buy multiple evaluation boards.
I want a low power device with serial, USB and some ADC channels.
I think those are the requirements you should focus on (repeating others' remearks here.) Not the 'ARM family.' What's an 'ARM family' anyway? Is it the CPU core? ARM7TDMI is among the most popular in general-purpose MCU's. Cortex M3 is emerging as the new leader. Whatever you pick, you'll still program in C (most likely.) I've had an experience of transitioning from an ARM7TDMI-based MCU to Coldfire V2. The latter is big-endian as opposed to the little-endian ARM7TDMI. To my surprise, it wasn't painful at all. As long as you write in well-styled C, you won't have problems running your code on any 32-bit CPU. For every new architecture, things like startup code and device drivers have to be written. That's something to keep in mind. Apart from that, I don't think the choice of a CPU family is that critical.
look at what you need
I thoroughly agree.
It is, however, the trend these days.
:-(
And I do take your point about the distinction between learning/experimenting and actually trying to develop an application.
John; I believe that one of the devices in the Cortex-M3 family will be an excellent choice. I think the Luminary devices are great chips. I just worry about which chips that TI will cull from it broad device selections. With the TMS430 (not ARM), the TMS470, the OMAP35xx series only the shooting stars will make the cut. I know exactly which device will be cut. The very next Luminary chip I select for a project will be the first victim : ( For the Cortex M-3, I suggest that you review Joseph Yiu "The Definitive Guide to the ARM Cortex-M3". The ISBN: 978-0-7506-8534-4. You can review the book at http://www.books.elsevier.com. It's a UK book house. Also, available is the Cortex_M3 Technical Reference Manual (TRM) at www.arm.com/.../index.html Bradford
if you are just trying to learn about the chips, it is a lot easier: the idiosyncrasy among the various ARM chips, even across vendors, is much less than for other chips, like PIC. that is especially true if you stay with a high-level language, like C.
however, if you start to use OEM libraries in your code, the program will become very platform dependent and far less portable, unless you rewrite the library functions for another chip - which is doable but can be burdensome.
if you are picking a chip for a particular design, I would prototype it on a dev board, figuring out how much resources you need and upon completion, pick the device that matches the current and future needs for that project.
It is always very dangerous to make use of manufacturer-specific libraries.
For commercial use, you should have full access to the source code, and a license that allows you to run the code on _any_ processor, even if different manufacturer or non-ARM architecture.
I'm not too fond of the libraries some manufacturers supplies with the intention to make it easy to move between different chips from them. It might sound good, but the main reason for the manufacturer-supplied libraries is to make it hard for you as customer to move to a different manufacturer. Having millions invested in a product and find that you can't move to a different manufacturer to save $2/device, or to get a working chip after the original chip stops being produced can be very interesting...
"For commercial use, you should have full access to the source code, and a license that allows you to run the code on _any_ processor, even if different manufacturer or non-ARM architecture."
I would be surprised if that (moving the code to _any_ processor, even if different manufacturer) is the case with OEM libraries - at least in my experience.
a big discussion is going on right now with TI's purchase of Luminary, and the resulting possibility to run Luminary libraries on TI chips. the Luminary library provides full source code to its libraries and it is not hard at all to port it to other TI chips, ARM or not, or other manufacturers' as well.
But legally, you are NOT supposed to do that.
if you can provide a few examples where an OEM library can be legally run on other manufacturer's chips, I am happy to see that.
Right now?
Really?
No, I would have big troubles supplying examples. But that is why I warn about taking the easy route and use the OEM libraries without first having made a full analysis of the implications.