C- Programming for ARM Microcontrollers

Started by tech...@gmail.com October 23, 2006
hi

Can someone point me to some C- Programming Tutorials for ARM7
Microcontrollers???

regards

Krish

techie.embedded@gmail.com wrote:

> Can someone point me to some C- Programming Tutorials for ARM7 > Microcontrollers???
My first book meets this description :) <http://www.amazon.com/exec/obidos/ASIN/0750676094/zws-20>
"larwe" <zwsdotcom@gmail.com> wrote in message 
news:1161605840.574481.27540@i3g2000cwc.googlegroups.com...
> > techie.embedded@gmail.com wrote: > >> Can someone point me to some C- Programming Tutorials for ARM7 >> Microcontrollers??? > > My first book meets this description :) > > <http://www.amazon.com/exec/obidos/ASIN/0750676094/zws-20>
BTW, chalk up another sale. I ordered "So you wanna" from Amazon on Friday. Only GBP16.49 at the moment as well so I'm glad I didn't buy the one at ESS that they wanted 21 for.
Hi

thanks for that.. but any online tutorials that u remember to have
seen????

thanks

Krish

larwe wrote:
> techie.embedded@gmail.com wrote: > > > Can someone point me to some C- Programming Tutorials for ARM7 > > Microcontrollers??? > > My first book meets this description :) > > <http://www.amazon.com/exec/obidos/ASIN/0750676094/zws-20>
> Hi
> > thanks for that.. but any online tutorials that u remember to have > seen????
What is it you want to know? More about C programming, or more about ARM processors? Once you know the byte alignment, data sizes, interrupt structure, etc of the ARM then C is just C. The alignment, data sizes, etc are not that relevant to C and more ARM specific. Regards, Richard. + http://www.FreeRTOS.org + http://www.SafeRTOS.com for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430 Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC
Tom Lucas wrote:

> BTW, chalk up another sale. I ordered "So you wanna" from Amazon on > Friday. Only GBP16.49 at the moment as well so I'm glad I didn't buy the > one at ESS that they wanted 21 for.
Yay, my bank manager thanks you :) Please let me know what you think. I'm having real trouble getting my next book project off the ground, mainly because people keep thrusting excruciatingly interesting projects my way. I remember sleeping, once; it was good.
"larwe" <zwsdotcom@gmail.com> wrote in message 
news:1161696142.695443.267990@i3g2000cwc.googlegroups.com...
> > Tom Lucas wrote: > >> BTW, chalk up another sale. I ordered "So you wanna" from Amazon on >> Friday. Only GBP16.49 at the moment as well so I'm glad I didn't buy >> the >> one at ESS that they wanted 21 for. > > Yay, my bank manager thanks you :) Please let me know what you think.
I will do.
> I'm having real trouble getting my next book project off the ground, > mainly because people keep thrusting excruciatingly interesting > projects my way. I remember sleeping, once; it was good.
It's getting that way for me too - I'm not sure when I'll find time to read the book! I used to have a slot on my train journey but my GP2X and Scrubs series 4 have that covered for a couple of weeks.
Tom Lucas wrote:
> "larwe" <zwsdotcom@gmail.com> wrote in message >> techie.embedded@gmail.com wrote: >> >>> Can someone point me to some C- Programming Tutorials for ARM7 >>> Microcontrollers??? >> >> My first book meets this description :) >> >> <http://www.amazon.com/exec/obidos/ASIN/0750676094/zws-20> > > BTW, chalk up another sale. I ordered "So you wanna" from Amazon > on Friday. Only GBP16.49 at the moment as well so I'm glad I > didn't buy the one at ESS that they wanted 21 for.
That is about 30 USD or less, and quite attractive. So I checked the link Amazon, and they want about 60 USD for it. What goes on? -- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net>
"CBFalconer" <cbfalconer@yahoo.com> wrote in message 
news:453E21AE.E7BB5B24@yahoo.com...
> Tom Lucas wrote: >> "larwe" <zwsdotcom@gmail.com> wrote in message >>> techie.embedded@gmail.com wrote: >>> >>>> Can someone point me to some C- Programming Tutorials for ARM7 >>>> Microcontrollers??? >>> >>> My first book meets this description :) >>> >>> <http://www.amazon.com/exec/obidos/ASIN/0750676094/zws-20> >> >> BTW, chalk up another sale. I ordered "So you wanna" from Amazon >> on Friday. Only GBP16.49 at the moment as well so I'm glad I >> didn't buy the one at ESS that they wanted 21 for. > > That is about 30 USD or less, and quite attractive. So I checked > the link Amazon, and they want about 60 USD for it. What goes on?
I guess more guys in the US wanna be hardware engineers so there's no need to discount it. Also, people in the UK normally avoid American books unless there is no alternative so Amazon may have felt it needed to pull the price down due to the competition in this field from homegrown books.
"Tom Lucas" <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote in 
message news:1161702618.83532.0@iris.uk.clara.net...

