Opinions on Rowley CrossWorks for ARM

Sebastian Schildt wrote:
>=> 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)
> 

Wow. That hurts a little. No one quite said that in the 12+ years we 
have been in business. We tend to look at it as friendly neighbor mom 
and pop compiler company. We offer features that we deem are good and 
provide excellent support. We even offer things that are "hard to do," 
like the first whole program code compression commercial embedded C 
compiler and now global optimizations. We have 10,000+ of satisified 
customers across multiple CPU families. We are one of the few remaining 
compiler companies in US, so I guess we are doing OK.

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.

Good point - I have to agree with you that time is worth a lot more than 
some savings in the upfront cost of development tools. But the Wiggler 
was only an example and Rowley (Like Keil or others) have their own high 
speed debugging interface.
Still using Rowley Crossworks the Wiggler is a good product because it 
is the only product I know of where it works reliable and has a tight 
integration.

>> * 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.

Why - Can you provide some evidence for this claim that GCC is not 
suitable for embedded use in general?

>> * Works on Linux
> And this is an advantage?
> 
> 90% of embedded systems don't use an OS let alone Linux.

That depends - But clearly the choice of the desktop operating system 
does not belong to this group.
Again could you provide some evidence for you 90% claim. For example 
look at the 2005 survery at embedded.com [1]. Or do you mean embedded 
systems in use?

[1] http://www.embedded.com/columns/showArticle.jhtml?articleID=163700590


Kind Regards,
   Christian Walter

On Thu, 02 Nov 2006 10:36:45 +0100, Christian Walter wrote:

> 
>>> * Works on Linux
>> And this is an advantage?
>> 
>> 90% of embedded systems don't use an OS let alone Linux.
> 
> That depends - But clearly the choice of the desktop operating system 
> does not belong to this group.

Hi Christian,

I think choice of desktop system has some important. Some may think the
reasoning a bit tenuous, but with a greater percentage of embedded systems
moving over to Linux, then using Linux as your host is a very good start
before jumping into a project where embedded linux is your target. Then,
you can get to know various aspects about linux, (file permissions, device
nodes, nfs, make etc), before the time comes when you need those skills in
an embedded linux project.

And of course Linux is a very solid development host anyway, with great
support for development activities. I really can't think of a reason why
using Linux as a development host is a bad idea anyway.

So I would indeed advocate Linux as a host (even though I use Windows for
a lot of development activities), and I wouldn't discourage people to use
gcc either, given that gcc could well play a bigger part in the future
that it plays now. Take a look at avr32. IIRC, Atmel talks about gcc
before iar in their literature, for a processor which looks to have a very
bright future. Is this a clue to which way the tide is turning?

Regards,

Paul.

>Take a look at avr32. IIRC, Atmel talks about gcc
> before iar in their literature, for a processor which looks to have a very
> bright future. Is this a clue to which way the tide is turning?
>
> Regards,
>
> Paul.

I recently ported FreeRTOS.org to PIC24 and dsPIC and was surprised to find 
that their C30 compiler was in fact ....... GCC.  Makes a better job of it 
than the C18 compiler no doubt.

Regards,
Richard.

+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC

On Thu, 02 Nov 2006 11:02:48 +0000, FreeRTOS.org wrote:

>>Take a look at avr32. IIRC, Atmel talks about gcc
>> before iar in their literature, for a processor which looks to have a very
>> bright future. Is this a clue to which way the tide is turning?
>>
>> Regards,
>>
>> Paul.
> 
> I recently ported FreeRTOS.org to PIC24 and dsPIC and was surprised to find 
> that their C30 compiler was in fact ....... GCC.  Makes a better job of it 
> than the C18 compiler no doubt.
> 

Yep. I think if someone tells you not to use Linux or gcc, check their
trousers and shoes. If they are flares and platforms, don't believe them -
they're stuck in the past ;-)

Regards,

Paul.

Paul Taylor wrote:
> On Thu, 02 Nov 2006 10:36:45 +0100, Christian Walter wrote:
> 
>>>> * Works on Linux
>>> And this is an advantage?
>>>
>>> 90% of embedded systems don't use an OS let alone Linux.
>> That depends - But clearly the choice of the desktop operating system 
>> does not belong to this group.
> 
> Hi Christian,

Hi Paul,

> I think choice of desktop system has some important. Some may think the
> reasoning a bit tenuous, but with a greater percentage of embedded systems
> moving over to Linux, then using Linux as your host is a very good start
> before jumping into a project where embedded linux is your target. Then,
> you can get to know various aspects about linux, (file permissions, device
> nodes, nfs, make etc), before the time comes when you need those skills in
> an embedded linux project.
> 
> And of course Linux is a very solid development host anyway, with great
> support for development activities. I really can't think of a reason why
> using Linux as a development host is a bad idea anyway.

You are right - Linux as a desktop OS matters when you work with 
Embedded Linux you will already have some knowledge. I just didn't want 
to discuss this never ending issue about the war on desktop operating 
systems and there are also other alternative for Windows (Connecting to 
a development host, Using Cygwin, ...)

