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...
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".
Tapeer.
a nother example to cklarimfy.
void SmallLoop(void) { volatile int a; for (a=10000;a!=0;--a) { volatile int b; for (b=10000;b!=0;--b) { volatile int c; for (c=10000;c!=0;--c) { ; } } } }
SmallLoop PROC ;;;783 ;;;784 void SmallLoop(void) 000ba4 e59f211c LDR r2,|L1.3272| ;;;785 { ;;;786 volatile int a; ;;;787 ;;;788 for (a=10000;a!=0;--a) 000ba8 e1a03002 MOV r3,r2 |L1.2988| ;;;789 { ;;;790 volatile int b; ;;;791 ;;;792 for (b=10000;b!=0;--b) 000bac e1a01003 MOV r1,r3 |L1.2992| ;;;793 { ;;;794 volatile int c; ;;;795 ;;;796 for (c=10000;c!=0;--c) 000bb0 e1a00003 MOV r0,r3 |L1.2996| 000bb4 e2500001 SUBS r0,r0,#1 000bb8 1afffffd BNE |L1.2996| 000bbc e2511001 SUBS r1,r1,#1 ;792 000bc0 1afffffa BNE |L1.2992| 000bc4 e2522001 SUBS r2,r2,#1 ;788 000bc8 1afffff7 BNE |L1.2988| ;;;797 { ;;;798 ; ;;;799 } ;;;800 } ;;;801 } ;;;802 } 000bcc e12fff1e BX lr ;;;803 ENDP
are r0 r1 r2 r3 all return values? have keil got big code problems? no!
plz wake up and read.
Always yo're freind.
Zeusti.
you see, I have provided a quote which makes you look bad because you made a totally unfounded, repeated and fantastic claim that is (as far as I can tell; if somebody knows better please do correct me and justify the "professor"!) wrong. you showed a piece of assembly that further proves that you don't understand the problem at hand. I am still waiting. show me a quote or a piece of code that proves you point; show me that apart from register R1 to R4 in thumb mode, a program does not need to preserve the processor context (unless the register is shadowed by the mode itself, or course!!!!). I'm still waiting.
are you sure this code is compiled at ARM mode?
Tapeer,.
YES IT IS ARM MODE!
TRY IT UR SELF!
leave the compilers aside. can you provide a quote from the documentation founding your claim? how many times do I need to ask? come on, show us. I'm still waiting. If you can then I am wrong - not the end of the world. but you must show the quote first (I didn't find it).
i told u so many many many times b4 but u seem prejudiced aginst things i say.
look at
infocenter.arm.com/.../IHI0042C_aapcs.pdf
page 16
A subroutine must preserve the contents of the registers r4-r8, r10, r11 and SP (and r9 in PCS variants that designate r9 as v6).
it does not say must preserve r0-r3. dos it?
why does ity not say r0-r3? bcoz they do not need preserve.
i think i am correct
now plz. u reciover { and maybe apologise }.
Zeusti
(i bare no gruges)
I will not provide a quote but in this particular instance you are right - R0-R3 can freely be corrupted at any processor mode (I don't know the M3).
Based on: infocenter.arm.com/.../IHI0042C_aapcs.pdf
5.1.1 This paragraph seems to indicate that you need not preserve r0 to r3:
r0 named scratch register 1 ... r3 named scratch register 3
and: "The first four registers r0-r3 (a1-a4) are used to pass argument values into a subroutine and to return a result value from a function. They may also be used to hold intermediate values within a routine (but, in general, only between subroutine calls)."
the "(but, in general, only between subroutine calls)" seems to indicate that if the called function is visible to the compiler, the compiler can see if any of these registers are unused in the function. For the general case, they are assumed to be destroyed.
This also seems to indicate that r0 .. r3 need not be preserved (still 5.1.1): "A subroutine must preserve the contents of the registers r4-r8, r10, r11 and SP (and r9 in PCS variants that designate r9 as v6)."
---
Then something about using volatile in loops. We have had a debate about this earlier and not managed to find 100% proof from the C standard what goes.
The AAPCS specifies in 7.1.5 (my emphasis) "A data type declaration may be qualified with the volatile type qualifier. The compiler may not remove any access to a volatile data type unless it can prove that the code containing the access will never be executed; <v>however, a compiler may ignore a volatile qualification of an automatic variable whose address is never taken unless the function calls setjmp()."
In short, a loop with a volatile local loop variable that doesn't get the address taken may be removed. So volatile doesn't guarantee that a delay loop will survive.
<quote>
</quote>
u r magnanimous in yo're learning.
(holding no gruge)
I know, I just found it myself following the lack of response from our talented peer.
'our talented peer.'
respect at last.
ha ha ha ho ho ho
I don't know what is worst - making a mistake because I got confused with another process architecture that I used to work with, or writing delay loops that can kill people. I have a guess that you will pick the first option - well, well, well....
in other words - preserving 2 redundant registers is not going to do any harm to anyone. but writing broken C code like you do - and you brag about it even (making me laugh time after time after time...) is on the verge on criminality in certain circles.
I have still never seen a compiler remove a loop where the loop variable has been volatile. And I haven't been able to find a sentence in the C standard that clearly indicates if the compiler is allowed to, or isn't allowed to.
But the ARM document seems to say that it is an allowed, but not required optimization.
Another issue here is that you may have delay loops in a program for more than one reason.
One reason may be to make something happen once/second. Such a product isn't likely to get out on the market without you noticing that it runs at 100 times the normal speed because of the lack of delay. Any use of a loop for creating exact delays are a way to sure disaster. Using assembler or __nop() could give a minimum delay, but the loop will not be able to adjust for the interrupt load. Obivously, a timer or similar should be used when actual delay length is important.
The other reason may be to create short micro-delays in the code. You maybe need 30 NOP instructions to let an external signal settle. Using a small loop with a few __nop() consumes less code space than having all the __nop() in a long sequence. For ARM mode, 30 nop instructions would consume 120 bytes. As long as the compiler treats the __nop() as having a side effect it isn't allowed to optimize away, such software loops should be ok, and shouldn't even need any "volatile" on the loop variable. Such a loop will not create a fixed delay, but instead a minimum delay. But that is fine if the requirement is just to get enough settle time on a signal. The extra cycles for the loop instructions or from an interrupt in the middle of the delay can then be ignored.
But the bottom line here is that whenever you design critical hardware - whatever algorithms the program contains - you will have to get the software through a release acceptance test of some form. Such a test is seriously broken if it does not verify all timing means used by the software. It should verify that the real-time clock ticks one second/second with a suitable precision. If changing a couple of source-code lines rsults in a day or a week of testing, a change of compiler, processor frequency or processor model would most definitely not lead to less testing.
The issue with software delays is that the testing may see that the delay is long enough. But it can be hard to get the test to figure out potential problems if the sw delay gets extended to the maximum because of maximum interrupt loads from all possible sources during the delay. Such behaviour will require a lot of theoretical work too since a test rig has limitations.
Tapir.
<quote> but writing broken C code like you do </quote>
books and false judgements agin?
plz read the previes postings
remembar:
u only guess what i do. i know what i do!
View all questions in Keil forum