> I guess more guys in the US wanna be hardware engineers so there's no
I misspelt "embedded". oops
On Mon, 30 Oct 2006 08:30:22 +0000, Chris Hills wrote:

>> >>With the trend of semiconductor manufacturers releasing cheap 32-bit arm >>microcontrollers with increasing sizes of flash and SRAM, efficiency in >>the compiler is becoming less and less of an issue. > > This is not correct. >
Maybe not for the type of work you get involved with, but it is for me. I can get a Atmel arm, 64K flash and 16K sram, from farnell in 100 off for £3.25. The price point and amounts of Flash/SRAM mean I don't care how efficient the compiler is. OK - an efficient compiler means I can download the compiled software quicker.
>>Again, with 32-bit processors at traditional 8-bit prices, compiling and >>testing on a PC, rather than a simulator, becomes possible. Then you get >>the advantages of using a PC. > > What advantages?
Well, a PC has lots of disk space for storing test data. Also tests run quicker. It's also easier change the tests you are performing - no need to download a newly compiled test or set of tests to a target. And you don't need to use a terminal + send data over serial links to look at your results. Just compiling code, running it, and instantaneously getting the results is kind of good. Regards, Paul.
Robert Adsett wrote:
> Stefan Reuther wrote: > > That would have been a little harder if they'd used other platform > > specifics such as *(char far*)0x00400017, asm { ... }, <dos.h> etc., > > even if that'd have saved a cycle here and there. > > Well, once you include any I/O other than stdio you are definitely in > for a porting job. Even that wasn't portable across DOS compilers. Of > course stdio isn't going to be a lot of good on a lot of embedded
Well that was bad phrasing. I meant I/O wasn't portable across DOS compilers. I've run into three similar schemes and seen reference to a fourth. AFAIK, stdio was portable. Robert
Stefan Reuther wrote:
> Agreed. I didn't have the pleasure(?) to code for a 8051 yet, but as > long as it's just the memory allocation directives, you can probably > easily #define them away if needed. I just pumped a 15 year old DOS C > source through a C++ compiler, the only thing I had to change was to add > a '#define far' (their excuse for not having to use Huge memory model > which generates less efficient code), and convert the K&R function > headings to prototypes.
Well huge model does generate less efficient code but as I remember the only advantage it offered over large was that it could address across a 64K boundary in a single unit. If you had no single allocation larger than 64K there was no reason to use huge. Most of the pointer modifiers I ever saw on x86 code were mis-guided optimizations. The code would have been clearer and just as fast and small if the authours had just picked the right model to begin with and left off the modifiers. Of course this wasn't helped by the fact that there was no agreed definition for all the various memory models. Microsoft, Borland and Watcom all had different definitions.
> That would have been a little harder if they'd used other platform > specifics such as *(char far*)0x00400017, asm { ... }, <dos.h> etc., > even if that'd have saved a cycle here and there.
Well, once you include any I/O other than stdio you are definitely in for a porting job. Even that wasn't portable across DOS compilers. Of course stdio isn't going to be a lot of good on a lot of embedded targets. Robert
Chris Hills wrote:
> In article <ei26ue.1g4.1@stefan.msgid.phost.de>, Stefan Reuther >> Chris Hills wrote: >>> For example on 8051 most (80%) of the code adheres to the Keil C51 (and >>> there are far more 51's out there than anything else) >> >> But probably it is much easier to find a compiler for a non-8051 CPU >> that adheres to ISO C90 than to find one that adheres to Keil C51's >> language. > > Yes but writing in pure C90 etc is not going to be a very efficient > 8051 program by a long way.
Agreed. I didn't have the pleasure(?) to code for a 8051 yet, but as long as it's just the memory allocation directives, you can probably easily #define them away if needed. I just pumped a 15 year old DOS C source through a C++ compiler, the only thing I had to change was to add a '#define far' (their excuse for not having to use Huge memory model which generates less efficient code), and convert the K&R function headings to prototypes. That would have been a little harder if they'd used other platform specifics such as *(char far*)0x00400017, asm { ... }, <dos.h> etc., even if that'd have saved a cycle here and there.
>> I routinely compile parts of my embedded code for Win32 - to have >> automated test suites, for example. Whereas my embedded device is >> allowed to require half an hour to decode a 100 MB MP3 file, having my >> PC run the same decoder in a couple of seconds surely helps to validate >> it. Hence, I try to make most parts of my code understandable to PC >> compilers, and ISO C90 (and C++98, in my case) is some sort of a least >> common denominator. > > This is OK if the target has the same size ie 8/16/32 bit as the PC. If > not it is a bit pointless.
8-bit bytes are nice, but 16/32/64 bit word size shouldn't matter thanks <stdint.h>.
> You should write the code for the target and > test in the simulator for the target.
My simulator does a mere 10000 cycles/second, and doesn't simulate the interesting peripherals, so I've decided to ignore it. One of my modules is a CD file system implementation. Testing that on the target means burning 150 CDs with different file systems, ISO 9660 violations, etc on them, and spending half a day juggling discs in and out. Testing that on the PC means swapping a simple fopen/fread/fclose in place of the ReadBlock routine, and have an automated test driver run all these tests in a matter of seconds from a directory with .isos in them. The only real drawback I had to make to make this possible is to avoid '#pragma pack' and friends, and manually assemble the multi-byte values. Of course one must make sure that the test has some resemblance to what actually happens on the target. For that, I trust my debugging skills :) Stefan
In article <pan.2006.10.29.16.42.26.853168@tiscali.co.uk>, Paul Taylor 
<paul_ng_pls_rem@tiscali.co.uk> writes
>On Sun, 29 Oct 2006 12:32:21 +0000, Chris Hills wrote: > >> >> Yes but writing in pure C90 etc is not going to be a very efficient >> 8051 program by a long way. >> > >With the trend of semiconductor manufacturers releasing cheap 32-bit arm >microcontrollers with increasing sizes of flash and SRAM, efficiency in >the compiler is becoming less and less of an issue.
This is not correct.
>I wonder how long it will be before compiler efficiency is a moot point >for a vast percentage of embedded applications?
It is actually becoming more important.
>> This is OK if the target has the same size ie 8/16/32 bit as the PC. If >> not it is a bit pointless. You should write the code for the target and >> test in the simulator for the target. > >Again, with 32-bit processors at traditional 8-bit prices, compiling and >testing on a PC, rather than a simulator, becomes possible. Then you get >the advantages of using a PC.
What advantages? -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
On Sun, 29 Oct 2006 12:32:21 +0000, Chris Hills wrote:

> > Yes but writing in pure C90 etc is not going to be a very efficient > 8051 program by a long way. >
With the trend of semiconductor manufacturers releasing cheap 32-bit arm microcontrollers with increasing sizes of flash and SRAM, efficiency in the compiler is becoming less and less of an issue. I wonder how long it will be before compiler efficiency is a moot point for a vast percentage of embedded applications?
> This is OK if the target has the same size ie 8/16/32 bit as the PC. If > not it is a bit pointless. You should write the code for the target and > test in the simulator for the target.
Again, with 32-bit processors at traditional 8-bit prices, compiling and testing on a PC, rather than a simulator, becomes possible. Then you get the advantages of using a PC.
Chris Hills <chris@phaedsys.org> writes:
> CBFalconer <cbfalconer@yahoo.com> writes
[snip]
> >or earlier C standards generally known > >as C89, C90, C95. > > SO your definition is "any of the documents that are or were ISO or US C > standards going back over the last 25 years and/or any of the CD's TC's > etc etc that are also produced by WG14 even if they are mutually > exclusive. > > That is one hell of a mess..... You are FAR better to adhere to what the > compiler does. Yes you should try and group the extensions separately > but in embedded > > >Surely you were aware of this. > > As a longstanding member of the ISO C panel I know what the C standard > is and just as importantly what it is not. > > "Close enough" is OK for horse shoes and hand grenades NOT for > programming. Things change in C from year to year.
Something's wrong with the standardization process if things are changing "year to year". The whole idea of standardization is to provide a stable and well-defined basis for production of standard-conforming products, preferably over an extended period of time.
> Chris Hills wrote: > > Stefan Reuther <stefan.news@arcor.de> writes > > >I routinely compile parts of my embedded code for Win32 - to have > >automated test suites, for example. Whereas my embedded device is > >allowed to require half an hour to decode a 100 MB MP3 file, having my > >PC run the same decoder in a couple of seconds surely helps to validate > >it. Hence, I try to make most parts of my code understandable to PC > >compilers, and ISO C90 (and C++98, in my case) is some sort of a least > >common denominator. > > This is OK if the target has the same size ie 8/16/32 bit as the PC.
Are you referring to the hardware size(s) or the implicit sizes of int, char, et al?
> If not it is a bit pointless. You should write the code for the > target and test in the simulator for the target.
It certainly is not pointless to test programming with a host having a different word size than the target. If the C compilers produce the same functionality for both the host and the target, it makes no difference where the testing is done (other than speed of execution). Using a simulator to perform testing is almost a last resort unless one wants to proceed at glacial speeds or has something that can't be tested any other way.
Chris Hills wrote:
> In article <1162076665.038472.168090@e64g2000cwd.googlegroups.com>, > Robert Adsett <sub2@aeolusdevelopment.com> writes > > > >Chris Hills wrote: > >> In article <1161784387.593457.189290@h48g2000cwc.googlegroups.com>, > >> Robert Adsett <sub2@aeolusdevelopment.com> writes > >> > > >> >techie.embedded@gmail.com wrote: > >> >> hello members. > >> >> > >> >> thanks for the last... The ARM Application Notes, i guess should serve > >> >> my purpose. > >> >> > >> >> Just another question. Does the syntax of code change when programming > >> >> in a IAR enviorment to a Keil Environment???? > >> > > >> >If you are foolhardy enough to use compiler extensions, yes. > >> > > >> >If you are disciplined enough to stick to standard C, no. > >> > >> > >> Please explain what you mean by standard C > > > >ANSI/ISO. > > Any of the version since 1989? The last poster included "all versions" > and the committee drafts etc... Even where they are mutually exclusive.
I did restrict myself a bit later :)
> >It probably makes sense to stick to C89 for true portability > >between compilers at the moment. > > You probably mean ISO C90, C89 is a local US standard. > > In any event most are at C95/6 + "some bits" of C99 > > >Consider it shorthand for avoiding compiler specific extension, > >pragmas, inline assembler, interrupt keywords etc..., etc... > > However...... Depending on what you are programming and what if any > portability is required often you are better sticking with a compiler > implementation than the C standard.
Remember the original question was (paraphrased) "Will the syntax from one compiler for ARM compiler on another compiler for ARM?" However, even disregarding that context, and dealing with the circumstance where you are dealing with a product where you never expect to change processors or compilers you are best served by sticking mainly with the standard C subset. Not only does that improve the code portability, more importantly it improves the programmers and associated tools portability. I've not yet seen a case where I'd consider inline assembler, interrupt keywords and pragmas 'better' that using assembler or rethinking the problem. I have run into compilers that give you no choice in the matter, since they offer no assembler (and sometimes no linker). Especially in the latter case though they had a legion of other problems as well. I've not had to use an 8051 derivative yet so I'll leave open the possibility that there are architectural features that forbid the use of a standard C compiler on it. OTOH with the current price trend of the ARM family maybe we'll see the 8051 family begin to restrict itself to it's current base.
> In real world SW engineering portability is NOT a priority for the vast > majority of systems An embedded system is part of something else. No one > (bar developers) buys an "embedded system" they buy a clock, camera, > car, microwave oven etc.
So? The OP was clearly contemplating switching between compilers. They weren't talking about buying a microwave oven but a compiler that would help them (learn to) develop. And considering they were talking ARM probably a larger system than a clock.
> As such the cost of the embedded system in the product has to be > minimised. That is the smallest tightest code using the smallest MCU > they can get away with the least memory and power consumption.
Cost also includes cost of development. That's minimized by using the common standardized language definition and the associated tools that support it.
> By the time they are looking at changing MCU it is because marketing > want the device to do a lot more in different ways (often with a new or > different MMI) which usually requires a of the majority of the code > will be new anyway. > > However C code should always be written in a modular style and it does > make sense to try an encapsulate areas where you talk to the hardware or > use some extensions. Other extensions you will have no choice about.
I did allude to that in the piece you elided. Yes you sometimes have to use non-C extensions but you can usually partition them and even then you are often as far or further ahead to avoid them in favour of other alternatives. In some cases you may not have an alternative but you do cut yourself off from other compilers and tools.
> For example on the 8051 placing variables in to Data, BDATa, XData etc > > Embedded SW Engineering is about pragmatically using the right tools for > the job. Not being religious.
And here I thought I was stating a rather simple fact about the portability of code between compilers on a single processor ;)
> Incidentally using pure ISO C would mean not using Linux...... It > requires GCC extensions to compile it. However I don't see anyone > complaining that Linux is not portable.
I don't know, can you compile it with Visual C++ or Borland C++? Really that arguments a bit of a non-sequiter given the original question. Robert
In article <45449DF9.8432E1A6@yahoo.com>, CBFalconer 
<cbfalconer@yahoo.com> writes
>Chris Hills wrote: >> <cbfalconer@yahoo.com> writes >> >Chris Hills wrote: >>> >... snip ... >>>> >>>> Please explain what you mean by standard C >>> >>> A C system that adheres to the ISO C standard as described in: >>> >>> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf> >> >> That document is NOT "Standard C" It is a Committee Draft. >> >> If you tell me it is "close enough" then so is ANY compiler >> implementation. You can't have it both ways. >> >>> or n869.txt (same location) >> >> Niether is that the C standard... >> >>> or earlier C standards generally known as C89, C90, C95. >> >> SO your definition is "any of the documents that are or were ISO or >> US C standards going back over the last 25 years and/or any of the >> CD's TC's etc etc that are also produced by WG14 even if they are >> mutually exclusive. ... snip ... > >Yup. That will do adequately for 99% of the problems.
As will any compiler C with extensions.
>>> Surely you were aware of this. >> >> As a longstanding member of the ISO C panel I know what the C >> standard is and just as importantly what it is not. > >Which is why I said 'surely' above. However you seem to recommend >abandoning all standards and portability.
Not at all. We need standards. However for the vast majority of embedded systems portability is NOT a requirement. Your glib comment of using "standard C" is sadly meaningless in reality.
> Somehow I don't think >you are well received in the 'ISO C panel'.
So now you know the mind of WG14 and or the NB panels...... I don't suppose you have ANY justification or support for your last statement? -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <ei26ue.1g4.1@stefan.msgid.phost.de>, Stefan Reuther 
<stefan.news@arcor.de> writes
>Chris Hills wrote: >> However...... Depending on what you are programming and what if any >> portability is required often you are better sticking with a compiler >> implementation than the C standard. >> >> For example on 8051 most (80%) of the code adheres to the Keil C51 (and >> there are far more 51's out there than anything else) > >But probably it is much easier to find a compiler for a non-8051 CPU >that adheres to ISO C90 than to find one that adheres to Keil C51's >language.
Yes but writing in pure C90 etc is not going to be a very efficient 8051 program by a long way.
>I routinely compile parts of my embedded code for Win32 - to have >automated test suites, for example. Whereas my embedded device is >allowed to require half an hour to decode a 100 MB MP3 file, having my >PC run the same decoder in a couple of seconds surely helps to validate >it. Hence, I try to make most parts of my code understandable to PC >compilers, and ISO C90 (and C++98, in my case) is some sort of a least >common denominator.
This is OK if the target has the same size ie 8/16/32 bit as the PC. If not it is a bit pointless. You should write the code for the target and test in the simulator for the target.
>> However C code should always be written in a modular style and it does >> make sense to try an encapsulate areas where you talk to the hardware or >> use some extensions. Other extensions you will have no choice about. > >Exactly. > Stefan
I don't think our positions are too far apart. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/