1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Code Red for ARM Cortex M3 development - any good ?

Discussion in 'Embedded' started by Mike, Jul 5, 2012.

  1. Mike

    Mike Guest

    Hi,

    I am hardening up on using Code Red 4 for my new STM32L15xx based
    project and I wondered if anyone here can tell me from experience
    whether they have had any issues or problems with this tool set ?
    From what I've seen so far it seems OK and they've been quitre
    responsive by email. Price is good so all I need is the gotcha list
    to make a decision :)

    Thanks,

    Mike
     
    Mike, Jul 5, 2012
    #1
    1. Advertising

  2. Mike

    mi Guest

    Mike <> writes:

    Hi,
    >
    > I am hardening up on using Code Red 4 for my new STM32L15xx based
    > project and I wondered if anyone here can tell me from experience
    > whether they have had any issues or problems with this tool set ?


    We've used Code Red for quite a few projects with NXP LPC17xx series,
    FreeRTOS and bare iron. We had a few issues (with linker scripts if I remember
    correctly and for those the solutions from their KB and support were found easily.

    The ready FreeRTOS and other examples were very useful for us, too. The
    RedProbe+ sometimes hanged, but a reboot has always fixed it.

    Great value for money in my opinion.

    --
    Mikko
     
    mi, Jul 5, 2012
    #2
    1. Advertising

  3. Mike

    Guest

    On 5 Jul., 17:44, Mike <> wrote:
    > Hi,
    >
    > I am hardening up on using Code Red 4 for my new STM32L15xx based
    > project and I wondered if anyone here can tell me from experience
    > whether they have had any issues or problems with this tool set ?
    > From what I've seen so far it seems OK and they've been quitre
    > responsive by email.  Price is good so all I need is the gotcha list
    > to make a decision :)
    >
    > Thanks,
    >
    > Mike


    it's gcc, so I assume it is mostly a matter of the ide

    -Lasse
     
    , Jul 5, 2012
    #3
  4. Mike

    alb Guest

    On 7/5/2012 10:45 PM, wrote:
    > On 5 Jul., 17:44, Mike <> wrote:
    >> Hi,
    >>
    >> I am hardening up on using Code Red 4 for my new STM32L15xx based
    >> project and I wondered if anyone here can tell me from experience
    >> whether they have had any issues or problems with this tool set ?


    why using a closed tool when there are free and open development tools
    available with an increasingly active community?

    >> From what I've seen so far it seems OK and they've been quitre
    >> responsive by email. Price is good so all I need is the gotcha list
    >> to make a decision :)


    I was once used to program ADSP devices via VisualDSP IDE and I was
    'happy' with it. At that time I was a mildly happy Windows user not
    knowing anything about POSIX systems. But then I learned the advantages
    and the freedom of using GNU/Linux and coming back to a closed
    environment is simply not possible now.

    Unless is a choice forced by some kind of partnership, I would never
    choose to limit my freedom and IMO even though a FOSS toolchain may not
    be the optimal solution for the target the overall benefit you get is huge.

    >
    > it's gcc, so I assume it is mostly a matter of the ide


    Can someone here explain what is the gain of an IDE?
    I have to say that I hardly manage to find something rational or logical
    behind the IDEs, starting from the concept of 'project' that nearly all
    of them have but none of them describe formally.

    IMO the power you have with a Makefile goes way beyond the fancy icons
    of an IDE, let alone that is far more portable and free from copyrights.

    My 2 cents.
     
    alb, Jul 6, 2012
    #4
  5. Mike

    Rob Gaddi Guest

    On Fri, 06 Jul 2012 20:03:17 +0200
    alb <> wrote:

    >
    > Can someone here explain what is the gain of an IDE?
    > I have to say that I hardly manage to find something rational or logical
    > behind the IDEs, starting from the concept of 'project' that nearly all
    > of them have but none of them describe formally.
    >
    > IMO the power you have with a Makefile goes way beyond the fancy icons
    > of an IDE, let alone that is far more portable and free from copyrights.
    >
    > My 2 cents.


    God I love having an IDE when I'm debugging. Visual breakpoints,
    register display windows, expanded peripheral registers, all of that
    stuff is golden.

    And a good one also has good refactoring and code navigation tools that
    work across large numbers of files. I think you can get that level of
    power from emacs or vim as well, but I haven't managed to find it in
    any sensible editor.

    But yes, their concept of a "project", and their firm belief that they
    know better than me how to organize one, is like dental surgery on a
    moving truck.

    --
    Rob Gaddi, Highland Technology -- www.highlandtechnology.com
    Email address domain is currently out of order. See above to fix.
     
    Rob Gaddi, Jul 6, 2012
    #5
  6. Mike

    alb Guest

    On 7/6/2012 8:16 PM, Rob Gaddi wrote:
    > On Fri, 06 Jul 2012 20:03:17 +0200
    > alb <> wrote:
    >
    >>
    >> Can someone here explain what is the gain of an IDE?
    >> I have to say that I hardly manage to find something rational or logical
    >> behind the IDEs, starting from the concept of 'project' that nearly all
    >> of them have but none of them describe formally.
    >>
    >> IMO the power you have with a Makefile goes way beyond the fancy icons
    >> of an IDE, let alone that is far more portable and free from copyrights.
    >>
    >> My 2 cents.

    >
    > God I love having an IDE when I'm debugging. Visual breakpoints,
    > register display windows, expanded peripheral registers, all of that
    > stuff is golden.


    ever tried ddd? is a graphical front-end for command-line debuggers like
    gdb and will allow you to set breakpoints, display registers, variables
    and all that stuff.

    >
    > And a good one also has good refactoring and code navigation tools that
    > work across large numbers of files. I think you can get that level of
    > power from emacs or vim as well, but I haven't managed to find it in
    > any sensible editor.


    I use vim and emacs with ctags which is a very powerful yet simple tool
    to index and tag all variables and functions definitions, which then can
    be easily navigated.

    IMO if you have to work on a large number of files regularly I would
    reconsider the structure of your files :)

    >
    > But yes, their concept of a "project", and their firm belief that they
    > know better than me how to organize one, is like dental surgery on a
    > moving truck.
    >


    Right. That is incredibly irritating.

    And why reinvent the editor? each of these lousy IDE has its own editor
    which is irritatingly 20 years behind emacs or vim (I use emacs with
    VHDL extension and is a blessing!).
     
    alb, Jul 7, 2012
    #6
  7. Mike

    Tim Wescott Guest

    On Fri, 06 Jul 2012 11:16:31 -0700, Rob Gaddi wrote:

    > On Fri, 06 Jul 2012 20:03:17 +0200 alb <>
    > wrote:
    >
    >
    >> Can someone here explain what is the gain of an IDE?
    >> I have to say that I hardly manage to find something rational or
    >> logical behind the IDEs, starting from the concept of 'project' that
    >> nearly all of them have but none of them describe formally.
    >>
    >> IMO the power you have with a Makefile goes way beyond the fancy icons
    >> of an IDE, let alone that is far more portable and free from
    >> copyrights.
    >>
    >> My 2 cents.

    >
    > God I love having an IDE when I'm debugging. Visual breakpoints,
    > register display windows, expanded peripheral registers, all of that
    > stuff is golden.
    >
    > And a good one also has good refactoring and code navigation tools that
    > work across large numbers of files. I think you can get that level of
    > power from emacs or vim as well, but I haven't managed to find it in any
    > sensible editor.
    >
    > But yes, their concept of a "project", and their firm belief that they
    > know better than me how to organize one, is like dental surgery on a
    > moving truck.


    Which is why I use Eclipse almost exclusively. As long as it'll talk to
    the debugger, I get all the cool integrated debugging stuff, and when I
    save a file it invokes the makefile that I or a trusted coworker wrote.

    --
    Tim Wescott
    Control system and signal processing consulting
    www.wescottdesign.com
     
    Tim Wescott, Jul 7, 2012
    #7
  8. In article <>,
    says...
    >
    > On 7/5/2012 10:45 PM, wrote:
    > > On 5 Jul., 17:44, Mike <> wrote:
    > >> Hi,
    > >>
    > >> I am hardening up on using Code Red 4 for my new STM32L15xx based
    > >> project and I wondered if anyone here can tell me from experience
    > >> whether they have had any issues or problems with this tool set ?

    >
    > why using a closed tool when there are free and open development tools
    > available with an increasingly active community?
    >
    > >> From what I've seen so far it seems OK and they've been quitre
    > >> responsive by email. Price is good so all I need is the gotcha list
    > >> to make a decision :)

    >
    > I was once used to program ADSP devices via VisualDSP IDE and I was
    > 'happy' with it. At that time I was a mildly happy Windows user not
    > knowing anything about POSIX systems. But then I learned the advantages
    > and the freedom of using GNU/Linux and coming back to a closed
    > environment is simply not possible now.
    >
    > Unless is a choice forced by some kind of partnership, I would never
    > choose to limit my freedom and IMO even though a FOSS toolchain may not
    > be the optimal solution for the target the overall benefit you get is huge.


    What is that overall benefit? Better code generated more quickly?
    I've used GCC-ARM, Codewarrior, and IAR EW-ARM. I didn't find that
    GCC-ARM produced better code more quickly than the others.
    >
    > >
    > > it's gcc, so I assume it is mostly a matter of the ide

    >
    > Can someone here explain what is the gain of an IDE?


    IDEs are great at helping you generate complex make sequences without
    the necessity of typing file names, make commands, and options WITHOUT
    ERRORS. If I could type 100WPM without error and had memorized all the
    library file names, and compile options, I probably would have less use
    for an IDE.
    > I have to say that I hardly manage to find something rational or logical
    > behind the IDEs, starting from the concept of 'project' that nearly all
    > of them have but none of them describe formally.
    >
    > IMO the power you have with a Makefile goes way beyond the fancy icons
    > of an IDE, let alone that is far more portable and free from copyrights.


    To quote Lord Acton:
    "Power tends to corrupt, and absolute power corrupts absolutely."

    Makefiles can get you in trouble as often as they get you out of it.
    Some projects, such as building a linux distro, probably need the
    flexibility of make files and the supporting linux tools. OTOH, many
    embedded projects running on bare silicon, reduce to a make file of
    perhaps 20 or 30 lines. For those, an IDE that allows you to pick the
    processor, organize the libraries, stack, and heap, compile, link,
    download and debug with a series of menu items can save quite a bit of
    time in looking up and correctly typing file names and make commands.

    IMHO, a good IDE is a distillation of hundreds of hours spend by good
    programmers in distilling the essence of a programming environment down
    to a series of GUI elements. If it's done properly, you should never
    have to worry about misspelling a file name or generating a proper set
    of options for the compiler. If it's done really well, you can override
    any of the generated options and add you own.

    At some point, you have to relenquish the power that you get from
    writing your own make files, peripheral drivers, and libraries. People
    who use IDEs just do so a little sooner in the hope that they can spend
    more time on the problem, rather than on the process.
    >
    > My 2 cents.


    My son is taking an upper-division Computer Science class on operating
    systems. So far, the instructor has insisted that all problems be
    solved using the Linux command-line interface. It seems that the
    teaching of OS fundamentals hasn't changed much since I was a CS
    instructor in the mid 80's. What do you want to bet that he and his
    fellow students come out of that class thinking that writing your own
    make files is the best way to program a computer? ;-)

    Mark Borgerson
     
    Mark Borgerson, Jul 7, 2012
    #8
  9. Mike

    Paul Guest

    In article <>,
    says...
    >
    > On Fri, 06 Jul 2012 11:16:31 -0700, Rob Gaddi wrote:
    >
    > > On Fri, 06 Jul 2012 20:03:17 +0200 alb <>
    > > wrote:
    > >
    > >
    > >> Can someone here explain what is the gain of an IDE?
    > >> I have to say that I hardly manage to find something rational or
    > >> logical behind the IDEs, starting from the concept of 'project' that
    > >> nearly all of them have but none of them describe formally.
    > >>
    > >> IMO the power you have with a Makefile goes way beyond the fancy icons
    > >> of an IDE, let alone that is far more portable and free from
    > >> copyrights.
    > >>
    > >> My 2 cents.

    > >
    > > God I love having an IDE when I'm debugging. Visual breakpoints,
    > > register display windows, expanded peripheral registers, all of that
    > > stuff is golden.
    > >
    > > And a good one also has good refactoring and code navigation tools that
    > > work across large numbers of files. I think you can get that level of
    > > power from emacs or vim as well, but I haven't managed to find it in any
    > > sensible editor.
    > >
    > > But yes, their concept of a "project", and their firm belief that they
    > > know better than me how to organize one, is like dental surgery on a
    > > moving truck.

    >
    > Which is why I use Eclipse almost exclusively. As long as it'll talk to
    > the debugger, I get all the cool integrated debugging stuff, and when I
    > save a file it invokes the makefile that I or a trusted coworker wrote.


    As long as the makefile is human readable, not a nested bunch of
    makefiles auto generated that are specific to that IDE.

    One advantage I have found with makefiles properly constructed is they
    are quicker and easier to port to other processors/compilers/IDE than
    those autogenerated. In ten years time I cannot guarantee the
    auto-generated ones will be readable by newer versions of same IDE or
    compiler, not had problems with hand crafted ones.

    Don't even get me started on IDEs that have 'hidden' makefiles as
    part of their custom format project/workspace control file(s).

    With a makefile that is only 20-30 lines long it is just as easy to
    generate your own even with helper files for linker maps specific to
    processor. Too often I find autogenerated can lead to all sorts of
    ancilliary issues where you spend just as long finding out the build
    did not work because of some option on menus three levels down, or the
    third tab of option B, press button Z on this dialog to select this
    option. Getting auto generated is not a guarantee of success.

    On a couple of IDEs with their 'integrated' project description and
    'builder' control menus, I had to specify the processor three times
    for project, compiler and linker before it would work properly. This
    should have been specify once and use multiple times.

    The amount of time it takes to generate a hand crafted makefile for an
    embedded app is not long and it will be used thousand of times more than
    edited. Unlike some IDEs at tiomes I have seen regenerate makefiles
    as part of each build!


    --
    Paul Carpenter |
    <http://www.pcserviceselectronics.co.uk/> PC Services
    <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
    <http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
    <http://www.badweb.org.uk/> For those web sites you hate
     
    Paul, Jul 8, 2012
    #9
  10. Mike

    Tim Wescott Guest

    On Sun, 08 Jul 2012 03:36:37 +0100, Paul wrote:

    > In article <>,
    > says...
    >>
    >> On Fri, 06 Jul 2012 11:16:31 -0700, Rob Gaddi wrote:
    >>
    >> > On Fri, 06 Jul 2012 20:03:17 +0200 alb <>
    >> > wrote:
    >> >
    >> >
    >> >> Can someone here explain what is the gain of an IDE?
    >> >> I have to say that I hardly manage to find something rational or
    >> >> logical behind the IDEs, starting from the concept of 'project' that
    >> >> nearly all of them have but none of them describe formally.
    >> >>
    >> >> IMO the power you have with a Makefile goes way beyond the fancy
    >> >> icons of an IDE, let alone that is far more portable and free from
    >> >> copyrights.
    >> >>
    >> >> My 2 cents.
    >> >
    >> > God I love having an IDE when I'm debugging. Visual breakpoints,
    >> > register display windows, expanded peripheral registers, all of that
    >> > stuff is golden.
    >> >
    >> > And a good one also has good refactoring and code navigation tools
    >> > that work across large numbers of files. I think you can get that
    >> > level of power from emacs or vim as well, but I haven't managed to
    >> > find it in any sensible editor.
    >> >
    >> > But yes, their concept of a "project", and their firm belief that
    >> > they know better than me how to organize one, is like dental surgery
    >> > on a moving truck.

    >>
    >> Which is why I use Eclipse almost exclusively. As long as it'll talk
    >> to the debugger, I get all the cool integrated debugging stuff, and
    >> when I save a file it invokes the makefile that I or a trusted coworker
    >> wrote.

    >
    > As long as the makefile is human readable, not a nested bunch of
    > makefiles auto generated that are specific to that IDE.
    >
    > One advantage I have found with makefiles properly constructed is they
    > are quicker and easier to port to other processors/compilers/IDE than
    > those autogenerated. In ten years time I cannot guarantee the
    > auto-generated ones will be readable by newer versions of same IDE or
    > compiler, not had problems with hand crafted ones.
    >
    > Don't even get me started on IDEs that have 'hidden' makefiles as part
    > of their custom format project/workspace control file(s).
    >
    > With a makefile that is only 20-30 lines long it is just as easy to
    > generate your own even with helper files for linker maps specific to
    > processor. Too often I find autogenerated can lead to all sorts of
    > ancilliary issues where you spend just as long finding out the build did
    > not work because of some option on menus three levels down, or the third
    > tab of option B, press button Z on this dialog to select this option.
    > Getting auto generated is not a guarantee of success.
    >
    > On a couple of IDEs with their 'integrated' project description and
    > 'builder' control menus, I had to specify the processor three times for
    > project, compiler and linker before it would work properly. This should
    > have been specify once and use multiple times.
    >
    > The amount of time it takes to generate a hand crafted makefile for an
    > embedded app is not long and it will be used thousand of times more than
    > edited. Unlike some IDEs at tiomes I have seen regenerate makefiles as
    > part of each build!


    I guess that's another reason I like Eclipse: one click, and no more
    automatically generated makefile.

    I will grant you: if all you want is prototype code in a hurry, and to
    hell with anyone that has to work on things a year from now, then an IDE
    can be a boon.

    But if you want code that lasts, it can be Very Bad Indeed.

    --
    Tim Wescott
    Control system and signal processing consulting
    www.wescottdesign.com
     
    Tim Wescott, Jul 8, 2012
    #10
  11. Rob Gaddi wrote:
    > On Fri, 06 Jul 2012 20:03:17 +0200
    >>Can someone here explain what is the gain of an IDE?
    >>I have to say that I hardly manage to find something rational or logical
    >>behind the IDEs, starting from the concept of 'project' that nearly all
    >>of them have but none of them describe formally.
    >>
    >>IMO the power you have with a Makefile goes way beyond the fancy icons
    >>of an IDE, let alone that is far more portable and free from copyrights.
    >>
    >>My 2 cents.

    >
    > God I love having an IDE when I'm debugging. Visual breakpoints,
    > register display windows, expanded peripheral registers, all of that
    > stuff is golden.


    Sure, but that's a reason to get a decent debugger, not to get an IDE.
    Visual breakpoints or mixed asm/source view are pretty tricky if your
    source view doubles as a source editor.

    And if everything is visual, how do you set a breakpoint on printf?
    Solutions I have found so far in IDEs are "it's not possible" (VC6), or
    "click 'window->show view->modules', 'functions by name', 'malloc ..
    strcpy' (wording varies), 'printf', copy the address (note that Ctrl-C
    does not work), click 'window->show view->disassembly', paste the
    address into a five pixel wide field, press enter, double-click" (Code
    Composer Studio v4, based on Eclipse). Or "navigate to the libc source
    code if you have it, lose if you don't".

    Boy do I love the simplicity of a 'b printf' in gdb, Green Hills or
    Lauterbach.

    > And a good one also has good refactoring and code navigation tools that
    > work across large numbers of files. I think you can get that level of
    > power from emacs or vim as well, but I haven't managed to find it in
    > any sensible editor.


    Any sensible editor has support for ctags/etags, otherwise it doesn't
    deserve being called a sensible programmer's editor. This solves the
    navigation problem for me most of the time. Plus, my emacs has 1000
    files open anyway, so most of the time opening a file is C-x b
    name-of-file.c RET, no need to navigate through a file system. Try that
    with Eclipse.


    Stefan
     
    Stefan Reuther, Jul 8, 2012
    #11
  12. In article <>,
    says...
    >
    > Rob Gaddi wrote:
    > > On Fri, 06 Jul 2012 20:03:17 +0200
    > >>Can someone here explain what is the gain of an IDE?
    > >>I have to say that I hardly manage to find something rational or logical
    > >>behind the IDEs, starting from the concept of 'project' that nearly all
    > >>of them have but none of them describe formally.
    > >>
    > >>IMO the power you have with a Makefile goes way beyond the fancy icons
    > >>of an IDE, let alone that is far more portable and free from copyrights.
    > >>
    > >>My 2 cents.

    > >
    > > God I love having an IDE when I'm debugging. Visual breakpoints,
    > > register display windows, expanded peripheral registers, all of that
    > > stuff is golden.

    >
    > Sure, but that's a reason to get a decent debugger, not to get an IDE.
    > Visual breakpoints or mixed asm/source view are pretty tricky if your
    > source view doubles as a source editor.
    >
    > And if everything is visual, how do you set a breakpoint on printf?
    > Solutions I have found so far in IDEs are "it's not possible" (VC6), or
    > "click 'window->show view->modules', 'functions by name', 'malloc ..
    > strcpy' (wording varies), 'printf', copy the address (note that Ctrl-C
    > does not work), click 'window->show view->disassembly', paste the
    > address into a five pixel wide field, press enter, double-click" (Code
    > Composer Studio v4, based on Eclipse). Or "navigate to the libc source
    > code if you have it, lose if you don't".
    >
    > Boy do I love the simplicity of a 'b printf' in gdb, Green Hills or
    > Lauterbach.
    >
    > > And a good one also has good refactoring and code navigation tools that
    > > work across large numbers of files. I think you can get that level of
    > > power from emacs or vim as well, but I haven't managed to find it in
    > > any sensible editor.

    >
    > Any sensible editor has support for ctags/etags, otherwise it doesn't
    > deserve being called a sensible programmer's editor. This solves the
    > navigation problem for me most of the time. Plus, my emacs has 1000
    > files open anyway, so most of the time opening a file is C-x b
    > name-of-file.c RET, no need to navigate through a file system. Try that
    > with Eclipse.
    >

    This raises a few questions:

    1. Why does your emacs have 1000 files open?
    2. How do you pick the file you would like to edit among those 1000
    files?
    3. What projects do you work on that have 1000 files?
    4. How much system resources does it take to manage those 1000 files?

    Still, I suppose a thousand files isn't anything too extraordinary.
    After all, the W7 system that I'm using to write this post has 911
    active threads, 26,987 handles, and 71 active processes.

    Mark Borgerson
     
    Mark Borgerson, Jul 8, 2012
    #12
  13. Mike

    alb Guest

    On 7/7/2012 9:24 PM, Mark Borgerson wrote:
    [...]
    >> Unless is a choice forced by some kind of partnership, I would never
    >> choose to limit my freedom and IMO even though a FOSS toolchain may not
    >> be the optimal solution for the target the overall benefit you get is huge.

    >
    > What is that overall benefit? Better code generated more quickly?
    > I've used GCC-ARM, Codewarrior, and IAR EW-ARM. I didn't find that
    > GCC-ARM produced better code more quickly than the others.


    The benefit of using a FOSS toolchain, as I already said, does not
    necessarily comes from the optimal solution for the target, it comes
    from many aspects that IMO tend to come within it:

    - standardization: the FOSS community has always paid great attention to
    the necessity of agreeing upon standards, from file formats to protocols
    and much more. A closed tool has not such an interest and from time to
    time even different versions of the same tool do not support file
    formats they originally created.

    - support: there are many 'channels' on which you may get an incredible
    amount of support. Certainly proprietary tools also have their
    'support', but when the problems get hard to solve the support you get
    may depend on the size of your organization.

    - quality: 'peer review' is what lies behind the quality of your
    software. A widely open code can certainly receive much more reviews
    than a closed one.

    - flexibility: if you are not happy with what it does you can fix it.
    Even though it is hard that you will mess around with a cross compiler,
    nevertheless there are very skilled people out there who may do that and
    share their improvement without the need to sell you yet another version
    of the tool.

    - cost: even though you are working within a big company which may
    easily buy licenses, the aspect of the cost may be a show stopper for
    small businesses which eventually get stuck with a product and their
    'updates'.

    - freedom: the freedom to *use* the code the way you want (providing you
    do not violate the license agreement).

    >>
    >>>
    >>> it's gcc, so I assume it is mostly a matter of the ide

    >>
    >> Can someone here explain what is the gain of an IDE?

    >
    > IDEs are great at helping you generate complex make sequences without
    > the necessity of typing file names, make commands, and options WITHOUT
    > ERRORS. If I could type 100WPM without error and had memorized all the
    > library file names, and compile options, I probably would have less use
    > for an IDE.


    autogenerated 'make sequences' are very difficult to manage and
    certainly not easy to share between tools.
    The problem is not to type a file 'without errors', the problem is to
    know what you are doing with the 'make sequence', such that if you want
    to add/modify you can do it easily.

    I compile my code with one command:

    [me@work]$ make

    How hard is that to remember?
    And before releasing my version I compile with the following:

    [me@work]$ make 1>/dev/null

    which will help me found out if there are any warnings which I missed on
    the way.

    [...]
    >> IMO the power you have with a Makefile goes way beyond the fancy icons
    >> of an IDE, let alone that is far more portable and free from copyrights.

    >

    [...]
    > Makefiles can get you in trouble as often as they get you out of it.
    > Some projects, such as building a linux distro, probably need the
    > flexibility of make files and the supporting linux tools. OTOH, many
    > embedded projects running on bare silicon, reduce to a make file of
    > perhaps 20 or 30 lines. For those, an IDE that allows you to pick the
    > processor, organize the libraries, stack, and heap, compile, link,
    > download and debug with a series of menu items can save quite a bit of
    > time in looking up and correctly typing file names and make commands.


    A Makefile may work with any structure of directories and files you may
    invent, while an IDE will force you use their own choice. And what will
    happen if in the next version they decided to move the 'library'
    directory (what a silly one) into a folder called 'work' (just to remind
    you that you are there to work) in the directory called 'release'? Would
    your previously defined 'make sequence' work?

    Certainly they will be kind enough to let you 'import' the previous
    'project' with a special button on the top left corner which launches a
    'wizard' which will eventually say:

    "Congratulations! you successfully imported the project ABC. Beware that
    you cannot import this project back!"

    Personally, I don't find that quite amusing.

    >
    > IMHO, a good IDE is a distillation of hundreds of hours spend by good
    > programmers in distilling the essence of a programming environment down
    > to a series of GUI elements. If it's done properly, you should never
    > have to worry about misspelling a file name or generating a proper set
    > of options for the compiler. If it's done really well, you can override
    > any of the generated options and add you own.


    The 'essence of a programming environment' sometimes is what you want to
    have under your control, rather than somebody else's.

    >
    > At some point, you have to relinquish the power that you get from
    > writing your own make files, peripheral drivers, and libraries. People
    > who use IDEs just do so a little sooner in the hope that they can spend
    > more time on the problem, rather than on the process.


    Solving the 'problem' - as you call it - is usually the smallest part in
    the 'process' of writing software. The infrastructure of your software
    comes from the overall 'process' and the less solid it is the more you
    will suffer it when your software will grow a little beyond 'hello world'.

    The 'process' of software development doesn't differ very much from the
    'process' of building a bridge or a car. Very seldom your 'problem' will
    hit you, unless you are doing cutting edge research, where nevertheless
    having control over the 'process' will certainly help your productivity.

    Well, somebody once wrote: "East is East and West is West, and never the
    twain shall meet". It is clear to me that what you consider pros I see
    them as cons and viceversa.

    > My son is taking an upper-division Computer Science class on operating
    > systems. So far, the instructor has insisted that all problems be
    > solved using the Linux command-line interface. It seems that the
    > teaching of OS fundamentals hasn't changed much since I was a CS
    > instructor in the mid 80's. What do you want to bet that he and his
    > fellow students come out of that class thinking that writing your own
    > make files is the best way to program a computer? ;-)


    I hope they will enjoy the class and I hope they will appreciate the
    freedom you have when working on a GNU/Linux system.
     
    alb, Jul 9, 2012
    #13
  14. In article <>,
    says...
    >
    > On 7/7/2012 9:24 PM, Mark Borgerson wrote:
    > [...]
    > >> Unless is a choice forced by some kind of partnership, I would never
    > >> choose to limit my freedom and IMO even though a FOSS toolchain may not
    > >> be the optimal solution for the target the overall benefit you get is huge.

    > >
    > > What is that overall benefit? Better code generated more quickly?
    > > I've used GCC-ARM, Codewarrior, and IAR EW-ARM. I didn't find that
    > > GCC-ARM produced better code more quickly than the others.

    >
    > The benefit of using a FOSS toolchain, as I already said, does not
    > necessarily comes from the optimal solution for the target, it comes
    > from many aspects that IMO tend to come within it:
    >
    > - standardization: the FOSS community has always paid great attention to
    > the necessity of agreeing upon standards, from file formats to protocols
    > and much more. A closed tool has not such an interest and from time to
    > time even different versions of the same tool do not support file
    > formats they originally created.
    >
    > - support: there are many 'channels' on which you may get an incredible
    > amount of support. Certainly proprietary tools also have their
    > 'support', but when the problems get hard to solve the support you get
    > may depend on the size of your organization.
    >
    > - quality: 'peer review' is what lies behind the quality of your
    > software. A widely open code can certainly receive much more reviews
    > than a closed one.
    >
    > - flexibility: if you are not happy with what it does you can fix it.
    > Even though it is hard that you will mess around with a cross compiler,
    > nevertheless there are very skilled people out there who may do that and
    > share their improvement without the need to sell you yet another version
    > of the tool.
    >
    > - cost: even though you are working within a big company which may
    > easily buy licenses, the aspect of the cost may be a show stopper for
    > small businesses which eventually get stuck with a product and their
    > 'updates'.
    >
    > - freedom: the freedom to *use* the code the way you want (providing you
    > do not violate the license agreement).
    >
    > >>
    > >>>
    > >>> it's gcc, so I assume it is mostly a matter of the ide
    > >>
    > >> Can someone here explain what is the gain of an IDE?

    > >
    > > IDEs are great at helping you generate complex make sequences without
    > > the necessity of typing file names, make commands, and options WITHOUT
    > > ERRORS. If I could type 100WPM without error and had memorized all the
    > > library file names, and compile options, I probably would have less use
    > > for an IDE.

    >
    > autogenerated 'make sequences' are very difficult to manage and
    > certainly not easy to share between tools.
    > The problem is not to type a file 'without errors', the problem is to
    > know what you are doing with the 'make sequence', such that if you want
    > to add/modify you can do it easily.
    >
    > I compile my code with one command:
    >
    > [me@work]$ make
    >
    > How hard is that to remember?
    > And before releasing my version I compile with the following:
    >
    > [me@work]$ make 1>/dev/null
    >
    > which will help me found out if there are any warnings which I missed on
    > the way.
    >
    > [...]
    > >> IMO the power you have with a Makefile goes way beyond the fancy icons
    > >> of an IDE, let alone that is far more portable and free from copyrights.

    > >

    > [...]
    > > Makefiles can get you in trouble as often as they get you out of it.
    > > Some projects, such as building a linux distro, probably need the
    > > flexibility of make files and the supporting linux tools. OTOH, many
    > > embedded projects running on bare silicon, reduce to a make file of
    > > perhaps 20 or 30 lines. For those, an IDE that allows you to pick the
    > > processor, organize the libraries, stack, and heap, compile, link,
    > > download and debug with a series of menu items can save quite a bit of
    > > time in looking up and correctly typing file names and make commands.

    >
    > A Makefile may work with any structure of directories and files you may
    > invent, while an IDE will force you use their own choice. And what will
    > happen if in the next version they decided to move the 'library'
    > directory (what a silly one) into a folder called 'work' (just to remind
    > you that you are there to work) in the directory called 'release'? Would
    > your previously defined 'make sequence' work?


    Are you saying that you don't have to change the makefile if the source
    files get moved? That hasn't been my experience unless ALL the files
    are in the same directory tree. Most of the IDEs that I've used allow
    one to move a whole project directory tree without problems.

    A good IDE also allows you to define variables for various library and
    header file directories.
    >
    > Certainly they will be kind enough to let you 'import' the previous
    > 'project' with a special button on the top left corner which launches a
    > 'wizard' which will eventually say:
    >
    > "Congratulations! you successfully imported the project ABC. Beware that
    > you cannot import this project back!"
    >
    > Personally, I don't find that quite amusing.
    >
    > >
    > > IMHO, a good IDE is a distillation of hundreds of hours spend by good
    > > programmers in distilling the essence of a programming environment down
    > > to a series of GUI elements. If it's done properly, you should never
    > > have to worry about misspelling a file name or generating a proper set
    > > of options for the compiler. If it's done really well, you can override
    > > any of the generated options and add you own.

    >
    > The 'essence of a programming environment' sometimes is what you want to
    > have under your control, rather than somebody else's.


    That's certainly true if your goal is to build a programming
    environment, rather than a standalone application. However, every
    minute you spend on controlling the environment is a minute you don't
    spend writing and documenting your application.
    >
    > >
    > > At some point, you have to relinquish the power that you get from
    > > writing your own make files, peripheral drivers, and libraries. People
    > > who use IDEs just do so a little sooner in the hope that they can spend
    > > more time on the problem, rather than on the process.

    >
    > Solving the 'problem' - as you call it - is usually the smallest part in
    > the 'process' of writing software. The infrastructure of your software
    > comes from the overall 'process' and the less solid it is the more you
    > will suffer it when your software will grow a little beyond 'hello world'.



    You're writing a different kind of software than me. I'm working on
    embedded applications for the Cortex-M3 and MSP430. Each project has
    between 10 and 15 source files and the final object code is from 20 to
    60Kbytes. The most time-consuming part of each project is writing the
    code to set up and manage the peripheral devices (SD cards, USB ports,
    timers, A/D converters, etc. These projects also involve my designing
    the circuits, laying out the PCB and assembling and testing the board.
    When all those things are done, I have little time left over for
    controlling my programming environment.
    >
    > The 'process' of software development doesn't differ very much from the
    > 'process' of building a bridge or a car. Very seldom your 'problem' will
    > hit you, unless you are doing cutting edge research, where nevertheless
    > having control over the 'process' will certainly help your productivity.


    I can see that if your goal is to generate code more efficiently, FOSS
    software may be a help. However, if your goal is to generate more
    efficient code, I don't see it being much help.
    >
    > Well, somebody once wrote: "East is East and West is West, and never the
    > twain shall meet". It is clear to me that what you consider pros I see
    > them as cons and viceversa.


    I do agree that FOSS software and tool chains are a good idea and good
    for the software developer in general. If nothing else, they provide
    some competition and benchmarks for the commercial tool vendors.
    >
    > > My son is taking an upper-division Computer Science class on operating
    > > systems. So far, the instructor has insisted that all problems be
    > > solved using the Linux command-line interface. It seems that the
    > > teaching of OS fundamentals hasn't changed much since I was a CS
    > > instructor in the mid 80's. What do you want to bet that he and his
    > > fellow students come out of that class thinking that writing your own
    > > make files is the best way to program a computer? ;-)

    >
    > I hope they will enjoy the class and I hope they will appreciate the
    > freedom you have when working on a GNU/Linux system.


    It's ironic that the appreciation of that freedom starts with a list of
    tools the students CANNOT use. ;-) Linux has a lot of good features---
    but making it easy to directly control the peripheral devices is not one
    of them.

    Mark Borgerson
     
    Mark Borgerson, Jul 9, 2012
    #14
  15. Mike

    Rob Gaddi Guest

    On Sat, 7 Jul 2012 12:24:31 -0700
    Mark Borgerson <> wrote:

    > > Unless is a choice forced by some kind of partnership, I would never
    > > choose to limit my freedom and IMO even though a FOSS toolchain may not
    > > be the optimal solution for the target the overall benefit you get is huge.

    >
    > What is that overall benefit? Better code generated more quickly?
    > I've used GCC-ARM, Codewarrior, and IAR EW-ARM. I didn't find that
    > GCC-ARM produced better code more quickly than the others.
    > >

    >


    Permanence. By using gcc, I know that I will always, always, always be
    able to get my exact toolchain back if I try hard enough. I won't have
    to try to contact a defunct company's license server to reinstall on a
    machine with a new MAC address or hard disk ID, or a still-existing
    company who will no longer provide licenses for "ancient" tools.

    It might take me going all the way back to rebuilding gcc and newlib
    from source, and that might take me days, but it's not impossible.

    --
    Rob Gaddi, Highland Technology -- www.highlandtechnology.com
    Email address domain is currently out of order. See above to fix.
     
    Rob Gaddi, Jul 9, 2012
    #15
  16. Mark Borgerson wrote:
    > In article <>,
    >>Rob Gaddi wrote:
    >>>And a good one also has good refactoring and code navigation tools that
    >>>work across large numbers of files. I think you can get that level of
    >>>power from emacs or vim as well, but I haven't managed to find it in
    >>>any sensible editor.

    >>
    >>Any sensible editor has support for ctags/etags, otherwise it doesn't
    >>deserve being called a sensible programmer's editor. This solves the
    >>navigation problem for me most of the time. Plus, my emacs has 1000
    >>files open anyway, so most of the time opening a file is C-x b
    >>name-of-file.c RET, no need to navigate through a file system. Try that
    >>with Eclipse.

    >
    > This raises a few questions:
    >
    > 1. Why does your emacs have 1000 files open?


    Why not?

    > 2. How do you pick the file you would like to edit among those 1000
    > files?


    C-x b name-of-file.c RET

    Or, actually, F10 (my shortcut for C-x b) nam<TAB>fi<TAB>c RET, using
    completion.

    > 3. What projects do you work on that have 1000 files?


    Automotive infotainment, from low level (boot loader) through the whole
    stack (drivers, file system, codec), to high level (HMI adaption).

    > 4. How much system resources does it take to manage those 1000 files?


    The emacs process has a memory footprint of about 50-100 megabytes,
    containing all those files, and their undo data for the last half year.

    About the same size as an Eclipse with no files open.


    Stefan
     
    Stefan Reuther, Jul 9, 2012
    #16
  17. In article <>,
    says...
    >
    > Mark Borgerson wrote:
    > > In article <>,
    > >>Rob Gaddi wrote:
    > >>>And a good one also has good refactoring and code navigation tools that
    > >>>work across large numbers of files. I think you can get that level of
    > >>>power from emacs or vim as well, but I haven't managed to find it in
    > >>>any sensible editor.
    > >>
    > >>Any sensible editor has support for ctags/etags, otherwise it doesn't
    > >>deserve being called a sensible programmer's editor. This solves the
    > >>navigation problem for me most of the time. Plus, my emacs has 1000
    > >>files open anyway, so most of the time opening a file is C-x b
    > >>name-of-file.c RET, no need to navigate through a file system. Try that
    > >>with Eclipse.

    > >
    > > This raises a few questions:
    > >
    > > 1. Why does your emacs have 1000 files open?

    >
    > Why not?
    >
    > > 2. How do you pick the file you would like to edit among those 1000
    > > files?

    >
    > C-x b name-of-file.c RET


    WOW! you can keep track of 1000 file names in your head. I have
    trouble remembering the last 50 files I've used.
    >
    > Or, actually, F10 (my shortcut for C-x b) nam<TAB>fi<TAB>c RET, using
    > completion.
    >
    > > 3. What projects do you work on that have 1000 files?

    >
    > Automotive infotainment, from low level (boot loader) through the whole
    > stack (drivers, file system, codec), to high level (HMI adaption).


    That's a much larger system than any I've worked on. Even the flight
    control system I worked on had only about 50-60 files---but we used
    pretty standard drivers for everything and depended on the OS (linux) to
    provide those, so we didn't have to recompile them.
    >
    > > 4. How much system resources does it take to manage those 1000 files?

    >
    > The emacs process has a memory footprint of about 50-100 megabytes,
    > containing all those files, and their undo data for the last half year.


    Does the EMACs process have all the file structures, or does the OS have
    them and EMACS just keeps file handles?
    >
    > About the same size as an Eclipse with no files open.
    >


    The IAR IDE with no files open uses 47MB. Each file opened adds about
    4K, so 1000 files would add only 4MB. I don't know how the editor
    would handle having that many tabs in the top bar, though. ;-)

    With the C-Spy debugger running and several debugger windows open, EW-
    ARM goes up to 48.5MB.




    Mark Borgerson
     
    Mark Borgerson, Jul 10, 2012
    #17
  18. Mike

    alb Guest

    On 7/9/2012 6:33 PM, Rob Gaddi wrote:
    >> What is that overall benefit? Better code generated more quickly?
    >> I've used GCC-ARM, Codewarrior, and IAR EW-ARM. I didn't find that
    >> GCC-ARM produced better code more quickly than the others.
    >>>

    >>

    >
    > Permanence. By using gcc, I know that I will always, always, always be
    > able to get my exact toolchain back if I try hard enough. I won't have
    > to try to contact a defunct company's license server to reinstall on a
    > machine with a new MAC address or hard disk ID, or a still-existing
    > company who will no longer provide licenses for "ancient" tools.


    Confirmed. I had to build from scratch the g21k cross-compiler based on
    gcc-2.3.3 with my gcc-4.4.1. I needed to change few obsolete things, but
    after some struggle I did manage to compile the compiler and the
    binutils (linker, assembler...).

    Certainly YMMV, but as a counter example, when I needed VisualDSP
    running I had to look for an old computer in order to install Windows98
    and have it working with the EZ-ICE on the ISA. After having found the
    right hardware combination, installing network drivers with a 3.5inch
    disk, I decided to hell with VisualDSP and started my journey with g21k.

    I'm still missing the possibility to hook up the emulator, but I decided
    I can build my own debugging tools within the code itself, which
    certainly will pay off when I will have no possibility at all to hook up
    anything since the hardware is in space.

    >
    > It might take me going all the way back to rebuilding gcc and newlib
    > from source, and that might take me days, but it's not impossible.
    >


    Took me a little more than 'days', but I now feel much more satisfied
    than once was.
     
    alb, Jul 10, 2012
    #18
  19. Mike

    Walter Banks Guest

    Mark Borgerson wrote:

    > In article <>,
    > says...
    > >


    > > The 'essence of a programming environment' sometimes is what you want to
    > > have under your control, rather than somebody else's.

    >
    > That's certainly true if your goal is to build a programming
    > environment, rather than a standalone application. However, every
    > minute you spend on controlling the environment is a minute you don't
    > spend writing and documenting your application.


    I agree. The high cost of application development using FOSS
    comes from tools instead of application focus.

    Changes that are made by FOSS developers rarely go through the
    rigorous design and testing that commercial tools go through and
    as soon as applications become large enough then change change side
    effects start to take there toll on debugging and implementation time.


    > I can see that if your goal is to generate code more efficiently, FOSS
    > software may be a help. However, if your goal is to generate more
    > efficient code, I don't see it being much help.


    > > Well, somebody once wrote: "East is East and West is West, and never the
    > > twain shall meet". It is clear to me that what you consider pros I see
    > > them as cons and viceversa.

    >
    > I do agree that FOSS software and tool chains are a good idea and good
    > for the software developer in general. If nothing else, they provide
    > some competition and benchmarks for the commercial tool vendors.


    FOSS impacts commercial tools in a couple ways. They have forced the
    cost of commercial tools up primarily by impacting the easy sales. The
    support aspect of commercial tools has changed and become more formal
    with fewer releases and more attention being made to international standards.

    In the automotive area for example not only are language standards being
    tested but there are becoming standardized regression tests that are used
    by tool vendors.

    Most of the FOSS tools are using 20+ year old technology whose code
    generation is weak.

    w..
     
    Walter Banks, Jul 10, 2012
    #19
  20. Mike

    Walter Banks Guest

    alb wrote:

    > On 7/7/2012 9:24 PM, Mark Borgerson wrote:
    > [...]
    > > What is that overall benefit? Better code generated more quickly?
    > > I've used GCC-ARM, Codewarrior, and IAR EW-ARM. I didn't find that
    > > GCC-ARM produced better code more quickly than the others.

    >
    > The benefit of using a FOSS toolchain, as I already said, does not
    > necessarily comes from the optimal solution for the target, it comes
    > from many aspects that IMO tend to come within it:
    >
    > - standardization: the FOSS community has always paid great attention to
    > the necessity of agreeing upon standards, from file formats to protocols
    > and much more. A closed tool has not such an interest and from time to
    > time even different versions of the same tool do not support file
    > formats they originally created.


    The FOSS community has a lot of Ad Hoc standards but doesn't
    participate in standards groups and generally don't support formal
    standards. Commercial tools do and that makes them much more
    flexible to use in unusual combinations of code generation toolsets,
    simulators, emulators and debug devices.

    This is especially true of language implementation in FOSS tools
    and conformance to IEC / ISO standards. I have been shocked that
    of all the work that has been done on tools sets very little has been
    done in the FOSS community on conformance testing.

    w..
     
    Walter Banks, Jul 10, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ilgaz Ocal
    Replies:
    0
    Views:
    1,394
    Ilgaz Ocal
    Jun 5, 2005
  2. Oliver Betz

    Re: Gnu tools for ARM Cortex development

    Oliver Betz, May 4, 2010, in forum: Embedded
    Replies:
    1
    Views:
    273
    Oliver Betz
    May 5, 2010
  3. John Devereux

    Re: Gnu tools for ARM Cortex development

    John Devereux, May 4, 2010, in forum: Embedded
    Replies:
    1
    Views:
    262
    John Devereux
    May 4, 2010
  4. Ulf Samuelsson

    Re: Gnu tools for ARM Cortex development

    Ulf Samuelsson, May 19, 2010, in forum: Embedded
    Replies:
    34
    Views:
    1,036
    Ulf Samuelsson
    Jun 3, 2010
  5. Mike
    Replies:
    19
    Views:
    2,254
Loading...

Share This Page