"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
> 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
Reply by Michael J. Noone●September 2, 20052005-09-02
> 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
Reply by A. P. Richelieu●September 2, 20052005-09-02
"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
>
Reply by A. P. Richelieu●September 2, 20052005-09-02
> 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
Reply by Tauno Voipio●September 2, 20052005-09-02
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
Reply by joep●September 1, 20052005-09-01
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.
Reply by Grant Edwards●September 1, 20052005-09-01
On 2005-09-01, Stephen Pelc <stephenXXX@mpeforth.com> wrote:
>>Samsung's ARM7 parts have a cache, and are pretty cheap (though
>>in my experience the peripherals tend to be buggy). The
>>Linksys WAPs run Samsung ARM7 parts and can be a cheap
>>"development platform" for running uCLinux.
>
> We used the S3C4510B a while ago. It had quite the nastiest
> Ethernet controller
Yup, I've used that part as well as its 5V predecessor the
'4500. The basic design of the controller wasn't too bad (it
was a bit overly complex), but there were a couple nasty bugs.
OTOH, the basic design of the internal UARTs was just plain
f*&ked up. Whoever designed the UART had no idea how flow
control on serial ports worked.
> and very buggy code examples on the development CD.
The sample code was mostly useless, and the "English" in the
documentation was entertaining if not always informative.
> Apart from that, it was dirt cheap and our client is very
> happy.
The features/dollar (even with bugs) are hard to beat. Just
ask Linksys (which I believe used the '4510 in a lot of WAPs).
> However, I have heard rumours about Samsung's commitment to
> commodity ARMs. Can anyone confirm/deny?
--
Grant Edwards grante Yow! I FORGOT to do the
at DISHES!!
visi.com
Reply by Stephen Pelc●September 1, 20052005-09-01
On Thu, 01 Sep 2005 14:45:25 -0000, Grant Edwards <grante@visi.com>
wrote:
>Samsung's ARM7 parts have a cache, and are pretty cheap (though
>in my experience the peripherals tend to be buggy). The
>Linksys WAPs run Samsung ARM7 parts and can be a cheap
>"development platform" for running uCLinux.
We used the S3C4510B a while ago. It had quite the nastiest
Ethernet controller and very buggy code examples on the
development CD. Apart from that, it was dirt cheap and our client
is very happy. However, I have heard rumours about Samsung's
commitment to commodity ARMs. Can anyone confirm/deny?
Stephen
--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Reply by Grant Edwards●September 1, 20052005-09-01
On 2005-09-01, Stephen Pelc <stephenXXX@mpeforth.com> wrote:
> The Atmel AT91 ARM7 cores mostly use a 16 bit external bus and no
> caches. The ARM9 cores are nearly always cached and the memory system
> is usually optimised for SDRAM.
>
> Of the ARM7 chips we have used, the Philips LPC2000 family's MAM
> unit is far and away the best solution for hard real-time systems. The
> downside is that it only works on internal Flash (up to 512k). The
> cached Sharp parts are pretty good too, providing you can live with
> the usual cache side-effects.
Samsung's ARM7 parts have a cache, and are pretty cheap (though
in my experience the peripherals tend to be buggy). The
Linksys WAPs run Samsung ARM7 parts and can be a cheap
"development platform" for running uCLinux.
--
Grant Edwards grante Yow! I Know A Joke!!
at
visi.com