EmbeddedRelated.com
Forums

general questions regarding ARMs

Started by Michael J. Noone August 31, 2005
Being able to collect A/D at hundreds of khz at 4Mhz using FIQ is
excellent (assuming you have time left over to do something useful
during the collection).

The ARM I'm currently working with (ADuC702x) has a 1Mhz 12 bit A/D, 50
cycle worst case FIQ latency, at top speed of 40Mhz thats 1.2 usec, at
4 Mhz it would be 12 usec, nowhere near fast to process an A/D at
hundreds of kHz using FIQ like you are. I have to sit there and poll
the A/D to collect the data at that rate.

joep wrote:
> Being able to collect A/D at hundreds of khz at 4Mhz using FIQ is > excellent (assuming you have time left over to do something useful > during the collection). > > The ARM I'm currently working with (ADuC702x) has a 1Mhz 12 bit A/D, 50 > cycle worst case FIQ latency, at top speed of 40Mhz thats 1.2 usec, at > 4 Mhz it would be 12 usec, nowhere near fast to process an A/D at > hundreds of kHz using FIQ like you are. I have to sit there and poll > the A/D to collect the data at that rate. >
It seems that your FIQ handler is in some way fishy (or the base code keeps FIQ off for long times). Here's my fiq handler for the data collection: (It's written in GCC embedded assembly code) /* FIQ bank register usage: r8, -> destination buffer, -> AIC set request r9, pixel pair counter r10, -> I/O read port r11, -> PIO output reset port r12, capture control bit r13, work register r14, return link register */ ".code 32\n" "fiq1:\t" "ldr r13,[r10]\n\t" /* get a pixel pair */ "str r13,[r8],#4\n\t" /* save it - bump pointer */ "subs r9,r9,#1\n\t" /* bump count - done? */ "subnes pc,lr,#4\n\t" /* no - dismiss */ "str r12,[r11]\n\t" /* stop capture & FIQ */ "ldr pc,fiq2\n" /* continue to completion */ "fiq2:\t.word fiq4\n" /* -> completion handler */ "fiq3:\n" /* handler end label */ /* Fast interrupt completion in normal text segment */ /* ------------------------------------------------ */ "fiq4:\n\t" "ldr r8,fiq5\n\t" /* -> AIC base */ "mov r13,%2\n\t" /* get AIC SWI bit */ "str r13,[r8,%3]\n\t" /* cause SWI */ "subs pc,lr,#4\n" /* dismiss the FIQ */ "fiq5:\t" ".word at91aic\n\t" /* -> AIC base */ ------ The core handling is at the FIQ vector address (byte address 0x1e). There are just 4 instructions in the fast loop: ldr for reading the data, str for storing it, subs for counting and subnes for dismissing the FIQ. The execution time is far under 50 clocks: after the initial interrupt latency, it should use 5 clocks. -- Tauno Voipio tauno voipio (at) iki fi
> 1. programming: My understanding of programming an ARM is that you do > it with a JTAG cable. I was looking at this one, specifically: > http://olimex.com/dev/arm-jtag.html as it is fairly inexpensive. Is > this a good plan? Bad plan? I've also heard of boot-loading. Is this > possible on Atmel ARMs? if it is, does this only temporarily load code > into the chip, or permanently load it in the flash?
Atmel ARMs w Flash has an internal Bootloader. The AT91RM9200 has also an internal bootloader, but it is different.
> > 2. boot process: when an AVR turns on it begins by executing the first > line of code in the flash - the reset interrupt. Is this how ARMs work? > I noticed that the ARMs that I was looking at can only access their > flash in a single cycle at about half the clock speed - so how would > executing code work for this? I mean how would it run at double that > speed if it couldn't access the code? Does all code get loaded into the > RAM and executed there?
If you execute in Thumb mode, the memory controller will fetch two instructions per two clock cycles, so you get one instruction per clock cycle in average until you do a jump. Then you have a two clock cycle fetch. Executing from SRAM will ensure you always get 1 instruction per clock even in ARM mode.
> 3. operating systems: in my experience with AVRs I've never had an > operating system running onboard. Is this what is done on ARMs > generally? I've noticed that there is ARM Linux - could that run on a > 55Mhz Atmel ARM based off of a ARM7TDMI with 64KB of memory and 256KB > of flash? Would this even make sense? >
No, Linux needs just more. If you want to run Linux, then the AT91RM9200 is a better choice.
> 4. DMA: the chip I'm using boasts about its Peripheral DMA Controller > (PDC). It says that it greatly reduces the overhead on the processor. > But reading about it, I am having trouble understanding how DMA differs > from no DMA.
The DMA allows you to send/receive large blocks of data, so you do not get so many interrupts. Each interrupt will have to handle more than one byte.
> > Sorry for asking so many questions - I'm just very new to the ARM > world. Thanks! > > -Michael J. Noone >
-- A. P. Richelieu
"Michael J. Noone" <nleahcim@gmail.com> skrev i meddelandet 
news:1125539621.631035.224550@g14g2000cwa.googlegroups.com...
> OK - I just remembered one more really important question: What > programs should I use? Right now in all the AVR development I do I use > WinAVR and code in C. I've seen GNU ARM - is that the best thing to > use?Will that be able to compile code for any ARM chip? Specifically - > I'm worried as I'm planning on using the SAM7X, which isn't even yet on > Atmel's website. Thanks, >
It is on the web site now! You can compile code using any compiler as long as you can get header files. -- A. P. Richelieu
> -Michael >
> It is on the web site now! > You can compile code using any compiler as long as you can get header files.
Indeed it is - they must have posted it in the last day or two as I checked quite recently. But are header files for it available? I suppose now that the datasheet is released if they aren't already available they will be soon. -Michael
Michael J. Noone wrote:
> linnix wrote: > > > Static or SDRAM? Most ARMs come with kilo bytes of static, but upto > > hundred mega bytes of external SDRAM. You can jtag into RAM or boot > > load from external flash. > > from the datasheet "Internal High-speed SRAM, Single-cycle Access at
Internal SRAM are ususally 32K to 64K.
> Maximum Speed". By external do you mean a seperate chip?
Yes, external SDRAM chips upto 256M, most ARMs has SDRAM controller only. Some can stack dies, which can be argued as internal or external.
> > Thanks, > > Michael
"Michael J. Noone" <nleahcim@gmail.com> wrote in message 
news:1125518864.246836.67700@g43g2000cwa.googlegroups.com...
> Hi - I'm fairly certain I'm going to use an ARM in a project I'm > working on. I have a good deal of experience with Atmel AVRs, but I > have never used an ARM before. So I was wondering if you all could > answer a couple basic questions regarding ARMs: > > 1. programming: My understanding of programming an ARM is that you do > it with a JTAG cable. I was looking at this one, specifically: > http://olimex.com/dev/arm-jtag.html as it is fairly inexpensive. Is > this a good plan? Bad plan? I've also heard of boot-loading. Is this > possible on Atmel ARMs? if it is, does this only temporarily load code > into the chip, or permanently load it in the flash? > > 2. boot process: when an AVR turns on it begins by executing the first > line of code in the flash - the reset interrupt. Is this how ARMs work? > I noticed that the ARMs that I was looking at can only access their > flash in a single cycle at about half the clock speed - so how would > executing code work for this? I mean how would it run at double that > speed if it couldn't access the code? Does all code get loaded into the > RAM and executed there? > > 3. operating systems: in my experience with AVRs I've never had an > operating system running onboard. Is this what is done on ARMs > generally? I've noticed that there is ARM Linux - could that run on a > 55Mhz Atmel ARM based off of a ARM7TDMI with 64KB of memory and 256KB > of flash? Would this even make sense? > > 4. DMA: the chip I'm using boasts about its Peripheral DMA Controller > (PDC). It says that it greatly reduces the overhead on the processor. > But reading about it, I am having trouble understanding how DMA differs > from no DMA. > > Sorry for asking so many questions - I'm just very new to the ARM > world. Thanks! > > -Michael J. Noone
For a cheap arm 7 dev boards look at http://www.sparkfun.com/shop/index.php?shop=1&cart=380020&cat=73& boards are made by olimex but its a lot easier to buy from sparkfun.com They also have a good range of sensors Alex