I added the Linux Platform as a plus point for Rowley Crossworks to my 
lust because at least at my university the Embedded Systems Lab uses 
Linux hosts for development. I don't know the rationale behind it but I 
think it has to do with cost and technical decisions.

> So I would indeed advocate Linux as a host (even though I use Windows for
> a lot of development activities), and I wouldn't discourage people to use
> gcc either, given that gcc could well play a bigger part in the future
> that it plays now. Take a look at avr32. IIRC, Atmel talks about gcc
> before iar in their literature, for a processor which looks to have a very
> bright future. Is this a clue to which way the tide is turning?

I am a supporter of GCC as embedded platform and added this as a plus 
point for Rowley Crossworks. Maybe my point got lost in my last email. I 
had good experience with code size and speed on GCC based toolchains 
(ARM, Coldfire, AVR).
Where other tools are superior than GCC (at least on the MSP430) are 
floating point support. Recently we had a project where we only had left 
a few bytes of Flash on a MSP430 target and then tried different 
compilers. IAR produced the smallest code and saved about 7K code. 
Integer nearly was the same between different compilers.

> Regards,
> 
> Paul.

Kind regards,
	Christian Walter

> I added the Linux Platform as a plus point for Rowley Crossworks to my
> lust

Lust?  Is there something you are not sharing with us?

Regards,
Richard.

+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC

On Thu, 02 Nov 2006 12:14:30 +0100, Christian Walter wrote:


> Hi Paul,
> 
> You are right - Linux as a desktop OS matters when you work with 
> Embedded Linux you will already have some knowledge. I just didn't want 
> to discuss this never ending issue about the war on desktop operating 
> systems and there are also other alternative for Windows (Connecting to 
> a development host, Using Cygwin, ...)
> 
> I added the Linux Platform as a plus point for Rowley Crossworks to my 
> lust because at least at my university the Embedded Systems Lab uses 
> Linux hosts for development. I don't know the rationale behind it but I 
> think it has to do with cost and technical decisions.
> 

Surely you mean list, or has linux advocacy reached new heights? ;-)

> I am a supporter of GCC as embedded platform and added this as a plus 
> point for Rowley Crossworks. Maybe my point got lost in my last email. I 
> had good experience with code size and speed on GCC based toolchains 
> (ARM, Coldfire, AVR).
> Where other tools are superior than GCC (at least on the MSP430) are 
> floating point support. Recently we had a project where we only had left 
> a few bytes of Flash on a MSP430 target and then tried different 
> compilers. IAR produced the smallest code and saved about 7K code. 
> Integer nearly was the same between different compilers.
>

That is more or less in line with my experience too. 

regards

Paul.

Paul Taylor wrote:
> On Thu, 02 Nov 2006 12:14:30 +0100, Christian Walter wrote:
> 
> 
>> Hi Paul,
>>
>> You are right - Linux as a desktop OS matters when you work with 
>> Embedded Linux you will already have some knowledge. I just didn't want 
>> to discuss this never ending issue about the war on desktop operating 
>> systems and there are also other alternative for Windows (Connecting to 
>> a development host, Using Cygwin, ...)
>>
>> I added the Linux Platform as a plus point for Rowley Crossworks to my 
>> lust because at least at my university the Embedded Systems Lab uses 
>> Linux hosts for development. I don't know the rationale behind it but I 
>> think it has to do with cost and technical decisions.
>>
> 
> Surely you mean list, or has linux advocacy reached new heights? ;-)

Hello,

Of course list - Looking up the word in the dictionary is somewhat funny 
for a non native english speaker. I already see this hanging around in 
Rowley offices as a new joke *g*.

Regards,
	Christian Walter

> 
>> I am a supporter of GCC as embedded platform and added this as a plus 
>> point for Rowley Crossworks. Maybe my point got lost in my last email. I 
>> had good experience with code size and speed on GCC based toolchains 
>> (ARM, Coldfire, AVR).
>> Where other tools are superior than GCC (at least on the MSP430) are 
>> floating point support. Recently we had a project where we only had left 
>> a few bytes of Flash on a MSP430 target and then tried different 
>> compilers. IAR produced the smallest code and saved about 7K code. 
>> Integer nearly was the same between different compilers.
>>
> 
> That is more or less in line with my experience too. 
> 
> regards
> 
> Paul.
> 
> 

Richard wrote:
> Sebastian Schildt wrote:
>>=> 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)
> 
> Wow. That hurts a little. No one quite said that in the 12+ years
> we have been in business. We tend to look at it as friendly
> neighbor mom and pop compiler company. We offer features that we
> deem are good and provide excellent support. We even offer things
> that are "hard to do," like the first whole program code
> compression commercial embedded C compiler and now global
> optimizations. We have 10,000+ of satisified customers across
> multiple CPU families. We are one of the few remaining compiler
> companies in US, so I guess we are doing OK.

I don't agree with that criticism.  However your pages suffer from
the too common and highly annoying failure to adapt to the width of
the users display, and thus require horizontal scrolling.

BTW, on first glance, your 'firststeps' book looks very good.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>