After a week or so of pulling my hair out, I have finally got a working development environment for ARM stuff. I had a problem finding a good toolchain, and then I stumbled on [XVerve which has two sets of stuff for WinARM, one of which has a nice installer. It contains everything needed to build the example projects I have downloaded so far. I just had to adjust the Makefiles to fit my environment. The changes I needed to make were pretty easy to figure out.
I discovered that some toolchains apparently assume you already have CygWin installed. I didn’t find anything that mentions this in the toolchain docs.
Once I got my PATH set for the WinARM toolchain bin folders and adjusted the Makefiles, things built flawlessly. I still haven’t quite figured out why I can’t get a project for my own simple program to build though, so I need to do some more reading on Makefiles. Using one of the Makefiles from an example project has not worked so far, but I have gotten pretty close. I think I am just missing some LPC2148 specific header files.
I am using the [Eclipse 3.3 IDE with the [Zylin CDT plugin, with the WinARM toolchain from [XVerve. You do have to register with XVerve before you can download, but it is worth it, even if just to get the WinARM toolchain from them.
I’lll give it a go as I’ve been putting off setting up my development environent for the LPC2148, on the pointy end of the steep learning curve for this device lol.
Personally I tried some of the GNU tool chains and was… well, dissapointed… I come across the CrossWorks tools and it is very clean, easy to use, and well… just darn easy vs. all of the other tool chains I tried… so, I own a personal license and it was worth the small amount of $$$ to get a supported compiler that just worked well for me. Thus, my suggestion, try out CrossWorks and see if you like it.
I am using YAGARTO for my project with absolutely no problems. It includes the GCC toolchain, newlib, Eclipse 3.3, Zylin CDT plugin, OpenOCD and Insight. This toolchain does not require cygwin. It is actively updated and it is free.
The whole thing is good enough to allow me to debug, using an Olimex JTAG probe, inside the OS kernel without problems with concurrent threads and continuos switching between ARM and THUMB mode.
The only problem I have with it is the lack of Cortex M3 support, I suppose we will have to wait for GCC 4.3 for that.
Personally I tried some of the GNU tool chains and was… well, dissapointed… I come across the CrossWorks tools and it is very clean, easy to use, and well… just darn easy vs. all of the other tool chains I tried… so, I own a personal license and it was worth the small amount of $$$ to get a supported compiler that just worked well for me.
I am also using [[Rowley Associates'](http://www.rowley.co.uk) Crossworks for ARM, but I am using the Linux version under Debian Etch. I have a CrossConnect Lite JTAG unit which works perfectly. Now I just have to get my Personal License (next month) so I can continue to use these great tools. Rowley Associates support is totally AWESOME and I can't recommend them enough. I've got a clean compile of FreeRTOS v4.7.0 now and am going to check and see what things I need to change to make everything work for my [[LPC-2148 Proto Board](http://www.sparkfun.com/commerce/product_info.php?products_id=545).
I’ve been working with ARM since the early 90s, I’ve used every commercial toolset for ARM and 3 home-brew GCC cross-compilers (always on Linux), and I can say without hesitation that Rowley offers the best combination of features, ease of use, stability, price, and EXCELLENT SUPPORT AND TECHNICAL KNOWLEDGE.
Right now I’m stuck using Keil for a customer and their support is less than stellar. They’re not responsive, and even worse, their forums are a dead-end. With Rowley, you always deal directly with the principals of the company, you’re not fobbed off to some droid. That might be the case with IAR as well, their staff seems to be pretty engaged with the community, I just like Rowley more.
Also Rowley has a very full offering of solid board support packages, they really make it easy to get up and running.
I really respect Rowley’s business model and their (great & helpful) attitude towards their customers. On my next project (don’t have the contract yet) I’m going to try to push Rowley very hard (prospective customer doesn’t know ARM from a leg & needs me to come in get things going.)
Have any of you developed ARM Linux applications using Crossworks? I don’t see why this shouldn’t be possible. You should only have to include the kernel include files, and anything else your application might require.
Is it this easy or am I missing something? I’ll be purchasing my Personal License for the Linux version of Crossworks for ARM next month, and will be developing for ARM7. I see no reason this can’t also extend to ARM9 standalone and for ARM Linux as well. At this point I am thinking specifically of the [Hammer and [i.MX21 COG.
linuxguy:
Have any of you developed ARM Linux applications using Crossworks?
I’ll be purchasing my Personal License for the Linux version of Crossworks for ARM next month, and will be developing for ARM7. I see no reason this can’t also extend to ARM9 standalone and for ARM Linux as well. At this point I am thinking specifically of the [Hammer and [i.MX21 COG.
8-Dale[/quote]
Hi Dale,
Is your question regarding developing on a Linux host platform (as opposed to Windows), or developing for an embedded Linux target (or both?)
Rowley runs great on Linux, no worries there. Regarding embedded Linux on a target, I only develop with hard real-time OSs so I am not an embedded Linux expert, but usually you’ll start with a package (even if it’s free) that is tailored to a specific kernel / board / toolset (usually some variant of GCC, commercial or homebrew).
The Rowley ARM toolset can target ARM7/ARM9 (and XScale and the Cortex-M3 also) variants, but there are always issues such as libraries, drivers, board support packages, etc… Try to start with a well-tested “package” (usually supplied by the board maker) and build from that.
To put it in perspective, let’s say you have a board and a very simple “hello world LED blinky” program. There will be a main.c file, along with some libraries linked in (printf), drivers (LED), and assembly code for startup & setup of the C runtime env. So no OS of any sort, let alone Linux. Already I can tell you, the same code that compiles under Keil/ARM will need some changes (or at least the OUTPUT will be different) from that under Rowley. Libraries, header files, build steps, linker command files…
Throw in a source tree for an embedded Linux variant & you get the idea. You want to know EXACTLY what toolset & version were used to build the code that worked on that board!
Fuss:
Is your question regarding developing on a Linux host platform (as opposed to Windows), or developing for an embedded Linux target (or both?)
I already have Crossworks for ARM working under Linux. In fact, I have had it working under the latest versions of Debian, Ubuntu, and SUSE. :)
Fuss:
The Rowley ARM toolset can target ARM7/ARM9 (and XScale and the Cortex-M3 also) variants, but there are always issues such as libraries, drivers, board support packages, etc… Try to start with a well-tested “package” (usually supplied by the board maker) and build from that.
I built FreeRTOS 4.7.0 with uIP as a test. I did have to make some changes in the cs8900.c file because I want to use the correct LPC2148 register names, but will have to verifiy that these are the correct registers. I also have to dig through the .h files and make any changes to defines necessary to address the peripherals on my board.
Fuss:
To put it in perspective, let’s say you have a board and a very simple “hello world LED blinky” program. There will be a main.c file, along with some libraries linked in (printf), drivers (LED), and assembly code for startup & setup of the C runtime env.
I still have to write my hello world and blinker program. That is my next project. :)
Fuss:
Already I can tell you, the same code that compiles under Keil/ARM will need some changes (or at least the OUTPUT will be different) from that under Rowley. Libraries, header files, build steps, linker command files…
It's unfortunate that this sort of change has to be made just to make a specific compiler happy.
linuxguy:
It’s unfortunate that this sort of change has to be made just to make a specific compiler happy.
8-Dale
Yeah I know… unfortunately in the embedded world it’s almost unavoidable. It’s not the toolset vendors’ fault.
For that reason I try to make my code as portable as possible. For example, I stay away from using compiler #pragma directives, as they are (by definition) compiler-specific extensions. Pragmas are often used to do things like interrupt handlers and in-line assembly in normal ‘C’ code… I tend to write these “shims” or “stubs” in tiny assembly modules and avoid all the toolset-specific headaches.
Other hazards when switching between toolsets are things like bitfields, byte-packing (such as in structures), and register usage/allocation. As you probably know already, even within the same toolset, changes to the compiler version (even bug-fix “point versions”) or compiler options (especially optimizations) can change the output and as a result, break the code.
DISCLAIMER: I and my company actually make a living porting applications between toolsets & platforms, and writing portable code, so it’s a subject that’s pretty close to my heart.
I still haven’t quite figured out why I can’t get a project for my own simple program to build though, so I need to do some more reading on Makefiles. Using one of the Makefiles from an example project has not worked so far, but I have gotten pretty close. I think I am just missing some LPC2148 specific header files.