Doug:
   I have used several compilers, and JTAG tools for RAM including the Atmel
series (quite good).

1) About the crystal, I suggest that you start using the 18.432 crystal that
ATMEL is using, and may adjust the PLL if you want a slower speed.
I am sure you may use other values, but then do not expect the USSb and
UARTS to work! And this value is easy to find (Jameco, Digikey and like..)

2) Compilers: First it is fair, to say that nowdays most tools work, but
they are not equal. Also you may want to consider the whole project before
you choose a compiler Or other component).

The first question would be the choice of the RTOS because most RTOS'es are
usually compiled (build) only with one compiler! Of course using another
compiler is possible... but extra work.

Also it is nice to get started with something which is known to work... for
hardware validation.

3) Which RTOS to use?
It really depends what you intend to do!
A really simple and good one is US/OS-II from Jean Labrosse.
I have used it but not yet its new USB -TCP/IP stack.

Nucleus, also with small memory foot print, (The ATI, now Mentor Graphics)
is also good, and has more BSP (peripheral support)... and cost more!
Like uC/OS-II the code is very clean and well documented.


And also ThreadX that I have not used. (Or very little and found basic setup
not so easy, support then was limited...)

There are more RTOS'es but (VxWork, OSE, and more...) mostly bigger in
size.. and cost.

4) JTAG / IDE tools.
They are much more many players (alphabetic order) including Ashling (Irish)
EPI Tools (Freemont US), Green Hills Systems, Signum and more.
I have used several, successully, including Signum that I really like: fast,
reliable, and good phone support. I like their debugger.
I have never used EPI Tools which get good reviews from people I know.

The ETM (Embedded Trace Module) support is usually not cheap, but can be
very usefull once in a while. If you are on a budget, you can do without.

One key issue, is which compilers they support: so far and to the best of my
knowledge, only EPI tools, and SIGNUM support the GU, and IAR and CrossWork
announced it for mid 2006.

5) Your question about startup code is important!
It is often called CRT).S, or CSTART.ASM or some of this nature...

Usually RTOS'es will come with the right startup code, for a given CPU, here
Atmel... but I found this to not be true, once! So be alert, when
purchasing the RTOS...
Ideally you want to make sure that RTOS does simple things from existing
basic application, to not waste anytime.
If you are good with assembly programming, modifying the startup code, is a
fairly simple task.

Hope it helped.
Andre


dhudson01@gmail.com wrote:

> Hi,
> On our project, we are considering an ARM  with a USB interface (Atmel
> AT91SAM7S256).  From looking at the datasheet, it appears that we need
> an 18.432 MHz crystal for the USB to operate at full speed.  Is this
> correct?  The datasheet seems to be a bit ambiguous in this regard.  I
> looked at the schematic for Atmel's AT91SAM7S-EK evaluation board and
> noticed that they are using an 18.432 MHz crystal, so I think I may be
> on the right track.  Will other value crystals (or digital clocks)
> work?  Could we drive the ARM at 36 MHz (this a required system clock
> frequency for other components) with the ARM's main oscillator bypassed
> and still run the USB at full speed?
> 
> Also, as I have never worked with an ARM before, does anyone have any
> suggestions for tools?  From reading this NG, it appears that the major
> players are:
> 
> Rowley CrossWorks
> IAR
> Keil
> GNU
> 
> What would be easiest for someone to get up and running "out of the
> box" with?  I have used Keil for 8051 development, WinAVR (GNU) for
> Atmel ATMEGA work, and dabbled with IAR before.
> 
> Do these tools provide the start up code for launching the C main( )
> function?  Do any have utilities for configuring peripherals?
> 
> Any recommended RTOSs for the AT91SAM7S256?
> 
> Thanks in advance for any help.
> 
> Regards,
> Doug

Tim & Michael,
Thanks for the posts.  Believe it or not, I did review the datasheet
for USB info prior to posting, however I didn't read the 544 page
document in its entirety (I don't believe I've ever read an *entire*
datasheet that was over 50 pages!).  I also searched for relevant app
notes, alas, to no avail.  As I mentioned in the original post, I found
the USB references in the datasheet to be somewhat ambiguous with
regards to USB timing.

Tim, on page 26 of the datasheet, the block diagram shows XIN feeding
the Main Oscillator which generates the Main Clock signal MAINCK.
MAINCK in turn is an input into the PLL and Divider block which creates
the PLL Clock PLLCK, which in turn drives the USB clock controller.

Michael, I will play around with the approach you described.  Thank
you!

Hope I didn't waste anyone's time.  This is my first project with an
ARM and our schedule doesn't have much room for a great deal of
experimentation.  I thought that if there was someone out there that
had successfully used the USB on this chip, I might get a bit of a
headstart.

Thanks for everyone's help.

Regards,
Doug

