general questions regarding ARMs

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

On 2005-08-31, Michael J. Noone <nleahcim@gmail.com> wrote:

> 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?

In the case you describe, it means execution speed is going to
be limited by the flash bandwidth.  If you pick one with a
cache, that can make a huge difference.   Many ARM setups run
code from RAM because it's faster.

> 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?

You can do that if that's what you want to do.  It does tend to
speed things up.

> 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?

Some do, some don't.  Depends on resources and requirements.

> 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?

No.

By "memory" I presume you mean RAM?

> 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.

Are you asking what DMA is?  

-- 
Grant Edwards                   grante             Yow!  .. I want to perform
                                  at               cranial activities with
                               visi.com            Tuesday Weld!!

First of all sorry for not replying inline - I haven't figured out how
to do that with Google Groups just yet, and I was forced to switch to
google groups due to an ISP change.

By memory I do indeed mean RAM.

I suppose yes - I'm asking what DMA is. My embedded experience is with
AVRs only - and I've never encounted DMA when working with them.
Reading through the datasheet about DMA I was having trouble figuring
out how it was different from how an AVR handled things and what
benefit it provided.

Thanks,

-Michael

Michael J. Noone wrote:
> 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?
>
You can program through serial interface or JTAG or parallel
programmer, this is not ARM specific but more vendor specific and most
of all tool specific. Using the high end tools will giove you the most
headache because they usually do not provide direct download into flash
software (e.g. Greenhills and ARM). Compilers from IAR and Keil however
support many ARM devices from different vendors and you can directly
download your code into the flash. afaik this is possible with Atmel
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?
Yes
> 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?
This depends on tyhe memory (Flash) implementation. Wider memory
intefaces such as the Philips 128-bit wide flash provide much faster
execution than a 32-bit wide flash as implemented on the newer Atmel
SAM7S devices and even more so than on the older devices which only
have a 16-bit bus to the flash.

> 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?
In an embedded environment you execute usually from both memories. If
your flash is slower than the clock rate and narrow, you should limit
the code executed form there to non realtime critical code. You are
talking about Linux, then all your code has to be non realtime critical
;-)

>
> 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 way! You need approx 4 MB of RAM to run Linux preferably 16 MB+

>
> 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.
Basically DMA does in one cycle (get some data from location a and
store it in location b) what otherwise needs a whole lot more cycles as
the ARM architecture is a Risc based architecture. That means all data
transfer goes through registers no memory to memory transfers (that's
what the DMA is doing).



>
> Sorry for asking so many questions - I'm just very new to the ARM
> world. Thanks!
> 
> -Michael J. Noone

On 2005-08-31, Michael J. Noone <nleahcim@gmail.com> wrote:

> First of all sorry for not replying inline - I haven't figured out how
> to do that with Google Groups just yet, and I was forced to switch to
> google groups due to an ISP change.

Hmm. I've seen instructions on how to follow-up properly using
GG, but I don't have a link handy.

> I suppose yes - I'm asking what DMA is. My embedded experience is with
> AVRs only - and I've never encounted DMA when working with them.
> Reading through the datasheet about DMA I was having trouble figuring
> out how it was different from how an AVR handled things and what
> benefit it provided.

DMA allows you to set up a block transfer operation to transfer
a block of memory from one place to another.  You
configured source address, destination address, and count by
writing to registers in the DMA controller.  Then you tell the
DMA controller to "go", and the data is transferred while the
CPU goes off and does other things. The DMA controller will use
bus cycles that are idle or it will pause the CPU and "steal"
bus cycles if it has to.

When the transfer is done, you can usually configure the
controller to cause an interrupt.

It's basically a memcpy() operation that's done by hardware, in
the background.  Typically the source and destination pointers
can be configured to auto-increment (typically for blocks of
memory) or not (typically used for peripheral I/O registers).

Let's say I have a buffer containnig 4K of data that I want to
send out the UART.  I do something like this:

DmaController.sourcePtr = &buffer;
DmaController.sourceMode = AutoIncrement;
DmaController.destPtr = UART.txDataReg;
DmaController.destMode = NoIncrement;
DmaController.trigger = UARTtx;
DmaController.commandReg = Start;

