general questions regarding ARMs

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.

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

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

No.

By "memory" I presume you mean RAM?

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

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.

Yes

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.

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 ;-)

No way! You need approx 4 MB of RAM to run Linux preferably 16 MB+

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

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

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!

DmaController.count = 4096;

Oops, forgot a step.

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

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.

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

Usually faster.

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.

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.

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.

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.

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

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.

You click "Show Options" near the top, which expands to show... er... options. One of those options is Reply - if you click it, you get a quoted reply window.

The reply link at the bottom is semi-broken, it seems like it only works properly once in a session.

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

think so? the worse case FIQ latency is pretty huge on the ARM7TDMI's I've work on to make "software DMA" pretty impractical, which is the reason I thought manufacturers are offering PDC's and the like on these devices

Well I should mention I'm a college student (3rd year EE at UIUC) so I was hoping to use some of the free tools out there. What options would that leave me?

Right now I'm planning on using a SAM7X.

Oh - everything needs to be realtime for this. I thought there were some special linux kernels designed to run real time code?

Any idea if that much RAM could be added to an Atmel ARM? I skimmed through the datasheet to see if it had any sort of external memory controller - and I didn't see one, but I might not be looking for the right thing.

Got it. Thanks for your help!

-Michael

Interesting. Is this how a boot loader would copy code to an ARM as well?

Sounds quite complicated - I think I like the AVR initialization process better :)

Are there any operating systems designed for some of the less powerful ARMs? Or am I stuck writing everything on my own? I should mention almost everything that this chip will be doing will be real time.

Excuse my ignorance, but what is the difference between this and a normal DMA unit?

Thanks,

-Michael

from the datasheet "Internal High-speed SRAM, Single-cycle Access at Maximum Speed". By external do you mean a seperate chip?

Thanks,

Michael

Excellent - I had just assumed that reply was teh same as at the bottom of each post, which isn't inline. I like how clearly it's labeled.

Sure. Two that I've used are:

eCos:

Free (community supported). Still probably a bit too big for your resources.

Free for educational use if you buy the (very good) book. Should run nicely in 64K/256K. If you've never used an RTOS before, the book is worth reading.

It should be trivial to port XMK, but that might be a bit much if you've never done RTOS stuff before.

There are probably at least a dozen commercial RTOSes, but since you're a studen I doubt you've got a couple grand to spare for an RTOS.

FIQ is just an interrupt pin. The ARM has two interrupt inputs. The "normal" one and the "fast" one. FIQ is the "fast one".

--
Grant Edwards                   grante             Yow!  .. does your DRESSING
                                  at               ROOM have enough ASPARAGUS?
                               visi.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,

-Michael

What's "best" depends on your requirements. The Gnu toolchain for ARM is a solid, professional-quality toolchain. And it's free.

Yes.

As long as it has a standard ARM instruction set, the Gnu toolchain will work fine.

--
Grant Edwards                   grante             Yow!  .. I
                                  at               feel... JUGULAR...
                               visi.com

What I'm more worried about is all the register names and locations. I mean, with AVRs you need a file that has the memory locations of each register to be able to produce code. Would such a file be available for the SAM7X, being that it isn't even available yet?