In article <1144957342.714505.134900@e56g2000cwe.googlegroups.com>,
dhudson01@gmail.com writes
>Hi,
>On our project, we are considering an ARM  with a USB interface (Atmel
>AT91SAM7S256).  From looking at the datasheet, it appears that we need
>an 18.432 MHz crystal for the USB to operate at full speed.  Is this
>correct?  The datasheet seems to be a bit ambiguous in this regard.  I
>looked at the schematic for Atmel's AT91SAM7S-EK evaluation board and
>noticed that they are using an 18.432 MHz crystal, so I think I may be
>on the right track.  Will other value crystals (or digital clocks)
>work?  Could we drive the ARM at 36 MHz (this a required system clock
>frequency for other components) with the ARM's main oscillator bypassed
>and still run the USB at full speed?
>
>Also, as I have never worked with an ARM before, does anyone have any
>suggestions for tools?  From reading this NG, it appears that the major
>players are:
>
>Rowley CrossWorks
>IAR
>Keil
>GNU


Rowely use the GNU compiler
Keil == ARM Real view (ARM bought Keil last year)


Gnu is now reputed to be only 5 years behind the main commercial
compilers. IF you have the time to get it tweaked it is not bad but if
time == money (ie you are doing a commercial project) then GNU is not
appreciably cheaper and the performance is ok but not brilliant. 

Both IAR and Keil have inexpensive but GOOD JTAG-USB debuggers. IAR also
have one with trace.

On SAM7 Atmel work closely with IAR (the IAR Jtag is supplied with the
SAM7 kits) 

The Keil simulator is better than the IAR but if you are using the JTAG
on to HW then the simulator is less important. 

Get the eval versions of the Keil and IAR and have a look.
The other thing is have a look at the Atmel kit and see what examples
they have and for which compiler...

It is no use buying compiler A if all the Atmel examples are for
compiler B.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

"Tim Wescott" <tim@seemywebsite.com> wrote in message
news:6sqdnQttGN4bJKPZRVn-gA@web-ster.com...
> dhudson01@gmail.com wrote:
> > Hi,
> > On our project, we are considering an ARM  with a USB interface (Atmel
> > AT91SAM7S256).  From looking at the datasheet, it appears that we need
> > an 18.432 MHz crystal for the USB to operate at full speed.  Is this
> > correct?  The datasheet seems to be a bit ambiguous in this regard.  I
> > looked at the schematic for Atmel's AT91SAM7S-EK evaluation board and
> > noticed that they are using an 18.432 MHz crystal, so I think I may be
> > on the right track.  Will other value crystals (or digital clocks)
> > work?  Could we drive the ARM at 36 MHz (this a required system clock
> > frequency for other components) with the ARM's main oscillator bypassed
> > and still run the USB at full speed?
> >
> > Also, as I have never worked with an ARM before, does anyone have any
> > suggestions for tools?  From reading this NG, it appears that the major
> > players are:
> >
> > Rowley CrossWorks
> > IAR
> > Keil
> > GNU
> >
> > What would be easiest for someone to get up and running "out of the
> > box" with?  I have used Keil for 8051 development, WinAVR (GNU) for
> > Atmel ATMEGA work, and dabbled with IAR before.
> >
> > Do these tools provide the start up code for launching the C main( )
> > function?  Do any have utilities for configuring peripherals?
> >
> > Any recommended RTOSs for the AT91SAM7S256?
> >
> > Thanks in advance for any help.
> >
> > Regards,
> > Doug
> >
> "The UDP peripheral requires two clocks: one peripheral clock used by
> the MCK domain and a 48 MHz clock used by the 12 MHz domain."
>
> That doesn't sound like it depends on the processor clock to me.  Have
> you carefully read all of the 571 pages in the data sheet, to make sure
> that you understand how they're clocking their USB peripheral?
>
> --
>
> Tim Wescott

Tim is right - if you are going to use this part then read that data sheet
and all the app notes very carefully.

I think (but you should check) that this scheme might work for you:

run the PLL clock at 48,92 or 192 MHz to use USB (it MUST be clocked at
48MHz but has a divider settable to 1/2/4). Then you could use a 36MHz
external clock, divide it by 6 to get 6MHz, "multiply" by 8 (or 16 or 32)
using the PLL to get the 48MHz for USB. The processor can then use the 36MHz
MAINCK as the the system MCK. (Don't blame me for the soundalike names!!).

I don't think that there is any way you can clock the processor at 36MHz and
the USB at 48MHz without directly injecting one of those frequencies from an
external oscillator. (The on chip crystal oscialltor will not run at 36MHz
but you can use external oscillators of up to 50MHz.

The most power efficient route is to use the crystal oscillator at a lowish
frequency (<12MHz) and clock the USB at 48MHz from the PLL and the processor
at 48MHz or 24MHz (or even lower if you can).

Only you can know if your application really can't get the clock it needs
from 48MHz but could from 36MHz.

Let us all know if this helps.

Michael Kellett

www.mkesc.co.uk

dhudson01@gmail.com wrote:
> Hi,
> On our project, we are considering an ARM  with a USB interface (Atmel
> AT91SAM7S256).  From looking at the datasheet, it appears that we need
> an 18.432 MHz crystal for the USB to operate at full speed.  Is this
> correct?  The datasheet seems to be a bit ambiguous in this regard.  I
> looked at the schematic for Atmel's AT91SAM7S-EK evaluation board and
> noticed that they are using an 18.432 MHz crystal, so I think I may be
> on the right track.  Will other value crystals (or digital clocks)
> work?  Could we drive the ARM at 36 MHz (this a required system clock
> frequency for other components) with the ARM's main oscillator bypassed
> and still run the USB at full speed?
> 
> Also, as I have never worked with an ARM before, does anyone have any
> suggestions for tools?  From reading this NG, it appears that the major
> players are:
> 
> Rowley CrossWorks
> IAR
> Keil
> GNU
> 
> What would be easiest for someone to get up and running "out of the
> box" with?  I have used Keil for 8051 development, WinAVR (GNU) for
> Atmel ATMEGA work, and dabbled with IAR before.
> 
> Do these tools provide the start up code for launching the C main( )
> function?  Do any have utilities for configuring peripherals?
> 
> Any recommended RTOSs for the AT91SAM7S256?
> 
> Thanks in advance for any help.
> 
> Regards,
> Doug
> 
"The UDP peripheral requires two clocks: one peripheral clock used by 
the MCK domain and a 48 MHz clock used by the 12 MHz domain."

That doesn't sound like it depends on the processor clock to me.  Have 
you carefully read all of the 571 pages in the data sheet, to make sure 
that you understand how they're clocking their USB peripheral?

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

> Also, as I have never worked with an ARM before, does anyone have any
> suggestions for tools?  From reading this NG, it appears that the major
> players are:
>
> Rowley CrossWorks
> IAR
> Keil
> GNU

These are all good tools - of coarse everybody has their favourite. 
CrossWorks can be downloaded with a 30 day evaluation, and IAR can be 
downloaded with a 32K code size limit.  I suggest you try them both out to 
see what you like/don't like.  For GCC I suggest going to www.gnuarm.com if 
you are a Windows user as this distribution comes with a Windows installer 
and does not require a separate Cygwin installation.  Debug capability is 
the down side of command line GCC but I have used Insight graphical debugger 
via a low cost wiggler successfully on other ARM7 based devices so this is 
an option if your budget is very tight.

> What would be easiest for someone to get up and running "out of the
> box" with?  I have used Keil for 8051 development, WinAVR (GNU) for
> Atmel ATMEGA work, and dabbled with IAR before.

IAR and CrossWorks come with an examples directory that contain 
pre-configured applications for the SAM7.  Both should work out of the box. 
I would guess that Keil will be the same.

If you look at the FreeRTOS.org download it contains preconfigured examples 
for SAM7S and SAM7X for IAR, Rowley and command line GCC.

> Do these tools provide the start up code for launching the C main( )
> function?  Do any have utilities for configuring peripherals?

IAR and CrossWorks come with all the linker and startup files you need. 
Again, I assume Keil does also.  As far as configuring peripherals goes then 
Keil is probably in the lead.  Startup files and linker scripts for GCC are 
fairly easy to come by, but can be more fiddly.

> Any recommended RTOSs for the AT91SAM7S256?

It depends on the requirements you have for the RTOS.  I will of coarse 
suggest look at http://www.FreeRTOS.org, but as you can see from the 
signature below I'm very bias ;-)  There are of plenty of others to choose 
from.

Regards,
Richard.

http://www.FreeRTOS.org
*Now for ARM CORTEX M3!*

Hi,
On our project, we are considering an ARM  with a USB interface (Atmel
AT91SAM7S256).  From looking at the datasheet, it appears that we need
an 18.432 MHz crystal for the USB to operate at full speed.  Is this
correct?  The datasheet seems to be a bit ambiguous in this regard.  I
looked at the schematic for Atmel's AT91SAM7S-EK evaluation board and
noticed that they are using an 18.432 MHz crystal, so I think I may be
on the right track.  Will other value crystals (or digital clocks)
work?  Could we drive the ARM at 36 MHz (this a required system clock
frequency for other components) with the ARM's main oscillator bypassed
and still run the USB at full speed?

Also, as I have never worked with an ARM before, does anyone have any
suggestions for tools?  From reading this NG, it appears that the major
players are:

Rowley CrossWorks
IAR
Keil
GNU

What would be easiest for someone to get up and running "out of the
box" with?  I have used Keil for 8051 development, WinAVR (GNU) for
Atmel ATMEGA work, and dabbled with IAR before.

Do these tools provide the start up code for launching the C main( )
function?  Do any have utilities for configuring peripherals?

Any recommended RTOSs for the AT91SAM7S256?

Thanks in advance for any help.

Regards,
Doug