I am currently using an older release (GCC 4.0.1), and I use only the
GCC toolchain and Insight debugger, 'integrated' using CodeWright and an
in-house developed makefile/dependency generator tool.

The project is running on custom hardware using an ARM9 based device,
and a commercial RTOS, so uses in-house developed BSP, boot-loader, and
runtime start-up.

It is primarily a C++ application, but does not (currently) use
stlibc++. Because at some point I will need VFP support, I will also
need to rebuild newlib from source (and 'fix' it's sqrt()
implementation).

I suspect I am in the minority, but a package of just the GCC toolchain,
including binutils, make, and supporting utilities such as rm and sh
would suit me fine.

While Eclipse is probably the best option for an IDE, being the basis
for several commercial embedded development environments from WindRiver,
QNX, and Mentor Graphics for example, I personally dislike it, but for
most purposes I agree it should be there. If I were to use it, I'd
probaly prefer the EasyEclipse for C/C++ distribution
http://www.easyeclipse.org/site/distributions/cplusplus.html.

Clifford

I just tested the new release and found some bug.

When I open one of the examples in examples folder and just test the
"make clean", I got the messages as below.

-----------------------------------------
...
...
rm -f .dep/*
zsh: no matches found: .dep/*
make.exe: *** [clean_list] Error 1

> Process Exit Code: 2
> Time Taken: 00:00
-----------------------------------------

I think that's because of the difference of version of make.exe.

So, I changed the Makefile as below and I could solve the problem.

// before
   $(REMOVE) .dep/*

// after
   if [ -f .dep/* ]; then  $(REMOVE) .dep/*; fi

That's it.
I think we should change all of the Makefiles as above or we should use
the older version make.exe ;)

Chaewon Lee wrote:
> // before
>    $(REMOVE) .dep/*
>
> // after
>    if [ -f .dep/* ]; then  $(REMOVE) .dep/*; fi
>
Wouldn't

-rm -f .dep/*

also work?

> Wouldn't
>
> -rm -f .dep/*
>
> also work?

Thank you for good advice.
"rm -f .dep/*" doesn't work either.
It seems to be the problem of the version difference of rm.exe

Old version of rm.exe is 4.1 while new version is 5.94

When I entered "rm -f .dep/*" with new rm.exe, I got the following
messages.

--------------------------------------------------
rm: cannot remove '.dep/*' : Invalid argument
--------------------------------------------------

Chaewon Lee wrote:
>> Wouldn't
>>
>> -rm -f .dep/*
>>
>> also work?
>
> Thank you for good advice.
> "rm -f .dep/*" doesn't work either.
> It seems to be the problem of the version difference of rm.exe
>
> Old version of rm.exe is 4.1 while new version is 5.94
>
> When I entered "rm -f .dep/*" with new rm.exe, I got the following
> messages.
>
> --------------------------------------------------
> rm: cannot remove '.dep/*' : Invalid argument
> --------------------------------------------------

Could you please try change the line

$(REMOVE) .dep/*

in your makefile's clean target-"section" to

$(REMOVE) .dep/* | exit 0

You may also check the makefiles in the later example in the collection
(LPC2378_demo1, str71x_demo1) as templates.

Yes, I expect too that the different rm-version cause this issue. If you
don't want to change your existing makefiles you can always use the
alternate build-toolset which I also included in the testing 20070505
package. It should bring back the old behaviour. Just rename
c:\WinARM\utils\bin to i.e. c:\WinARM\utils\bin_to_new and rename
c:\WinARM\utils\bin_utils_mingw to c:\WinARM\utils\bin.


Hope this helps,
Martin Thomas

Martin Thomas wrote:
>
> Could you please try change the line
>
> $(REMOVE) .dep/*
>
> in your makefile's clean target-"section" to
>
> $(REMOVE) .dep/* | exit 0
>
> You may also check the makefiles in the later example in the collection
> (LPC2378_demo1, str71x_demo1) as templates.
>
> Yes, I expect too that the different rm-version cause this issue. If you
> don't want to change your existing makefiles you can always use the
> alternate build-toolset which I also included in the testing 20070505
> package. It should bring back the old behaviour. Just rename
> c:\WinARM\utils\bin to i.e. c:\WinARM\utils\bin_to_new and rename
> c:\WinARM\utils\bin_utils_mingw to c:\WinARM\utils\bin.
>
>
> Hope this helps,
> Martin Thomas


The following line works good.

$(REMOVE) .dep/* | exit 0

Also, old version rm.exe which is in c:\WinARM\utils\bin_utils_mingw\
could be another solution.

Thank you.

Chaewon Lee wrote:
> Thank you for good advice.
> "rm -f .dep/*" doesn't work either.
> It seems to be the problem of the version difference of rm.exe
Sorry, perhaps I was not clear, what I should have said was:

   -$(REMOVE) .dep/*

Note the '-' prefix, to force make to ignore failure of rm. However I am
not in a position to try it, and am probably wrong.

Clifford

Clifford Slocombe wrote:
> Chaewon Lee wrote:
>> Thank you for good advice.
>> "rm -f .dep/*" doesn't work either.
>> It seems to be the problem of the version difference of rm.exe
> Sorry, perhaps I was not clear, what I should have said was:
>
>    -$(REMOVE) .dep/*
>
> Note the '-' prefix, to force make to ignore failure of rm. However I am
> not in a position to try it, and am probably wrong.
>
> Clifford

I tried '-' prefix.
It successfully ignores the result of rm. ;)

It brings the following result.

---------------------------------------------------------
...
...
rm -f .dep/*
zsh: no matches found: .dep/*
make.exe: [clean_list] Error 1 (ignored)
Errors: none
-------- end --------


> Process Exit Code: 0
> Time Taken: 00:01
---------------------------------------------------------

Thank you very much.

Chaewon Lee wrote:
> I tried '-' prefix.
> It successfully ignores the result of rm. ;)
>
The question is however should it have ignored it? Were there no matches
because there were no matches, or because the should there have been
match and there is a problem that should not be ignored?

Clifford

Clifford Slocombe wrote:
> The question is however should it have ignored it? Were there no matches
> because there were no matches, or because the should there have been
> match and there is a problem that should not be ignored?
>
> Clifford

The problem occurs when we try to delete the contents in the empty
directory( that is .dep).
When we try to delete something which does not exist, new version rm.exe
complains while old version rm.exe does not.

Therefore, I think your suggestion makes sense too.

:)

Have a nice day and thanks for your advice.

>
> Maybe it's time think about the future of WinARM as a big "all in one
> package" collection since the package has become rather large (ca. 120MB
> since Eclipse with CDT and different other tools are now included) and I
> don't know if all the components I did include because of my personal
> taste are also useful for others. I'd like to start a small survey and
> ask for your opinion:
>
> - What would you like to see included into the package?
> - Which one of the included components is especially useful for you?
> Which one not?
> - Do you use utilities from winarm/utils. Which if them?
> - Did you ever read one or more of the documents collected in winarm/doc
> - Are the examples as in the package's winarm/examples directory useful
> for you?
> - Do you prefer another precompiled package of the GNU ARM
> cross-compiler for MS-Windows hosts (Codesourcery's arm-none-eabi,
> devkitarm, Yagarto/Amontec sdk4arm, GNUARM with cygwin etc.)? Why?
> - Which targets to you use beside of ARM7TDMI(-S) based devices (like
> LPC2000, STR7, AT91SAM7S, ADuC7000)?
>
> Of cause all other suggestions for the future of WinARM are welcome.
>
> Please use this forum-thread or send me an e-mail of you don't want to
> post into a public forum.
>
> Martin Thomas
> (mthomas[At]rhrk(Dot)uni-kl[Dot]de)

For our need, we use yagarto ide + tool chain. But we use your makefile
and your sample as starting point. (Very well done btw !).

I realy don't know what exactly is the difference between your build and
the one from yagarto.

I don't know exactly we have 3 or 4 different build for the same
purpose. Probably i misse somthing there. Normaly the best tiohng to do
is to join effort to make something better that juste trying to make on
our own. But like i said, i can be wrong on alll the thing !

Continue your good work !

Jonathan

Chaewon Lee wrote:
> Clifford Slocombe wrote:
> The problem occurs when we try to delete the contents in the empty
> directory( that is .dep).
> When we try to delete something which does not exist, new version rm.exe
> complains while old version rm.exe does not.
>
> Therefore, I think your suggestion makes sense too.
>

Agreed the '-' prefix is the more usual solution solution for such a
situation.

Jonathan Dumaresq wrote:
> For our need, we use yagarto ide + tool chain. But we use your makefile
> and your sample as starting point. (Very well done btw !).

Thanks.

> I realy don't know what exactly is the difference between your build and
> the one from yagarto.

There are a few differences between the different collections but you
might never notice them: codesourcery, devkitpro: arm-eabi, devkitpro:
fewer "multilib" settings (but Dave is currently creating a new release
with additional multilibs enabled), codesourcery: ARMv7 "patches" not
sure about multilibs, Yagarto: "newlib-syscalls enabled", well tested
with Eclipse, WinARM: different multilibs, newlib-lpc "already at it's
place", syscalls disabled, single but huge download, no installer,
"WinAVR look-and-fell", Rowley: seems to use the Codesourcery-Toolchain
with an own libc/libm (not newlib). There might be more which I do not
remember or know right now. But you are right, the configuration in the
GNU-toolchain included in Yagarto is very similar to the one in WinARM.
Michael and me exchanged a few e-mails when he created Yagarto.

> I don't know exactly we have 3 or 4 different build for the same
> purpose. Probably i misse somthing there. Normaly the best tiohng to do
> is to join effort to make something better that juste trying to make on
> our own. But like i said, i can be wrong on alll the thing !

Thanks for the reply.

Correct, different builds are a waste of resources. And yes, I'm
thinking about teaming up with one or more of the other projects and
provide "WinARM" as an add-on (doc/examples/utils). But I will continue
maintaining WinARM util I know that such a approach does not break
peoples code which somehow relies on features included in WinARM only.
That's why I started the "survey" to find out what features are needed.

The main reason why WinARM still exists although Yagarto, Codesourcery,
DevKitARM etc. are available is compatibilty. WinARM has been one of the
first "non-cygwin" collections which has been configured for different
"multilibs" and "build-in"-support for the newlib-lpc. newlib-lpc has
been important for me in the beginning when I started with the LPC2106
and the initial reason - beside of getting rid of the cygwin-dependency
- why I started to build my "own" tool-collection. Maybe there are a lot
of users who need this setup too and don't know how to add the features
in another collection.

I try to test every new release with my "example collection" to verify
that everything still works and if there are modifications needed I
mention them in the readme-file. I feel responsible to maintain a
"product" which gets downloaded that often. Of cause this is not only a
"community work" but also a simple personal interest. I have sold some
source-codes and have to make sure that those who have bought them can
just use a "current" WinARM-collection to rebuild the projects without
problems to avoid time-consuming support-requests.

For me it's no major problem to migrate to another collection. I have
already used Codesourcery's "G++ lite" for my experiments with the LMI
Cortex-M3 controllers. I test most of the newer code I create with the
Codesourcery prebuild toolchain too. But I don't know the situation for
the other "end-users".

I just need to know why WinARM-users stay with WinARM to find out what
they need and do not find in another collection.

> Continue your good work !

Thanks.

Martin

I gave the yagatro a try and found that the Makefile is not readily
compatible. The yagarto tool chain complained about the missing newlib.
I did a simple search and the newlib-lpc indeed seems missing. How did
you solve that?
Cem



Jonathan Dumaresq wrote:
>>
>> Maybe it's time think about the future of WinARM as a big "all in one
>> package" collection since the package has become rather large (ca. 120MB
>> since Eclipse with CDT and different other tools are now included) and I
>> don't know if all the components I did include because of my personal
>> taste are also useful for others. I'd like to start a small survey and
>> ask for your opinion:
>>
>> - What would you like to see included into the package?
>> - Which one of the included components is especially useful for you?
>> Which one not?
>> - Do you use utilities from winarm/utils. Which if them?
>> - Did you ever read one or more of the documents collected in winarm/doc
>> - Are the examples as in the package's winarm/examples directory useful
>> for you?
>> - Do you prefer another precompiled package of the GNU ARM
>> cross-compiler for MS-Windows hosts (Codesourcery's arm-none-eabi,
>> devkitarm, Yagarto/Amontec sdk4arm, GNUARM with cygwin etc.)? Why?
>> - Which targets to you use beside of ARM7TDMI(-S) based devices (like
>> LPC2000, STR7, AT91SAM7S, ADuC7000)?
>>
>> Of cause all other suggestions for the future of WinARM are welcome.
>>
>> Please use this forum-thread or send me an e-mail of you don't want to
>> post into a public forum.
>>
>> Martin Thomas
>> (mthomas[At]rhrk(Dot)uni-kl[Dot]de)
>
> For our need, we use yagarto ide + tool chain. But we use your makefile
> and your sample as starting point. (Very well done btw !).
>
> I realy don't know what exactly is the difference between your build and
> the one from yagarto.
>
> I don't know exactly we have 3 or 4 different build for the same
> purpose. Probably i misse somthing there. Normaly the best tiohng to do
> is to join effort to make something better that juste trying to make on
> our own. But like i said, i can be wrong on alll the thing !
>
> Continue your good work !
>
> Jonathan

First, I'd like to say thank you for your effort in making WinARM
possible.

Now onto the feedback...

> Maybe it's time think about the future of WinARM as a big "all in one
> package" collection since the package has become rather large (ca. 120MB
> since Eclipse with CDT and different other tools are now included) and I
> don't know if all the components I did include because of my personal
> taste are also useful for others. I'd like to start a small survey and
> ask for your opinion:
>
> - What would you like to see included into the package?

I think the "all-in-one" is fine as long as there are options to
install/not-install components.  That way, users who need all the
components don't have to chase them down individually and those who
don't won't have to install a lot of stuff they don't need.

> - Which one of the included components is especially useful for you?
> Which one not?

I found the Insight tool to be very useful.  I am porting an RTOS
application from an AVR to ARM target and I have used the Insight tool
to simulate the ARM processor quite nicely.  It has allowed me to
validate context switch code and rapidly do the port.

> - Do you use utilities from winarm/utils. Which if them?

None. I do a lot of cross development (AVR, PIC, HC12, and now ARM), so
I have created a common build platform based on Cygwin and BoostJam.
The edit/compile cycle is now identical for all target devices as build
scripts using the Cygwin tools (sed,cp,mkdir,sh, etc.) have abstracted
the low-level commands sequences needed to compile/link code.

I have been using the BoostJam tool (not the whole Boost Build
framework, as it is way too large for what I need) along with a compact
and customized build script.  It makes a much more robust and easier to
work with tool than the traditional 'make' utility.

The 'Terminal' program looked interesting, but I did have some trouble
getting it to work with my COM ports.  I have no idea why.

> - Did you ever read one or more of the documents collected in winarm/doc

Yes. Almost all of them.  Very helpful.

> - Are the examples as in the package's winarm/examples directory useful
> for you?

Yes.  Especially the 'crt0.s' examples and the linker scripts.

> - Do you prefer another precompiled package of the GNU ARM
> cross-compiler for MS-Windows hosts (Codesourcery's arm-none-eabi,
> devkitarm, Yagarto/Amontec sdk4arm, GNUARM with cygwin etc.)? Why?

Yes. I prefer precompiled targets.  It is easy to install and reduces
the number of tool/lib dependencies I need to worry about.

Cygwin targets interest me first, windows targets second.

> - Which targets to you use beside of ARM7TDMI(-S) based devices (like
> LPC2000, STR7, AT91SAM7S, ADuC7000)?

For the moment, my only exposure the the ARM device arena is the
LPC2119, so I can't really add any useful feedback here.

> Of cause all other suggestions for the future of WinARM are welcome.

I would like to see some docs on re-entrancy issues that cover which
libraries are reentrant, language features, etc.  For example, is
exception handling re-entrant?

This would save much time when I am porting my RTOS application as I
would not have to do low-level code walk-throughs to try and determine
if re-entrancy is safe.

Well, that's it for now.

Once again, thank you very much for your work in this project.  I
appreciate and enjoy it!

Cheers!

Dan



>
> Please use this forum-thread or send me an e-mail of you don't want to
> post into a public forum.
>
> Martin Thomas
> (mthomas[At]rhrk(Dot)uni-kl[Dot]de)

I just finished downloading/installing/testing the new version.  My test
code compiled without errors/warnings and I observed the following:

1) The new version does not seem to come with Insight like the older
20060606 version.  Missing in the package or renamed or ???

2) My test code for exception handling crashes.  When I increase the
stack size from 256 bytes to 512 bytes, it works fine.  I take it this
implies there were changes to how exceptions were handled and this
required more RAM?

Cheers!

Dan




Martin Thomas wrote:
> Hello,
>
> a WinARM test-release 20070505 is available at:
> http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/#winarm
>
> The release-notes for the test-release are here:
> 
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/WinARM_20070505_readme.html
>
> Feel free to test and comment.
>
>
>
> Maybe it's time think about the future of WinARM as a big "all in one
> package" collection since the package has become rather large (ca. 120MB
> since Eclipse with CDT and different other tools are now included) and I
> don't know if all the components I did include because of my personal
> taste are also useful for others. I'd like to start a small survey and
> ask for your opinion:
>
> - What would you like to see included into the package?
> - Which one of the included components is especially useful for you?
> Which one not?
> - Do you use utilities from winarm/utils. Which if them?
> - Did you ever read one or more of the documents collected in winarm/doc
> - Are the examples as in the package's winarm/examples directory useful
> for you?
> - Do you prefer another precompiled package of the GNU ARM
> cross-compiler for MS-Windows hosts (Codesourcery's arm-none-eabi,
> devkitarm, Yagarto/Amontec sdk4arm, GNUARM with cygwin etc.)? Why?
> - Which targets to you use beside of ARM7TDMI(-S) based devices (like
> LPC2000, STR7, AT91SAM7S, ADuC7000)?
>
> Of cause all other suggestions for the future of WinARM are welcome.
>
> Please use this forum-thread or send me an e-mail of you don't want to
> post into a public forum.
>
> Martin Thomas
> (mthomas[At]rhrk(Dot)uni-kl[Dot]de)