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?
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
formatting link
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.
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.
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.
It depends on the requirements you have for the RTOS. I will of coarse suggest look at
formatting link
but as you can see from the signature below I'm very bias ;-) There are of plenty of others to choose from.
"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/
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 (
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 & 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.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.