general questions regarding ARMs

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

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

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

Probably.  If not, create one.

-- 
Grant Edwards                   grante             Yow!  ... I think I'm
                                  at               having an overnight
                               visi.com            sensation right now!!

joep wrote:
> "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
> 

Of course. it's not as fast as the real cycle-stealing DMA,
but it's fast enough for e.g. floppy data.

I'm using it on an AT91R40008 running at 4 MHz (yes, less than
10 % of rated, due to power limitations) and collecting data
from an A/D at hundreds of kHz. On another construction, FIQ
fits the bill in refreshing a LCD panel at 70 kHz.

-- 

Tauno Voipio
tauno voipio (at) iki fi

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

Kind of ... This is the way to write the initial boot loader
onto the Flash chip.

A boot loader is a piece of code running at the
bottom of the Flash and getting the data in in whatever
way it sees fit. Of course, the write to the Flash has
to be done in a way suitable for the Flash chip. There
is one complication, though: the Flash write code cannot
run from the Flash being written, as the chip cannot
be read during the erase or write cycle. The solution
is to copy the core of the write code into RAM and run it
from there.

In my constructions, there is a piece of boot code
on the first Flash segment (also called sector). The
rest of the Flash chip is handled as a disk with a
simple file system. The boot code is able to read
the file system and load an executable into the RAM
and run it. Alternatively, the boot can read an
executable binary from the outside (serial line or
Ethernet/BOOTP/TFTP) and run it. The boot code is loaded
with JTAG using the process above and all the rest
is then loaded using the boot code or an utility
program loaded by the boot.

>>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 code is not as complicated as it sounds - I counted
the instructions in my code for the AT91's: there are seven
instructions in the part setting up the memory chip selects
and remapping.

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

Yes, there are. You got a good answer from another poster.

I'm using my own kernel and TCP/IP stack.

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

Only the fact that is is tied on-chip to the built-in
serial channels, and so unusable for other peripherals.

HTH

-- 

Tauno Voipio
tauno voipio (at) iki fi

On 31 Aug 2005 15:11:54 -0700, "Michael J. Noone" <nleahcim@gmail.com>
wrote:

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

JTAG is a wonderful way to debug. I found that the "Angel debug
monitor" on the Atmel eval boards seemed to have some issues with IAR
embedded workbench.  With JTAG, loading and debugging is very
straightforward.  I got the example project from uc-os11 from the
web/and book running quite easily, even though I don't have much
experience and the example code had some new features that were not
supported in the older OS source code from the book.  I made some
slight change to allow it to compile, then it seemed to run fine.

I suggest that you go to the IAR website and look at their kickstart
kits.  That includes the JTAG interface and development board.  The
free IAR tools are limited to 32kB code size, which will get you
started.  It seems to me that CGG tool chain is only a realistic
option if you have a lot of patience.  I also believe that the
efficiency is not the best relative to the specialist embedded
compilers.

best regards,
Johnny.

On 31 Aug 2005 13:07:44 -0700, "Michael J. Noone" <nleahcim@gmail.com>
wrote:

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

In general, the ARM core executes instructions in 1/2/3 cycles
depending on whether memory is involved. Non-memory instructions
nearly all take one cycle. If the memory system can't provide
opcodes/data fast enough, the core stalls.

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.

We're running embedded web servers (CGI and ASP, Telnet ...) on
LPC2000 parts just using the internal Flash and RAM.

Until you say what you're going to do with the system, I can't say
whether you eed a 'big' ARM or a 'little' ARM.

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

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

Check out http://www.freertos.org/ for a simple free RTOS. It has quite a 
good tutorial on there as well which enough to get up and running but a 
little bit of prior knowledge about OS theory will grease the wheels a 
little. I've run it in a Phillips LPC2129 and it was able to jump straight 
in a get a few tasks set up. 

"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:

I've not used Atmel ARM parts but I have used the Phillips ones and the 
fundamental principles are the same,. I bought a Keil MBC2100 development 
kit which is based around an LPC2129 and has a serial port, CAN controller, 
a few LEDs, a pot and a couple of push switches to get you started. It costs 
about GBP75 for the board or GBP250 for the board and a JTAG programmer. It 
will accept programs via the serial port so you don't have to use JTAG but 
if you corrupt it's boot loader then you'll have to get the JTAG probe out.

It ran FreeRTOS quite comfortably and it only took a morning or so using the 
FreeRTOS on-line manual to get some tasks up and running. I even managed to 
get the serial port to send a few strings.

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

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

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