We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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.
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.
"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."
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.
I did not find Andy's argument entertaining one bit (in the case). He is simply right.
I meant of course, "I did not find Andy's argument entertaining one bit (in this case). He is simply right."
tamir, have you managed to find Per's writing that suggests that his caution against the use of OEM libraries "is due to the impact such libraries can have on the performance, stability and in the end, SAFETY of systems. "?
Just don't want to put words in Per's mouth, you know.
I already explained to you where, and even provided a quote.
tamir, are you talking about this "quote"
"For commercial use, you should have full access to the source code..."
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?
try to focus on the end of the quote. namely, the expression that start with a "s" (a blatant clue, surely you agree). if you need more, just say so. Ahh, whatever, I'll give you one more: the next character is "o". now it's a no-brainer.
tamir, thanks for that clue, not.
if you cannot answer the questions, please just admit to it and we will excuse you on your behalf.
thanks in advance.
I never like this, but it is a software release date and a reason to celebrate to let get it on!
I meant: "I'm never like this, but it is a software release date and a reason to celebrate to let get it on!"
Mr Tamir.
What are you on { about } ?
release P004 rocks...!
Per did use the word, "dangerous".
But I don't think he was talking (particularly) about hazards to persons or property - I think he was talking about business risks.
As in, "there is a danger [business risk] that not having the source code may leave your project/product high & dry"
I think.