general questions regarding ARMs

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

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

Schwob US wrote:
> 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.

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?

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

Right now I'm planning on using a SAM7X.

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

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

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

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.

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

Got it. Thanks for your help!

-Michael

Tauno Voipio wrote:
> 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.

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

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

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

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

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.

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

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

> Welcome - an ARM is not an impossible beast to tame.
> Been there - done that.
>
> HTH
> 
> -- 
> 
> Tauno Voipio
> tauno voipio (at) iki fi

Thanks,

-Michael

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
Maximum Speed". By external do you mean a seperate chip?

Thanks,

Michael

Dave Hansen wrote:
> On Wed, 31 Aug 2005 20:40:42 -0000, Grant Edwards <grante@visi.com>
> wrote:
>
> 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

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.

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

>> 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.
>
> Are there any operating systems designed for some of the less powerful
> ARMs?

Sure.  Two that I've used are:

  eCos: http://sources.redhat.com/ecos/ Free (community
        supported). Still probably a bit too big for your 
        resources.

  http://www.ucos-ii.com/
        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. http://www.shift-right.com/xmk/index.html

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.

>> On the ARM7TDMI, much of the DMA-like functionality can
>> be implemented using the FIQ Fast interrupt.
>
> Excuse my ignorance, but what is the difference between this and a
> normal DMA unit?

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

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

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

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

> Will that be able to compile code for any ARM chip?

Yes.

> Specifically - I'm worried as I'm planning on using the SAM7X,
> which isn't even yet on Atmel's website.

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            

Grant Edwards wrote:
> On 2005-09-01, Michael J. Noone <nleahcim@gmail.com> wrote:
>
> > 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?
>
> What's "best" depends on your requirements.  The Gnu toolchain
> for ARM is a solid, professional-quality toolchain.  And it's
> free.
>
> > Will that be able to compile code for any ARM chip?
>
> Yes.
>
> > Specifically - I'm worried as I'm planning on using the SAM7X,
> > which isn't even yet on Atmel's website.
>
> 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?