EmbeddedRelated.com
Forums

Opinions on Rowley CrossWorks for ARM

Started by Sebastian Schildt October 30, 2006
Sebastian Schildt wrote:
> Hello group, > > I'd like to hear some opinions regarding the Rowley CrossWorks for ARM > toolchain. I know, this is a somewhat broad request, so I'll try to > clarify things a bit more: > > I am in the process of evaluating ARM toolchains which are to be used in > university classes/projects.
Hallo, I have worked with Keil, GCC + GDB/Insight and Rowley Crossworks for ARM and have to say that I liked their toolchain best. In my opinion one of the strongest points for Rowley Crossworks are: * They support the ARM Wiggler Interfaces which is very cheap and it works excellent (Compared to using GDB/INSIGHT with ocddaemon or openocd). This might be interesting because cost is usually an issue for university classes. * The Debugger is an excellent peace of work. We switched from another toolchain and I found that debugging time cut down a big junk with the Rowley Tools. * They use the GNU C/C++ compiler tools which are somewhat "industry standard" tools. Specially the good integration for inline assembler in GCC is a big plus for embedded systems if you are doing low level stuff. * Works on Linux * They have the best cost/performance ration in my opinion. Some drawbacks on Rowley are: * They introduced another concept of linker script bases on XML stuff. It is somewhat complicated and internally generated GNU LD scripts. I have never understood why they did this. * There Code Editor is not the best. It does not support completion or folding or other neat stuff. * They use their own project files instead of something like Make. Although they support exporting something like a Build/ script. * They support only a very small range of platforms in contrast to IAR or others. Having more than one toolchain might be an issue. Kind Regards, Christian Walter
> > Wishlist > 1. stable, proven toolchain > 2. preferably something "industry standard", so students use the tools > which they might encounter in their future jobs > 3. Cheap :) > > We just recently switched to ARM. We have experience with the (X)C166 > architecture using the Tasking Toolchain and Atmel AVR with WinAVR (GCC) > > So far I tried out the the following ARM toolchains > > IAR: > Had no problems with this one. I've come to the understandung, that this > is THE toolchain for ARM Development? So certainly this fits 1 and 2 of > the wishlist, but not exactly 3 ... > > WinARM (free GCC) > I tried this and it worked somehow but feels a bit "hacky". AVRGCC > distributions in contrast are way more polished. So for the time being I > ruled this one out > > ImageCraft > This worked pretty good, but as far as I could see there's no debugger > included, which is a minus. Worse, the website, well, is very > unprofessional and looks and reads as if it was created by a bunch of > immature teenagers. I think I'll stay away from this. (I looked at > http://www.imagecraft.com/. First I thought it is a fake or something > but I couldn't find another page) > > > Rowley Crossworks > No Problems. Quite like IAR. Looks nice. I was quite impressed, and > prices are very reasonable. From what I've seen this is a GCC variant > for which Rowley provides the standard libs, device headers, IDE, etc? > > > Tasking > We already use this product for (X)C166. For ARM we want something else. > > Keil > Haven't tried this one so far. Also quite welll known, at least for 8051 > I think. > > So basically we're asking ourselves whether IAR or Rowley (and perhaps > Keil?) is the "better" solution for us. "Everyone" seems to know IAR or > Keil, while I haven't found that much about Rowley. > > Any personal opinions regarding Rowley/IAR/Keil or pointers to > Reviews/Benchmarks are greatly appreciated. > > Thanks for reading this far :) > > Sebastian Schildt > >
Thank you all for input so far.

