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.
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.
Simulation also.... helps a lot to get the product soon quick.
I feel Keil is better for ARM and C51 cores..
Chinni
"No, I would have big troubles supplying examples. "
because such OEM libraries don't exist - any OEM would be crazy to invest in a library only to help competition by allowing such libraries to be used on its competitor's chips.
"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."
your caution is the right one but for the wrong reason.
No. Per's caution is due to the impact such libraries can have on the performance, stability and in the end, SAFETY of systems. it is rahter your line of argumentation that is redundant from an engineering point of view.
"Per's caution is due to the impact such libraries can have on the performance, stability and in the end, SAFETY of systems. "
can you point out for us the exact sentences where Per argued in a way consistent with your representation above?
Just don't want to put words in Per's mouth, you know.
I believe that is the reason he specifically referred to "source code".
"For commercial use, you should have full access to the source code..."
Return to my original post. I did wrote:
"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 never said that manufacturers have libraries with licenses that allows you to move them to other architectures and/or manufacturers products.
I did say that a manufactuer-supplied library can be very dangerous to use.
And I did say that you should look for libraries that has source code and an acceptable license. These libraries would most probably _not_ be manufacturer-supplied, but libraries you buy from 3party companies, or libraries that have a LGPL license or similar.
When you invest greatly in a product, you must make sure that you are not squeezed into a situation where you must either start from scratch because your processor gets dropped, or where you must continue with one manufacturer even if another manufacturer has a way better product.
The question is how to best protect your investment, and to allow your company to make the business decisions, and not your component suppliers.
You may find that your nice product is too small - you get a customer that says: We will buy 10k units/year if you just have one more ethernet connector and 12-bit instead of 10-bit ADC. With full control over the sources, you may be able to port your 99% C/C++ code to _any_ available ARM. With 40% of your sources locked to a specific manufactuer, you may no longer just adjust the peripherial mappings for another chip, but suddenly also rewrite, test, document, ... the 40% of the code that you are not allowed to reuse.
And you may suddenly find out that you need 12 months for such a step, but a competitor can supply a customized OEM product in 3-6 months. Oops. Deal lost because you where not in control of the source code for your important product.
In the end, the chip manufacturers do not supply their libraries to be nice and make it easier to use their chips. The main reason is to lock you in. That the libraries _may_ simplify some things is a bonus, but not the primary goal. The only simplification that was intended was the amount of work needed to to move within their chips compared to the work of moving to a competitors chips.
which part of that talked about "performance, stability and in the end SAFETY"?
are you suggesting that having, or not having, access to the source code will hurt "the performance, stability and in the end, SAFETY of systems".
if so, how?
if not, what exactly did you mean?
and you cannot provide any examples of such libraries that would allow its licensees to use on _any_ processor.
it is a theoretical possibility and practical impossibility.
unfortunately, we live in a world that "should" has no value. "Per should be a billionaire" doesn't buy a $0.49 burger at McDonald's, :).
Not at all!
There are many commercial libraries that can be licensed to any suitable target; eg, most commercial TCP/IP stacks.
"most commercial TCP/IP stacks."
and you can eat BigMac with BK seasoning too, :).
while entertaining, your argument does sound irrelevant to our discussion here.