Hello folks, sorry for this newbie question. I am plan to start an ARM based project in the near future. So I google around and found WinARM. It sounds good to me so I know WinAVR very well. I think, I will use an Atmel ARM7 MCU - AT91SAM7A3 or AT91SAM7S256 - not clear by the moment. As far as I can see on the WinARM homepage the AT91SAM7S family is supported. But AT91SAM7A3? The SAM7A3 fits a little bit more into my design: MMC Card IF and CAN :-) That's what I'm looking for... So far so good. I download the WinARM .zip-file and take a look to the include directory to find some header files for one of the chips - nothing there...? For the AT91SAM7S64 I found an sample project. OK, there I found what I expect for this MCU. Some of the header files are from Atmel I think. Where I can found some identical for the SAM7256 and/or SAM7A3 (if supported)? And also a little bit unclear for me are the Board.h, the ROM and RAM ld-files and the Cstartup files. Can some one tell me more about the way to setup a project on an self-made hardware? Many thanks in advance! Regards Alex Zaech
Alexander Zaech wrote: > [...] As far as I can > see on the WinARM homepage the AT91SAM7S family is supported. But > AT91SAM7A3? The GNU-Tools (gcc c-compiler, linker at all) in WinARM (and other precompiled packages based on GNU-tools) support the SAM7A-series since ARM7TDMI is supported (and most other ARM architectures/cores too). > Where I can found some identical for the SAM7256 > and/or SAM7A3 (if supported)? at91.com -> kit -> (select eval kit) -> Software Packages -> download one of them (I usualy download those for IAR) -> extract. Header-file with register-defintions and "AT91-library" are included in the examples and both can be used with gcc too. > And also a little bit unclear for me are > the Board.h, Board.h is usualy used as "global config-header" for the project from Atmel and projects based on Atmel-code. Nothing magic in it, the comments in the source are obvious. > the ROM and RAM ld-files These are the linker-scripts: basicly to assign sections created by the compiler to a memory-address/range. "*ROM.ld" is the usualy used to create a binary/"load file" to be programmed into the controller's flash-memory, "RAM" usualy is used to create a file to be located in the controllers SRAM for debugging (but debugging in flash is also possible, but remind the limited number of hardware-breakpoints). The examples should give an idea. Search for "binutils manual" and read the ld manual for further information. > and the Cstartup files. In short: code needed for the basic preparation of hardware-registers and the memory before the code created by the c-Compiler can be started. Also read Jim Lynch's tutorial (i think it is available from atmel.com and at91.com now). Also read the the html-documents which come with the examples from Atmel, the application-notes from Atmel and for the "core" the technical reference/manual available from ARM (arm.com). > Can some > one tell me more about the way to setup a project on an self-made > hardware? I'd recommend that you buy a ready-made evaluation-board to get started. When you have a "feeling" for the tools (compiler, debugger etc.) and the way how to access the controller's hardware it will be easier to get your own hardware working. Your knowledge from the AVRs will help but there is a lot more to learn for ARM (I have started with AVRs too). Later study the schematics of the available eval.-boards from Atmel and others and read the "hardware-design" application-notes before creating your own hardware. Martin Thomas
Martin Thomas wrote: snip off > Also read Jim Lynch's tutorial (i think it is available from atmel.com > and at91.com now). Also read the the html-documents which come with the > examples from Atmel, the application-notes from Atmel and for the "core" > the technical reference/manual available from ARM (arm.com). > Many thanks for this hint. Jim Lynch's tutorial is great. Application notes and the "core" docu are a must! > > I'd recommend that you buy a ready-made evaluation-board to get started. > When you have a "feeling" for the tools (compiler, debugger etc.) and > the way how to access the controller's hardware it will be easier to get > your own hardware working. Your knowledge from the AVRs will help but > there is a lot more to learn for ARM (I have started with AVRs too). > Later study the schematics of the available eval.-boards from Atmel and > others and read the "hardware-design" application-notes before creating > your own hardware. > You are right, a ready-made evaluation-board is the best starting point. The tools itself are already well known from Linux projects. Only the differences to the embedded world and ARM needs hands-on training :-) Do you know something about the CrossWorks IDE? I have read some entries in other forums and it seems to be quite useful. BTW: Many thanks for explanations! Regards Alex Zaech
Alexander Zaech wrote: > Do you know something about the CrossWorks IDE? I have read some entries > in other forums and it seems to be quite useful. I have read some of the Crossworks-documentation but never used it so I can not comment on this product. But maybe someone else can. Rowley offers a time-limited evaluation-version.
Alexander Zaech wrote: > Where I can found some identical for the SAM7256 > and/or SAM7A3 (if supported)? Heres a SAM7A3 example that I was able to put together with Martin's help: http://users.wpi.edu/~jimmykaz/Arm/Sam7A3_Virt_Fnct.rar That includes the linker scripts, assembly file, C init file and Makefile. The Linker scripts, Assembly file and makefile have been modified to work with C++ virtual functions. Enjoy :)
Alexander Zaech wrote: > Do you know something about the CrossWorks IDE? I have read some entries > in other forums and it seems to be quite useful. > You can download an evaluation copy of CrossWorks. I evaluated it recently, it was fairly fully featured. The greatest benefit IMO is that Rowley have their own debugger that is not merely a front end to GDB. They also use their own C library rather than Newlib or GNU. C++ support seemed limited (with respect to teh libarary). In the end I rejected it because their VFP support was not yet mature (again w.r.t. the library). I also looked at Green Hills Multi, Keil uVision/RealView, and IAR Workbench. They all have their benefits, although you get most out of Green Hills by having relatively expensive trace hardware (the time-machine debugger is very clever) - without that, there is little to distinguish it from other tools, and the IDE itself is very quirky. If you are in a budget, CrossWorks is excellent value for money IMO, and takes a lot of the pain out of getting started on a wide rang eof hardware. I also got excellent support from Rowley during the evaluation. On the other hand WinARM is entirely free, but you are on your own for custom hardware and chips not directly supported. In my case the hardware specific headers, C runtime initialisation and other BSP code such as the syscalls interface and RTOS support were entirely written in-house. In short you can use WinARM on any ARM based chip supported by GCC, but the amount of work you have to do yourself depends on the hardware you choose. ARM7 devices are relatively straightforward since you do not normally have the complexity of an MMU to set up for example. ARM9 is more complex generally. If you are using external memory devices, there is additional complexity setting up bus-widths and bus-timing. Avoid Microcross GNU X-Tools IMO, what they are selling is a simple GNU cross distribution with support at additional (and high) cost, from experience WinARM is a better quality GCC build, does not need Cygwin, and you get better and free support from Martin and the user community right here. Clifford
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.