Then I go off and do whatever else I want to do while the DMA
controller sends the buffer full of data out the UART.

Similar for receiving data or for copying a block of memory
from one place to another in RAM.

-- 
Grant Edwards                   grante             Yow!  I'm young... I'm
                                  at               HEALTHY... I can HIKE
                               visi.com            THRU CAPT GROGAN'S LUMBAR
                                                   REGIONS!

On 2005-08-31, Grant Edwards <grante@visi.com> wrote:

> Let's say I have a buffer containnig 4K of data that I want to
> send out the UART.  I do something like this:
>
> DmaController.sourcePtr = &buffer;
> DmaController.sourceMode = AutoIncrement;
> DmaController.destPtr = UART.txDataReg;
> DmaController.destMode = NoIncrement;
> DmaController.trigger = UARTtx;

  DmaController.count = 4096;
  
> DmaController.commandReg = Start;

Oops, forgot a step.

-- 
Grant Edwards                   grante             Yow!  They don't hire
                                  at               PERSONAL PINHEADS,
                               visi.com            Mr. Toad!

Michael J. Noone wrote:
> First of all sorry for not replying inline - I haven't figured out how
> to do that with Google Groups just yet, and I was forced to switch to
> google groups due to an ISP change.
>
> By memory I do indeed mean RAM.

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.

>
> I suppose yes - I'm asking what DMA is. My embedded experience is with
> AVRs only - and I've never encounted DMA when working with them.
> Reading through the datasheet about DMA I was having trouble figuring
> out how it was different from how an AVR handled things

AVR memories are internal.  ARM memories are usually external.  DMA
means transferring from another external device without using the CPU.

> and what benefit it provided.

Usually faster.

> Thanks,
> 
> -Michael

Michael J. Noone wrote:
> 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?

The JTAG interface is a backdoor into the processor chip at
the boundary between the processor core and on-chip peripherals.
On an AT91xxxxx chip this is the boundary between the ARM part
and Atmel part of the chip.

You can read and write the processor registers and make
the processor run single instructions or start the processor
running. The JTAG loaders use this to write a
Flash writing program and the desired Flash contents into
the system RAM and then use the writing program to copy
the contents into the Flash chip.

> 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?

It's a bit more complicated with ARMs. The processor starts
by fetching the first instruction at address 0 which should
for this purpose be in permanent memory (e.g. Flash). On the
other hand, the processor exception vectors are in the lowest
8 fullwords (32 bytes) of memory, and it's desirable to have
them in writable memory.

The dilemma is solved by the EBI (External Bus Interface) which
locates the first chip select (CS0-) at address zero after a
hardware reset. The chip select registers can then be programmed
by the Flash code, and the new values taken into use with the
Cancel Remap EBI command. The change is a bit tricky, as it's
not desirable to lose the code memory during the switch.

> 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?

The memory is too small even for an ucLinux version. Of the
Atmel chips, full Linux needs a memory mapping unit, and
only AT91RM9200 has one.

> 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 PDC makes it possible to run autonomous serial block
I/O on the Atmel chips. It's not a general DMA unit.

On the ARM7TDMI, much of the DMA-like functionality can
be implemented using the FIQ Fast interrupt.

> Sorry for asking so many questions - I'm just very new to the ARM
> world. Thanks!

Welcome - an ARM is not an impossible beast to tame.
Been there - done that.

HTH

-- 

Tauno Voipio
tauno voipio (at) iki fi

Thank you Grant - that was a very clear explanation. That really clears
things up for me.

-Michael

On Wed, 31 Aug 2005 20:40:42 -0000, Grant Edwards <grante@visi.com>
wrote:

>On 2005-08-31, Michael J. Noone <nleahcim@gmail.com> wrote:
>
>> First of all sorry for not replying inline - I haven't figured out how
>> to do that with Google Groups just yet, and I was forced to switch to
>> google groups due to an ISP change.
>
>Hmm. I've seen instructions on how to follow-up properly using
>GG, but I don't have a link handy.

I've never used it myself, but IIRC, you click on something called
"show options" which reveals a different "Reply" button, and use that
rather than the "Reply" button at the bottom of the article.

HTH,

                               -=Dave
-- 
Change is inevitable, progress is not.