Sebastian Schildt
Not Really Me wrote:
> "Sebastian Schildt" <jisinews@arcor.de> wrote in message > news:45463c5c$0$27623$9b4e6d93@newsspool2.arcor-online.net... > > Hello group, > > > > I'd like to hear some opinions regarding the Rowley CrossWorks for ARM > > toolchain. I know, this is a somewhat broad request, so I'll try to > > clarify things a bit more: > > > > I am in the process of evaluating ARM toolchains which are to be used in > > university classes/projects. > > > > Wishlist > > 1. stable, proven toolchain > > 2. preferably something "industry standard", so students use the tools > > which they might encounter in their future jobs > > 3. Cheap :) > > > > We just recently switched to ARM. We have experience with the (X)C166 > > architecture using the Tasking Toolchain and Atmel AVR with WinAVR (GCC) > > > > So far I tried out the the following ARM toolchains > > > > IAR: > > Had no problems with this one. I've come to the understandung, that this > > is THE toolchain for ARM Development? So certainly this fits 1 and 2 of > > the wishlist, but not exactly 3 ... > > > > WinARM (free GCC) > > I tried this and it worked somehow but feels a bit "hacky". AVRGCC > > distributions in contrast are way more polished. So for the time being I > > ruled this one out > > > > ImageCraft > > This worked pretty good, but as far as I could see there's no debugger > > included, which is a minus. Worse, the website, well, is very > > unprofessional and looks and reads as if it was created by a bunch of > > immature teenagers. I think I'll stay away from this. (I looked at > > http://www.imagecraft.com/. First I thought it is a fake or something but > > I couldn't find another page) > > > > > > Rowley Crossworks > > No Problems. Quite like IAR. Looks nice. I was quite impressed, and prices > > are very reasonable. From what I've seen this is a GCC variant for which > > Rowley provides the standard libs, device headers, IDE, etc? > > > > > > Tasking > > We already use this product for (X)C166. For ARM we want something else. > > > > Keil > > Haven't tried this one so far. Also quite welll known, at least for 8051 I > > think. > > > > So basically we're asking ourselves whether IAR or Rowley (and perhaps > > Keil?) is the "better" solution for us. "Everyone" seems to know IAR or > > Keil, while I haven't found that much about Rowley. > > > > Any personal opinions regarding Rowley/IAR/Keil or pointers to > > Reviews/Benchmarks are greatly appreciated. > > > > Thanks for reading this far :) > > > > Sebastian Schildt > > > We find Microcross Visual X-Tools to work much better than the Rowley tools. > It is also based on gnu/gcc. We have used it on a number of ARM and > Coldfire projects. > > We found the Rowley debugger to be just awful. It was buggy and locked up > the PC repeatedly. The only recovery was a reboot. I believe it is still > the current version. It was only a few months ago that we used it. > > The Microcross implementation is much more stable. We have used it with > both Multi-Ice and Abatron JTAG emulators.
I've never had any problems with the debugger, and have never heard of anyone else having problems. I'm sure that any bugs would have been mentioned on the LPC2000 Yahoo group, as there are quite a lot of CrossWorks users there. Did you report the problems to Rowley and what was their response? Leon
In article <4qp8bhFodc66U1@individual.net>, 
scott@validatedQWERTYsoftware...XYZZYcom says...

<snip>

