> -----Original Message-----
> From: l...
> [mailto:l...] On Behalf Of Pete Vidler
> Sent: 13 February 2009 14:01
> To: l...
> Subject: Re: [lpc2000] Eclipse+Olimex openOCD+MAC OS X
>
> FreeRTOS.org Info wrote:
> > You can also use managed make, but personally I stick to
> makefiles as
> > managed make requires your source code to be organised in a
> > non-productive/non-optimal way.
>
> I've been using managed make for quite a while now (using the
> internal builder), without noticing any real restrictions on
> code organisation -- care to elaborate?
>
The managed make expects all source files to be below the project in the
directory tree. The "Linked Resources" feature get around this but are
tricky to setup and a bodged solution. A typical FreeRTOS project will be
in a directory and reference the kernel code that is in a separate SVN
repository (typically using ../FreeRTOS/Source/etc), drivers that are in a
separate repository/directory, 'middleware' that is in a separate
repository/directory again, etc.
Also, by default it will attempt to build all the files in the directories.
Again you can selectively tell it not to do this but this is awkward and
backwards (normally you would tell the IDE which files to build, not which
files not to build). The FreeRTOS code is structured as:
FreeRTOS/Source/portable/[compiler]/[architecture]
Where there are numerous compiler subdirectories, and numerous architectures
subdirectories per compiler. Therefore the directory tree contains loads of
files that are not to be used.
This is not just because of the way I have chosen organise FreeRTOS, because
drivers and middleware use similar schemes. In fact, all projects I have
worked on organise code into separate directories (effectively libraries)
because placing all code below the project directory would mean replicating
the code for every project - a support nightmare.
I would be very happy if you told me I was missing something obvious here
and using the tool in a dumb way, but my conversations with the Eclipse
Foundation would seem to indicate otherwise. Also, they are quite happy
with the way it works so its not going to change anytime soon. I am aware
of several independent attempts to fix this though.
IMHO, managed make is unusable for anything non-trivial. However, this does
not matter - if you use standard make then everything is simple and
flexible, and easy to maintain, configuration manage, and share with others.
Because I'm old I sort of prefer it anyway, I can see all the command
line
options in one place and make edits as I please without having to jump
through project setting menus plus I can build from the command line if the
mood takes me. I include the makefile in the project and to make any
changes I just edit it in Eclipse.
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers. More than 7000 downloads per month.
+ http://www.FreeRTOS.org/Documentation
FreeRTOS eBook - a hands on step by step guide.
Eclipse+Olimex openOCD+MAC OS X
Started by ●February 12, 2009
Reply by ●February 13, 20092009-02-13
Reply by ●February 13, 20092009-02-13
FreeRTOS.org Info wrote:
> This is not just because of the way I have chosen organise FreeRTOS, because
> drivers and middleware use similar schemes. In fact, all projects I have
> worked on organise code into separate directories (effectively libraries)
> because placing all code below the project directory would mean replicating
> the code for every project - a support nightmare.
Ah, I see... thanks for the info.
I have not encountered this issue, because I typically use header file
(template library or static inline style) and/or pre-compiled library
archives, rather than keeping source for external projects in the same
workspace.
To be honest, I see no problem in keeping separate copies of things
under the project folder (just the FreeRTOS folders you need, in your
example). As long as they are linked to the same version control
repository, there should be no real maintenance issue with keeping them
in sync -- presumably most usage scenarios don't involve modifying
FreeRTOS itself anyway.
Pete
> This is not just because of the way I have chosen organise FreeRTOS, because
> drivers and middleware use similar schemes. In fact, all projects I have
> worked on organise code into separate directories (effectively libraries)
> because placing all code below the project directory would mean replicating
> the code for every project - a support nightmare.
Ah, I see... thanks for the info.
I have not encountered this issue, because I typically use header file
(template library or static inline style) and/or pre-compiled library
archives, rather than keeping source for external projects in the same
workspace.
To be honest, I see no problem in keeping separate copies of things
under the project folder (just the FreeRTOS folders you need, in your
example). As long as they are linked to the same version control
repository, there should be no real maintenance issue with keeping them
in sync -- presumably most usage scenarios don't involve modifying
FreeRTOS itself anyway.
Pete
Reply by ●February 14, 20092009-02-14
Pete Vidler wrote:
> FreeRTOS.org Info wrote:
>> You can also use managed make, but personally I stick to makefiles as
>> managed make requires your source code to be organised in a
>> non-productive/non-optimal way.
>
> I've been using managed make for quite a while now (using the internal
> builder), without noticing any real restrictions on code organisation --
> care to elaborate?
I've tried with two different whole projects and managed make (via
the GNU ARM plugin for Eclipse) and have not gotten either to build.
Both of these projects build just fine with their included makefiles and
environments. This leads me to simply use Eclipse as an editor (so far)
since I have also not been able to get Avarice and GDB to work as a
debugger. Of course I too run on a Mac and haven't gotten a programmer
to work either, let alone a JTAG one needed for debugging. But, I've
not learned all there is to learn just yet either. I'm still struggling
up that long learning curve for ARM development.
DLC
> Pete
--
-------------
Dennis Clark TTT Enterprises
www.techtoystoday.com
-------------
> FreeRTOS.org Info wrote:
>> You can also use managed make, but personally I stick to makefiles as
>> managed make requires your source code to be organised in a
>> non-productive/non-optimal way.
>
> I've been using managed make for quite a while now (using the internal
> builder), without noticing any real restrictions on code organisation --
> care to elaborate?
I've tried with two different whole projects and managed make (via
the GNU ARM plugin for Eclipse) and have not gotten either to build.
Both of these projects build just fine with their included makefiles and
environments. This leads me to simply use Eclipse as an editor (so far)
since I have also not been able to get Avarice and GDB to work as a
debugger. Of course I too run on a Mac and haven't gotten a programmer
to work either, let alone a JTAG one needed for debugging. But, I've
not learned all there is to learn just yet either. I'm still struggling
up that long learning curve for ARM development.
DLC
> Pete
--
-------------
Dennis Clark TTT Enterprises
www.techtoystoday.com
-------------
Reply by ●February 19, 20092009-02-19
Does the crossworks solution include thumb,interwork builds?
I have an lpc2148. I need to use math functions. I've struggled for
a week now with the open source tools on osx and windoze - and I have
not solved this issue. On each platform I can build, link, and
download the code into the device. If there is any call to a function
in , the device stops working. I don't care about commercial
vs. open source, I want to write code with a functioning toolchain and
preferably on my mac. Does crossworks provide this functionality
without the pain?
--- In l..., "Paul Curtis" wrote:
>
> Hi,
>
> > Thanks for the heads up, crossworks is a commercial solution though. I
> > understand it is relatively cheap, though I am really looking for
> > something free to use for any type of applications. Eclipse, openOCD
> > are perfect for this.
>
> I'm sure there would be members interested in the solution, should
you find
> one.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
I have an lpc2148. I need to use math functions. I've struggled for
a week now with the open source tools on osx and windoze - and I have
not solved this issue. On each platform I can build, link, and
download the code into the device. If there is any call to a function
in , the device stops working. I don't care about commercial
vs. open source, I want to write code with a functioning toolchain and
preferably on my mac. Does crossworks provide this functionality
without the pain?
--- In l..., "Paul Curtis" wrote:
>
> Hi,
>
> > Thanks for the heads up, crossworks is a commercial solution though. I
> > understand it is relatively cheap, though I am really looking for
> > something free to use for any type of applications. Eclipse, openOCD
> > are perfect for this.
>
> I'm sure there would be members interested in the solution, should
you find
> one.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
Reply by ●February 19, 20092009-02-19
> Does the crossworks solution include thumb,interwork
builds?
> I have an lpc2148. I need to use math functions. I've struggled for
> a week now with the open source tools on osx and windoze - and I have
> not solved this issue. On each platform I can build, link, and
> download the code into the device. If there is any call to a function
> in , the device stops working. I don't care about commercial
> vs. open source, I want to write code with a functioning toolchain and
> preferably on my mac. Does crossworks provide this functionality
> without the pain?
I so understand your position. The ARM toolchains that I have tried
using GCC has been so fragile that if I deviate one little bit from the
layout of the demo package as supplied, I get nothing but heartburn
trying to find and fix the problem. I've heard that Rowley is going to
release a "version 2" IDE/compiler that runs on OS X. I have their AVR
package on Windows and like it, others have used it at my last job on
Windows for the ARM and spoke well of it. The price is better than the
"those other really expensive ones" as well and more affordable to those
of us that are independent consultant developers too. I can't wait to
see what happens!
ARM is a completely different bird from other processors because of the
incredible variety of strains and multiple vendors. Using one just
isn't a simple process, at least as I'm discovering.
DLC
>
> --- In l..., "Paul Curtis" wrote:
>>
>> Hi,
>>
>> > Thanks for the heads up, crossworks is a commercial solution though. I
>> > understand it is relatively cheap, though I am really looking for
>> > something free to use for any type of applications. Eclipse, openOCD
>> > are perfect for this.
>>
>> I'm sure there would be members interested in the solution, should
> you find
>> one.
>>
>> --
>> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>>
>
> I have an lpc2148. I need to use math functions. I've struggled for
> a week now with the open source tools on osx and windoze - and I have
> not solved this issue. On each platform I can build, link, and
> download the code into the device. If there is any call to a function
> in , the device stops working. I don't care about commercial
> vs. open source, I want to write code with a functioning toolchain and
> preferably on my mac. Does crossworks provide this functionality
> without the pain?
I so understand your position. The ARM toolchains that I have tried
using GCC has been so fragile that if I deviate one little bit from the
layout of the demo package as supplied, I get nothing but heartburn
trying to find and fix the problem. I've heard that Rowley is going to
release a "version 2" IDE/compiler that runs on OS X. I have their AVR
package on Windows and like it, others have used it at my last job on
Windows for the ARM and spoke well of it. The price is better than the
"those other really expensive ones" as well and more affordable to those
of us that are independent consultant developers too. I can't wait to
see what happens!
ARM is a completely different bird from other processors because of the
incredible variety of strains and multiple vendors. Using one just
isn't a simple process, at least as I'm discovering.
DLC
>
> --- In l..., "Paul Curtis" wrote:
>>
>> Hi,
>>
>> > Thanks for the heads up, crossworks is a commercial solution though. I
>> > understand it is relatively cheap, though I am really looking for
>> > something free to use for any type of applications. Eclipse, openOCD
>> > are perfect for this.
>>
>> I'm sure there would be members interested in the solution, should
> you find
>> one.
>>
>> --
>> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>>
>
Reply by ●February 19, 20092009-02-19
That's rather odd, and completely contrary to my experience with GCC.
I've
used it on MSP430's, AVRs, LPC2148/LPC2468, x86, and PowerPCs, and never run
into it being "fragile". In fact, I consider it to be far easier to use and
get started with than some packages I've run into, like IARs. And a lot
more reliable with far fewer quirks than many of the inhouse rolled C
compilers (like the Microchip PIC18 compiler).
--jc
On Thu, Feb 19, 2009 at 10:00 AM, Dennis Clark wrote:
>
> I so understand your position. The ARM toolchains that I have tried
> using GCC has been so fragile that if I deviate one little bit from the
> layout of the demo package as supplied, I get nothing but heartburn
> trying to find and fix the problem. I've heard that Rowley is going to
> release a "version 2" IDE/compiler that runs on OS X. I have their AVR
> package on Windows and like it, others have used it at my last job on
> Windows for the ARM and spoke well of it. The price is better than the
> "those other really expensive ones" as well and more affordable to those
> of us that are independent consultant developers too. I can't wait to
> see what happens!
> ARM is a completely different bird from other processors because of the
> incredible variety of strains and multiple vendors. Using one just
> isn't a simple process, at least as I'm discovering.
>
> DLC
>
used it on MSP430's, AVRs, LPC2148/LPC2468, x86, and PowerPCs, and never run
into it being "fragile". In fact, I consider it to be far easier to use and
get started with than some packages I've run into, like IARs. And a lot
more reliable with far fewer quirks than many of the inhouse rolled C
compilers (like the Microchip PIC18 compiler).
--jc
On Thu, Feb 19, 2009 at 10:00 AM, Dennis Clark wrote:
>
> I so understand your position. The ARM toolchains that I have tried
> using GCC has been so fragile that if I deviate one little bit from the
> layout of the demo package as supplied, I get nothing but heartburn
> trying to find and fix the problem. I've heard that Rowley is going to
> release a "version 2" IDE/compiler that runs on OS X. I have their AVR
> package on Windows and like it, others have used it at my last job on
> Windows for the ARM and spoke well of it. The price is better than the
> "those other really expensive ones" as well and more affordable to those
> of us that are independent consultant developers too. I can't wait to
> see what happens!
> ARM is a completely different bird from other processors because of the
> incredible variety of strains and multiple vendors. Using one just
> isn't a simple process, at least as I'm discovering.
>
> DLC
>
Reply by ●February 19, 20092009-02-19
> That's rather odd, and completely contrary to my
experience with GCC.
> I've
> used it on MSP430's, AVRs, LPC2148/LPC2468, x86, and PowerPCs, and never
> run
> into it being "fragile". In fact, I consider it to be far easier to use
> and
> get started with than some packages I've run into, like IARs. And a lot
> more reliable with far fewer quirks than many of the inhouse rolled C
> compilers (like the Microchip PIC18 compiler).
Me too. I've found it "fragile" with ARM set ups, not the others. Once
I can generate code everything is fine - With the ARM GCC setups that
I've tried (and I admit to being pretty green with ARM) I've found it
difficult to move from this company's configuration (how they did their
makefile, what IDE they used, etc.) to any other configuration.
Again, I'm green with ARM, I've used GCC in plenty with plenty of other
devices too. This could just be my experience and prejudice.
IMO,
DLC
> --jc
>
> On Thu, Feb 19, 2009 at 10:00 AM, Dennis Clark wrote:
>
>>
>> I so understand your position. The ARM toolchains that I have tried
>> using GCC has been so fragile that if I deviate one little bit from the
>> layout of the demo package as supplied, I get nothing but heartburn
>> trying to find and fix the problem. I've heard that Rowley is going to
>> release a "version 2" IDE/compiler that runs on OS X. I have their AVR
>> package on Windows and like it, others have used it at my last job on
>> Windows for the ARM and spoke well of it. The price is better than the
>> "those other really expensive ones" as well and more affordable to those
>> of us that are independent consultant developers too. I can't wait to
>> see what happens!
>> ARM is a completely different bird from other processors because of the
>> incredible variety of strains and multiple vendors. Using one just
>> isn't a simple process, at least as I'm discovering.
>>
>> DLC
>>
>
>
>
> I've
> used it on MSP430's, AVRs, LPC2148/LPC2468, x86, and PowerPCs, and never
> run
> into it being "fragile". In fact, I consider it to be far easier to use
> and
> get started with than some packages I've run into, like IARs. And a lot
> more reliable with far fewer quirks than many of the inhouse rolled C
> compilers (like the Microchip PIC18 compiler).
Me too. I've found it "fragile" with ARM set ups, not the others. Once
I can generate code everything is fine - With the ARM GCC setups that
I've tried (and I admit to being pretty green with ARM) I've found it
difficult to move from this company's configuration (how they did their
makefile, what IDE they used, etc.) to any other configuration.
Again, I'm green with ARM, I've used GCC in plenty with plenty of other
devices too. This could just be my experience and prejudice.
IMO,
DLC
> --jc
>
> On Thu, Feb 19, 2009 at 10:00 AM, Dennis Clark wrote:
>
>>
>> I so understand your position. The ARM toolchains that I have tried
>> using GCC has been so fragile that if I deviate one little bit from the
>> layout of the demo package as supplied, I get nothing but heartburn
>> trying to find and fix the problem. I've heard that Rowley is going to
>> release a "version 2" IDE/compiler that runs on OS X. I have their AVR
>> package on Windows and like it, others have used it at my last job on
>> Windows for the ARM and spoke well of it. The price is better than the
>> "those other really expensive ones" as well and more affordable to those
>> of us that are independent consultant developers too. I can't wait to
>> see what happens!
>> ARM is a completely different bird from other processors because of the
>> incredible variety of strains and multiple vendors. Using one just
>> isn't a simple process, at least as I'm discovering.
>>
>> DLC
>>
>
>
>
Reply by ●February 19, 20092009-02-19
Sounds like "IDE" may be the key word here. I despise IDEs. They impose
rules I don't care for, hide things you need to know about, etc. I like a
good old fashioned Makefile, vi, and a bash shell. Then you can get some
work done.
I particularly don't like IDEs that have been written in Java...
--jc
On Thu, Feb 19, 2009 at 12:47 PM, Dennis Clark wrote:
>
> > That's rather odd, and completely contrary to my experience with GCC.
> > I've
> > used it on MSP430's, AVRs, LPC2148/LPC2468, x86, and PowerPCs, and never
> > run
> > into it being "fragile". In fact, I consider it to be far easier to use
> > and
> > get started with than some packages I've run into, like IARs. And a lot
> > more reliable with far fewer quirks than many of the inhouse rolled C
> > compilers (like the Microchip PIC18 compiler).
>
> Me too. I've found it "fragile" with ARM set ups, not the others. Once
> I can generate code everything is fine - With the ARM GCC setups that
> I've tried (and I admit to being pretty green with ARM) I've found it
> difficult to move from this company's configuration (how they did their
> makefile, what IDE they used, etc.) to any other configuration.
>
> Again, I'm green with ARM, I've used GCC in plenty with plenty of other
> devices too. This could just be my experience and prejudice.
>
> IMO,
> DLC
>
> > --jc
> >
> > On Thu, Feb 19, 2009 at 10:00 AM, Dennis Clark >
> wrote:
> >
> >>
> >> I so understand your position. The ARM toolchains that I have tried
> >> using GCC has been so fragile that if I deviate one little bit from the
> >> layout of the demo package as supplied, I get nothing but heartburn
> >> trying to find and fix the problem. I've heard that Rowley is going to
> >> release a "version 2" IDE/compiler that runs on OS X. I have their AVR
> >> package on Windows and like it, others have used it at my last job on
> >> Windows for the ARM and spoke well of it. The price is better than the
> >> "those other really expensive ones" as well and more affordable to those
> >> of us that are independent consultant developers too. I can't wait to
> >> see what happens!
> >> ARM is a completely different bird from other processors because of the
> >> incredible variety of strains and multiple vendors. Using one just
> >> isn't a simple process, at least as I'm discovering.
> >>
> >> DLC
> >>
> >
> >
> >
> >
> >
> >
> >
> >
> >
rules I don't care for, hide things you need to know about, etc. I like a
good old fashioned Makefile, vi, and a bash shell. Then you can get some
work done.
I particularly don't like IDEs that have been written in Java...
--jc
On Thu, Feb 19, 2009 at 12:47 PM, Dennis Clark wrote:
>
> > That's rather odd, and completely contrary to my experience with GCC.
> > I've
> > used it on MSP430's, AVRs, LPC2148/LPC2468, x86, and PowerPCs, and never
> > run
> > into it being "fragile". In fact, I consider it to be far easier to use
> > and
> > get started with than some packages I've run into, like IARs. And a lot
> > more reliable with far fewer quirks than many of the inhouse rolled C
> > compilers (like the Microchip PIC18 compiler).
>
> Me too. I've found it "fragile" with ARM set ups, not the others. Once
> I can generate code everything is fine - With the ARM GCC setups that
> I've tried (and I admit to being pretty green with ARM) I've found it
> difficult to move from this company's configuration (how they did their
> makefile, what IDE they used, etc.) to any other configuration.
>
> Again, I'm green with ARM, I've used GCC in plenty with plenty of other
> devices too. This could just be my experience and prejudice.
>
> IMO,
> DLC
>
> > --jc
> >
> > On Thu, Feb 19, 2009 at 10:00 AM, Dennis Clark >
> wrote:
> >
> >>
> >> I so understand your position. The ARM toolchains that I have tried
> >> using GCC has been so fragile that if I deviate one little bit from the
> >> layout of the demo package as supplied, I get nothing but heartburn
> >> trying to find and fix the problem. I've heard that Rowley is going to
> >> release a "version 2" IDE/compiler that runs on OS X. I have their AVR
> >> package on Windows and like it, others have used it at my last job on
> >> Windows for the ARM and spoke well of it. The price is better than the
> >> "those other really expensive ones" as well and more affordable to those
> >> of us that are independent consultant developers too. I can't wait to
> >> see what happens!
> >> ARM is a completely different bird from other processors because of the
> >> incredible variety of strains and multiple vendors. Using one just
> >> isn't a simple process, at least as I'm discovering.
> >>
> >> DLC
> >>
> >
> >
> >
> >
> >
> >
> >
> >
> >
Reply by ●February 19, 20092009-02-19
I've done lots of AVR on my mac. And now I'm moving into ARM world.
Again, my primary dev station is the mac. Can anyone let me know what
specific toolchain setup is the most stable for mac -> lpc2148.
I am currently building the latest of everything again.
My issues don't seem to be building, linking, or flashing. Its
running on the lpc2148. And then, I can do the basic hello world
stuff. I can run most examples I've found on the net (though not
successful with jcwren lpc2148_demo -yet. It hasn't compiled for me.)
that do not call math functions.
cheers! I just joined the group yesterday, and reading reading reading...
--- In l..., "Dennis Clark" wrote:
> > That's rather odd, and completely contrary to my experience with GCC.
> > I've
> > used it on MSP430's, AVRs, LPC2148/LPC2468, x86, and PowerPCs, and
never
> > run
> > into it being "fragile". In fact, I consider it to be far easier
to use
> > and
> > get started with than some packages I've run into, like IARs. And
a lot
> > more reliable with far fewer quirks than many of the inhouse rolled C
> > compilers (like the Microchip PIC18 compiler).
>
> Me too. I've found it "fragile" with ARM set ups, not the others.
Once
> I can generate code everything is fine - With the ARM GCC setups that
> I've tried (and I admit to being pretty green with ARM) I've found it
> difficult to move from this company's configuration (how they did their
> makefile, what IDE they used, etc.) to any other configuration.
>
> Again, I'm green with ARM, I've used GCC in plenty with plenty of other
> devices too. This could just be my experience and prejudice.
>
> IMO,
> DLC
>
> > --jc
> >
> > On Thu, Feb 19, 2009 at 10:00 AM, Dennis Clark wrote:
> >
> >>
> >> I so understand your position. The ARM toolchains that I have tried
> >> using GCC has been so fragile that if I deviate one little bit
from the
> >> layout of the demo package as supplied, I get nothing but heartburn
> >> trying to find and fix the problem. I've heard that Rowley is
going to
> >> release a "version 2" IDE/compiler that runs on OS X. I have
their AVR
> >> package on Windows and like it, others have used it at my last job on
> >> Windows for the ARM and spoke well of it. The price is better
than the
> >> "those other really expensive ones" as well and more affordable
to those
> >> of us that are independent consultant developers too. I can't wait to
> >> see what happens!
> >> ARM is a completely different bird from other processors because
of the
> >> incredible variety of strains and multiple vendors. Using one just
> >> isn't a simple process, at least as I'm discovering.
> >>
> >> DLC
> >>
> >
> >
> >
> >
> >
> >
> >
> >
> >
Again, my primary dev station is the mac. Can anyone let me know what
specific toolchain setup is the most stable for mac -> lpc2148.
I am currently building the latest of everything again.
My issues don't seem to be building, linking, or flashing. Its
running on the lpc2148. And then, I can do the basic hello world
stuff. I can run most examples I've found on the net (though not
successful with jcwren lpc2148_demo -yet. It hasn't compiled for me.)
that do not call math functions.
cheers! I just joined the group yesterday, and reading reading reading...
--- In l..., "Dennis Clark" wrote:
> > That's rather odd, and completely contrary to my experience with GCC.
> > I've
> > used it on MSP430's, AVRs, LPC2148/LPC2468, x86, and PowerPCs, and
never
> > run
> > into it being "fragile". In fact, I consider it to be far easier
to use
> > and
> > get started with than some packages I've run into, like IARs. And
a lot
> > more reliable with far fewer quirks than many of the inhouse rolled C
> > compilers (like the Microchip PIC18 compiler).
>
> Me too. I've found it "fragile" with ARM set ups, not the others.
Once
> I can generate code everything is fine - With the ARM GCC setups that
> I've tried (and I admit to being pretty green with ARM) I've found it
> difficult to move from this company's configuration (how they did their
> makefile, what IDE they used, etc.) to any other configuration.
>
> Again, I'm green with ARM, I've used GCC in plenty with plenty of other
> devices too. This could just be my experience and prejudice.
>
> IMO,
> DLC
>
> > --jc
> >
> > On Thu, Feb 19, 2009 at 10:00 AM, Dennis Clark wrote:
> >
> >>
> >> I so understand your position. The ARM toolchains that I have tried
> >> using GCC has been so fragile that if I deviate one little bit
from the
> >> layout of the demo package as supplied, I get nothing but heartburn
> >> trying to find and fix the problem. I've heard that Rowley is
going to
> >> release a "version 2" IDE/compiler that runs on OS X. I have
their AVR
> >> package on Windows and like it, others have used it at my last job on
> >> Windows for the ARM and spoke well of it. The price is better
than the
> >> "those other really expensive ones" as well and more affordable
to those
> >> of us that are independent consultant developers too. I can't wait to
> >> see what happens!
> >> ARM is a completely different bird from other processors because
of the
> >> incredible variety of strains and multiple vendors. Using one just
> >> isn't a simple process, at least as I'm discovering.
> >>
> >> DLC
> >>
> >
> >
> >
> >
> >
> >
> >
> >
> >
Reply by ●February 19, 20092009-02-19
On Thu, 19 Feb 2009, Dennis Clark wrote:
> The ARM toolchains that I have tried using GCC has been so fragile
> that if I deviate one little bit from the layout of the demo package
> as supplied, I get nothing but heartburn trying to find and fix the
> problem.
I HEARTILY disagree. I've used nothing but gcc for many years now, and
even build (actually only build) my own toolchains from scratch.
FYI,
-Kenny
--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Los Angeles
O: 3630 S. Sepulveda Blvd. #138, L.A., CA 90034-6809 (888) 454-8181
> The ARM toolchains that I have tried using GCC has been so fragile
> that if I deviate one little bit from the layout of the demo package
> as supplied, I get nothing but heartburn trying to find and fix the
> problem.
I HEARTILY disagree. I've used nothing but gcc for many years now, and
even build (actually only build) my own toolchains from scratch.
FYI,
-Kenny
--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Los Angeles
O: 3630 S. Sepulveda Blvd. #138, L.A., CA 90034-6809 (888) 454-8181
