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...
lobotomized.
Tapeer.
i enjoy so much all the philisofical discusions with u. but i am busy and must work now.
plz. u lie down and relaxxxxx.
Always yo're freind.
Zeusti.
(job one, write good delay rootine)
I don't bother to read you messages anymore. I will only stop after you openly admit that you went through the lobotomy procedure, like this: "My name is zupeesti and I am lobotomized. Excuse my bad manners" (you can add typos were you like).
tamir, you sound like you have an anger mgmt issue.
calm down, please.
NO WAY, YOU @#!$#$%$@^#$%$#%$@%@%$@
:-)
"My verdict on their code was not positive. "
there are always bad OEM libraries, as there will always be bad programmers, or bad people.
But such facts don't mean all OEM libraries are bad, or all programmers are bad, or all people are bad.
if you don't believe me, take a look at Luminary's Stellaris and let me know if you think you can do better consistently.
"But such facts don't mean all OEM libraries are bad, or all programmers are bad, or all people are bad."
No one has made such a claim.
The question is just how much you are willing to trust the library supplier if you don't have access to the source code to verify the code quality and to incorporate fixes. Incorporating a bad library in a product can be lethal for a company, so the question is how much trust you have in the library supplier.
almost 10 years ago I was working for a startup company on a VOIP phone. we used a commercial TCP/IP stack which was riddled with a huge number of bugs. We could only help the manufacturer by actually having the source code and a lot of willingness to debug and dig up their trash...
I don't know why, but whenever someone mentions problems with a TCP/IP stack, I start to think about InterNiche. 10 years should be about the right time frame too ;)
(knows you do not need to push r0 and r1)
just a little foot note: you do know that this only applies to THUMB mode, don't you? otherwise, the following would not have appeared in the ATPCS (ARM-Thumb Procedure Call Standard) document, surely you agree?
maybe you have skipped this while browsing your documentation:
infocenter.arm.com/.../DUI0056.pdf
see page 24, paragraph 2.2.1
quote:
The following register usage applies in all variants of the ATPCS except where otherwise stated. To comply with the ATPCS you must follow these rules: Use registers r0-r3 to pass parameter values into routines, and to pass result values out. You can refer to r0-r3 as a1-a4 to make this usage apparent. See Parameter passing on page 2-9. Between subroutine calls you can use r0-r3 for any purpose. A called routine does not have to restore r0-r3 before returning. A calling routine must preserve the contents of r0-r3 if it needs them again....
however, if you can find a similar quote for ARM mode, in which I have written my code - you are right (but I doubt you will).
I forgot to highlight the following:
"A called routine does not have to restore r0-r3 before returning". but this is only true when complying with ATPCS. it is certainly not true (as far as I know) when running in ARM mode.
i dn'nt have time 2 teech u simple basics. but u need advising.
read
en.wikipedia.org/.../Calling_convention
look at entry for arm
infocenter.arm.com/.../IHI0042C_aapcs.pdf
look at page 16
if u do not understand now. compile this little function with keil
void SmallDelay(void) { volatile int x; for (x=10000;x!=0;--x) ; }
look at the code made by compiler
SmallDelay PROC ;;;783 ;;;784 void SmallDelay(void) 000ba4 e59f0100 LDR r0,|L1.3244| |L1.2984| ;;;785 { ;;;786 volatile int x; ;;;787 ;;;788 for (x=10000;x!=0;--x) 000ba8 e2500001 SUBS r0,r0,#1 000bac 1afffffd BNE |L1.2984| ;;;789 ; ;;;790 } 000bb0 e12fff1e BX lr ;;;791 ENDP
see that r0 is not preserved.
or do you think keil have got it wrong?
as i say b4. you should not say book is bad if you have not seen.
not surprisingly you don't answer my question, but let correct you: R0 is not saved because it should not - it is always used as a return value. try to actually understand what you are posting, for a change.
look man, I'm serious now. you are a danger to society. do you understand? you are dangerous by writing delay loops like that. confide it: you are indeed dangerous. don't write software for: planes missile space systems cars trains etc.
stick to flashing LEDs and bad English, please...
I wonder: can you point to anywhere in the document (that you obviously did not read at all!) to prove that I'm wrong? here, I challenge you: take your time, and tell all of us a page number and paragraph number. I'm waiting, "correcting professor".
Tamir wrote: "I wonder: can you point to anywhere in the document (that you obviously did not read at all!) to prove that I'm wrong? "
from the point of view of a bystander, I just wanted to point out that you seem to put a lot of emphasis / weight / priority of "proving yourself right". have you ever thought about why that's the case? that sounds like a very insecure person looking for ways to build up self-esteem.
there is nothing wrong with being wrong: it is human to be wrong.
there is everything wrong with refusing to acknowledge and learn from your wrongs: because you stay wrong that way.
if you look at this very thread, there is no shortage of people trying to explain their bogus reasons in order to "prove" their right.
you don't have to be anyone of those people, because you are better, as long as you are comfortable with your wrongs.
View all questions in Keil forum