> We found the Rowley debugger to be just awful. It was buggy and locked up > the PC repeatedly. The only recovery was a reboot. I believe it is still > the current version. It was only a few months ago that we used it.
This is contrary to my observations. I have had the debugger crash on rare occasions, and I have found that setting a breakpoint while the code is running on the target sometimes causes a dabort exception (if I break first, set the bp, then continue, there's no issue). I have never had the PC lock up or bluescreen. I find the project management to be excellent; the granularity for changing options at either the project or file level is a godsend. The fact that all configurations are in XML files lets me manage tool configurations with my version control system, a task that is impossible with another IDE I use that insists on a binary format. --Gene
> > The Microcross implementation is much more stable. We have used it with > both Multi-Ice and Abatron JTAG emulators. > > Scott > > DISCLAIMER: In all fairness I must say that we are a Microcross partner. > That said, I stand by my above comments. > > >
"Gene S. Berkowitz" <first.last@comcast.net> wrote in message 
news:MPG.1fb270b18b4317ab9897e5@newsgroups.comcast.net...
> In article <4qp8bhFodc66U1@individual.net>, > scott@validatedQWERTYsoftware...XYZZYcom says... > > <snip> > >> We found the Rowley debugger to be just awful. It was buggy and >> locked up >> the PC repeatedly. The only recovery was a reboot. I believe it is >> still >> the current version. It was only a few months ago that we used it. > > This is contrary to my observations. I have had the debugger crash on > rare occasions, and I have found that setting a breakpoint while the > code is running on the target sometimes causes a dabort exception (if > I > break first, set the bp, then continue, there's no issue). I have > never > had the PC lock up or bluescreen.
Oh good, it's not just me then. I noticed this has begun happening a bit more frequently since I went up to the latest versions (1.6) but it did happen once in a while on 1.5. Also, very occasionally, if I set a breakpoint on an if statement then I can't remove it - although the debugger says that it is gone I still stop whenever the if is considered.
> I find the project management to be excellent; the granularity for > changing options at either the project or file level is a godsend. > The fact that all configurations are in XML files lets me manage tool > configurations with my version control system, a task that is > impossible > with another IDE I use that insists on a binary format.
Version control. Errm yeah, I should probably get me some of that....
"Tom Lucas" <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote in 
message news:1162288802.23184.0@iris.uk.clara.net...
> "Sebastian Schildt" <jisinews@arcor.de> wrote in message > news:45463c5c$0$27623$9b4e6d93@newsspool2.arcor-online.net...
>> Rowley Crossworks >> No Problems. Quite like IAR. Looks nice. I was quite impressed, and >> prices are very reasonable. From what I've seen this is a GCC variant for >> which Rowley provides the standard libs, device headers, IDE, etc? > > In my experience IARs support is good but Rowley's is absolutely > first-class and they really do bend over backwards to help. However, you > do get paper manuals with IAR which I always like but that might not be > all that useful to a room full of students. > > I believe I read on the Rowley website that there is an educational > discount but Chris also mentioned that IAR can do that so I don't know how > the prices will compare once you explore both roads. I do prefer the IAR > IDE - their auto indentation is great and it does integrate with tools > like Lint better. On my project the code generated by the IAR compiler was > slightly smaller but no quicker than that generated by Rowley's gcc.
We now offer a Personal License for hobbyists and students at $149 rather than $950 for the Commercial License. Educational Licenses are for universitiy and research use. We're always very flexible and have donated licenses and hardware to many, many people. Donating software and hardware to startups (there is a "merit" criterion) with a promise that they'll purchase a commercial license and hardware at a later date once their product is minting it for them is not uncommon. It's better to do one thing very well than lots of things that are mediocre or, worse, pathetic. -- Paul.
"Paul Curtis" <plc@rowley.co.uk> wrote in message 
news:4548c969$0$8716$ed2619ec@ptn-nntp-reader02.plus.net...
> > "Tom Lucas" <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote > in message news:1162288802.23184.0@iris.uk.clara.net... >> "Sebastian Schildt" <jisinews@arcor.de> wrote in message >> news:45463c5c$0$27623$9b4e6d93@newsspool2.arcor-online.net... > >>> Rowley Crossworks >>> No Problems. Quite like IAR. Looks nice. I was quite impressed, and >>> prices are very reasonable. From what I've seen this is a GCC >>> variant for which Rowley provides the standard libs, device headers, >>> IDE, etc? >> >> In my experience IARs support is good but Rowley's is absolutely >> first-class and they really do bend over backwards to help. However, >> you do get paper manuals with IAR which I always like but that might >> not be all that useful to a room full of students. >> >> I believe I read on the Rowley website that there is an educational >> discount but Chris also mentioned that IAR can do that so I don't >> know how the prices will compare once you explore both roads. I do >> prefer the IAR IDE - their auto indentation is great and it does >> integrate with tools like Lint better. On my project the code >> generated by the IAR compiler was slightly smaller but no quicker >> than that generated by Rowley's gcc. > > We now offer a Personal License for hobbyists and students at $149 > rather than $950 for the Commercial License.
That's a good idea. Presumably it's the full package and their are no code size limits imposed?
> It's better to do one thing very well than lots of things that are > mediocre or, worse, pathetic.
I can do one thing mediocre and lots of things pathetically :-(
In article <45463c5c$0$27623$9b4e6d93@newsspool2.arcor-online.net>, 
Sebastian Schildt <jisinews@arcor.de> writes
>Hello group, > >I'd like to hear some opinions regarding the Rowley CrossWorks for ARM >toolchain. I know, this is a somewhat broad request, so I'll try to >clarify things a bit more: > >I am in the process of evaluating ARM toolchains which are to be used >in university classes/projects. > >Wishlist > 1. stable, proven toolchain > 2. preferably something "industry standard", so students use the >tools which they might encounter in their future jobs > 3. Cheap :) > >We just recently switched to ARM. We have experience with the (X)C166 >architecture using the Tasking Toolchain and Atmel AVR with WinAVR (GCC) > >So far I tried out the the following ARM toolchains > >IAR: >Had no problems with this one. I've come to the understandung, that >this is THE toolchain for ARM Development? So certainly this fits 1 and >2 of the wishlist, but not exactly 3 ...
It is one of the main ARM compilers used in Industry fro both C and C++ They can be inexpensive for universities. Talk to them
>Keil >Haven't tried this one so far. Also quite welll known, at least for >8051 I think.
This now has the ARM RealView compiler in it. Again talk to them about deals for Universities.
>So basically we're asking ourselves whether IAR or Rowley (and perhaps >Keil?) is the "better" solution for us. "Everyone" seems to know IAR or >Keil, while I haven't found that much about Rowley.
Both Keil and IAR are Industry standard, very reliable and well supported. They both do some very good deals for universities when asked. You won't go wrong with either of these for ARM Your students will come across both in industry and ARM the company work closely with both. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <newscache$lxp18j$pg2$1@news.sil.at>, Christian Walter 
<wolti@sil.at> writes
>Sebastian Schildt wrote: >> Hello group, >> I'd like to hear some opinions regarding the Rowley CrossWorks for >>ARM toolchain. I know, this is a somewhat broad request, so I'll try >>clarify things a bit more: >> I am in the process of evaluating ARM toolchains which are to be >>used in university classes/projects. > >Hallo, > >I have worked with Keil, GCC + GDB/Insight and Rowley Crossworks for >ARM and have to say that I liked their toolchain best. In my opinion >one of the strongest points for Rowley Crossworks are: > > * They support the ARM Wiggler Interfaces which is very cheap and it > works excellent (Compared to using GDB/INSIGHT with ocddaemon or > openocd). This might be interesting because cost is usually an > issue for university classes.
There is inexpensive and there is cheap.... You do not want to cut things too find. Industry stopped using wigglers some time back. In Industry time is money. So the cheapest option for hobby use is not the same as the best option for industry.
> * They use the GNU C/C++ compiler tools which are somewhat "industry > standard" tools. Specially the good integration for inline assembler > in GCC is a big plus for embedded systems if you are doing low level > stuff.
Hardly I would not recommend GCC for embedded use.
> * Works on Linux
And this is an advantage? 90% of embedded systems don't use an OS let alone Linux. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills wrote:
> In article <newscache$lxp18j$pg2$1@news.sil.at>, Christian Walter > <wolti@sil.at> writes > >Sebastian Schildt wrote: > >> Hello group, > >> I'd like to hear some opinions regarding the Rowley CrossWorks for > >>ARM toolchain. I know, this is a somewhat broad request, so I'll try > >>clarify things a bit more: > >> I am in the process of evaluating ARM toolchains which are to be > >>used in university classes/projects. > > > >Hallo, > > > >I have worked with Keil, GCC + GDB/Insight and Rowley Crossworks for > >ARM and have to say that I liked their toolchain best. In my opinion > >one of the strongest points for Rowley Crossworks are: > > > > * They support the ARM Wiggler Interfaces which is very cheap and it > > works excellent (Compared to using GDB/INSIGHT with ocddaemon or > > openocd). This might be interesting because cost is usually an > > issue for university classes. > > There is inexpensive and there is cheap.... You do not want to cut > things too find. Industry stopped using wigglers some time back. > > In Industry time is money. So the cheapest option for hobby use is not > the same as the best option for industry. > > > * They use the GNU C/C++ compiler tools which are somewhat "industry > > standard" tools. Specially the good integration for inline assembler > > in GCC is a big plus for embedded systems if you are doing low level > > stuff. > > Hardly I would not recommend GCC for embedded use.
When I worked for Racal on a large military project a few years ago, the expensive 68000 compiler that the software engineers were supposed to use was so full of bugs that they gave up on it and used gcc. The managers were horrified when they found out, but the software had already been written and worked. Leon