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...
tamir, don't give up. don't EVER give up, :).
so Andy, you are conceeding on that the two other fronts (performance and stability), Per didn't think using OEM libraries would have adverse effect? could you work that out with tamir? :)
"As in, "there is a danger [business risk] that not having the source code may leave your project/product high & dry""
so it would not have any adverse impact on "SAFETY" (aka business risk) if you have access to the source code?
does that make it OK to use the Luminary libraries? could you please work that out with Per? :)
This thread quickly evolved into a kindergarten brawl, for no apparent reason.
Why should I be required to give examples to something I'm not claiming?
The probability of bugs is similar whoever wrote the code. A much used library from a manufactuer should - hopefully - be reasonably well-tested by all the users.
But I was talking about the business risks of using a library you don't have the source code - and suitable license - for.
With the source code, you can perform security reviews, looking for buffer overflows, resource leaks...
With the source code (and most licenses), you can correct bugs without need to wait for a new official release, and without worrying about the supplier vanishing.
With the source and a suitable license, you can not only fix any bugs, but also move the complete source code to new platforms.
Since a chip manufacturer isn't likely to supply general libraries with full source and BSD, LGPL or similar licenses, you should be very careful about using them. You may end up with a very serious nose bleed.
The CRTL can also be a bit problematic, but the advantage with the CRTL is that there exists a large number of suitable licensed C runtime libraries, so a company can replace printf(), strxxx(), time(), ... with alternative implementations without having to start from scratch, as long as the target has some safety margins in case the alternative implementation takes more code space, RAM or executes a bit slower.
I'm not. Actually, now that RTX related problems have been solved (I hope; will know more the coming days when the feedback from the client(s) arrives) there is a real possibility to making it to the original deadline. Say, Ashley, are you related to "Jack Sprat" [or maybe I should say: ARE you "Jack Sprat"? Sorry Per for resuming the kindergarten for a while; I'm actually enjoying myself. this was a good day - have I mentioned release P004 yet? :-) ] ho and Ashley you forgot to grade me!
With the source code (and most licenses), you can correct bugs without need to wait for a new official release, and without worrying about the supplier vanishing. A ticket machine was violating the J1708 protocol and created many errors on the bus. When the manufacturer was approached they, of course, replied "no such thing". After being shown proof they stated "this will be fixed in the next release out in October next year (my emphasis).
Erik
"Why should I be required to give examples to something I'm not claiming?"
sounds like you are unclaiming what you just claimed. what do you think this guy/gal was claiming when s/he said:
"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."
no answer is required, :).
So, I give you an F for your reading skills.
Where did the following text explicitly mention that you should use OEM libraries with generous licenses?
The above text indirectly says that you should look for _general_ libraries and _stay_away_ from manufacturer-supplied libraries.
This was further strengthened if you had also quoted the sentence directly above: "It is always very dangerous to make use of manufacturer-specific libraries."
That is a good reason why it is quite strange that you require me to supply examples of OEM libraries with LGPL, BSD or similar license even if such examples does exist.
If I should supply examples to my claims, then it woould be more reasonable to expect examples of restricted licenses common with manufacturer-supplied libraries - not examples of free manufacturer-supplied libraries.
Do you often expect people to back their claims by examples that are negating the claims?
... some young whippersnapper SHOUTS "prove it"
If we can not share our experience whithout being "taken to court" then some of us will need to start charging (which we do when required to 'prove')
'Where did the following text explicitly mention that you should use OEM libraries with generous licenses?'
why should I defend a question that I didn't ask?
you get F for your reading comprehension.
'If we can not share our experience whithout being "taken to court" then some of us will need to start charging (which we do when required to 'prove')'
you sure can share your experience whenever you want. That doesn't mean that others have to take your experience at face value.
if you cannot stand the heat, you should probably stay out of the kitchen.
woman, you have an attitude! yuk! :-)
"why should I defend a question that I didn't ask?"
So you don't even understand your own posts?
"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."
is it less than truthful if the whole discussion has been able the use of OEM libraries - I am the first person mentioning that and you follow right up with your "commercial library" concept, which the OEM libraries are a subset of it.
now, you are saying that you followed up in a thread about the use of OEM libraries so you can talk about the use of non-OEM libraries that allow you full source code access, of which you can find none?
so you are essentially suggesting that we should use libraries that do not exist?
????????????????????????????????????????
is this some kind of mind trick?
Good writing practices says one or three punctuation characters. Not two. Not more than three. But then sentences are expected to start with a capital letter.
Do read my post again. I warn aganst the use of manufacturer-specific libraries or any other kind of libraries, where you do not have full control. And full control includes access to the source and a license that allows you to use it.
I have never once said that manufacturers likes to give out their libraries with full source and carte blanche licenses. But I have claimed that the main reason for such libraries is to bind you harder to their products.
The only trick involved is a trick often used by the manufacturers. If you are going to use a manufacturer-supplied library, you should at least do it with your eyes open!
The ARM chips are powerful enough that you can most of the time have very good separations between hardware and business logic. When you design all of the code, you can be very careful about where to place this separation. When using a manufacturer-supplied library, you will instead end up having your business logic littered with copyrighted function calls. You can't just rewrite the library implementation if you try to move to another processor, because you need to match the original function prototypes - and the original header file is copyrighted...
"I have never once said that manufacturers likes to give out their libraries with full source and carte blanche licenses. But I have claimed that the main reason for such libraries is to bind you harder to their products."
Now I use my MCU vendors brain: Creating the libraries often involves many man years of coding, so why giving it away to be used by competitors. Why would you not want to try binding customers to your chips if at all possible. That is viable business practice as long as you help your own customers.
Switching brain to MCU user: It sucks to be stuck with one vendor, particularly using ARM where it would be rather easy to switch from A to N to S or T. So if I find a real open source I will probably go for that one.
Impair, an attempt: If you find what you are looking for with one vendor and the chips do what they should and the price is right, don't argue, go for it and get work done.
Cheers, Robert For the original poster there is a site that gathers articles related to Cortex-M mcu-related.com/.../35-cortex-m3
View all questions in Keil forum