Re: [avr-chat] AVR IDE [WAS: UISP / AVRDude : what to choose ?]

[David Brown]

----- Original Message -----
From: "E. Weddington" <address@hidden>

> Vincent Trouilliez wrote:
>
> >><sarcasm>
> >>The obvious answer is that if its already good then its time to
> >>handicap ourselves in order to compete on a level playing field.
> >>Eliminate the advantage we have over GUI and overload the developer
> >>with glitz, bells, and whistles, with a single unified
> >>point-and-click development environment! We need to hide all our
> >>configuration options in a binary project file under a GUI with
> >>nested menus rather than a Makefile so only the original developer
> >>has any idea (if he/she remembers) as to what is happening.
> >>
> >>It seems to work for Microsoft, it must be right!
> >>
> >>Not only Microsoft but Metrowerks CodeWarrior follows the same
> >>model.
> >>
> >>And so many ask for it, It Must Be Right(tm).
> >></sarcasm>
> >>
> >>
> >
> >
> >I always fail to see why those that don't want GUI's in Linux, complain
> >about them. It's just that, a GUI, a front-end. If you feel you need it,
> >use it. If you prefer using the underlying back-end /command line tool
> >directly, you can do so as well of course. Everyone can use the tool
> >that suits him best at any given time. The same person might use the GUI
> >to manage a large project and benefit from the project manager one day,
> >and the other day prefer the command line because he has just a tiny
> >quick test program that's more straight forward to do at the command
> >line "by hand". It's like CD burning apps, there are hundreds of them,
> >and all rely only on 2 or 3 command line tools. If you feel like burning
> >your CD's by hand do it, nobody's forcing you to use a GUI ! Really, I
> >don't understand this 'war'. GUI's are just there for when you want/need
> >them, they have NEVER forced anyone to give up using the underlying
> >command line tools directly !!! As far as I know. So I really don't
> >understand this 'war', pointless :-/
> >
> >
> >
> >
> >>These are the kind of problems I had with Microchip's MPLAB. At
> >>least with the relatively small assembly projects one could hunt
> >>down each and every option and override project settings from the
> >>assembly file. That MPLAB was so stupid as to reference all files
> >>with absolute paths, rendering a project which could not be moved in
> >>the filesystem. That if archived *must* be restored in exactly the
> >>same place, and MPLAB must also be installed in exactly the same
> >>place as originally.
> >>No, I am not interested in "enhancing" avr-gcc along those lines.
> >>
> >>
> >
> >So just because there is (at least) one crap IDE under Windows, means
> >that Linux folks will inevitably be only capable of developing as bad an
> >IDE ?
> >
> >
> >
> Ok, let's step back and take a deep breath.
>
> There's really no need for this to devolve into a religious argument.
>
> I agree with David Kelly in the sense that *arbitrarily hiding important
> project information behind a binary-based GUI* is a Bad Thing. I've seen
> these issues too. I agree too with Vincent in that *a properly
> implemented GUI is nothing more than a graphical layer in front of
> command-line tools which anyone can get to at any time*. What David
> describes seems to be the paradigm adopted by many Windows-centric
> developers (including MS themselves). What Vincent describes is the
> paradigm adopted by Unix and Unix-like systems.
>
> I feel that there is a way to do both. Be able to provide a GUI layer to
> make it easy for a novice developer, or for an experienced user to start
> a project quickly. *And* provide the user (who is an embedded systems
> engineer and is very knowledgeable) with the means to get at the very
> lowest level to do any and all customization desired, to be able to get
> down to the nuts and bolts. This system should be *very open*, where
> nothing about the project is hidden. That it should not impose any rigid
> structure (e.g. absolute paths, etc.) unless the user specifies it. That
> it can be made cross-platform. That it can be scaled by being able to
> easily add new tools.
>
> Does this sound desirable?
>
> I hope so, because this system is already in the works..... :-)
>
> Eric
>

There is nothing like a good compromise - everyone is equally dissatisfied !

Seriously, I agree with Eric here - there is no need to throw out everything
"gui" because of some bad examples, but users should never be forced into
using a gui.  I too have used a Metroworks compiler (for a 68HC08 chip), and
it is bloatware beyond compare.  What I needed was a compiler for a small
chip with up to 4k flash - what I got was 650 MB of useless "wizzards" for
building libraries of device drivers for the part.  It might sound like a
good idea to be able to add ADC and timer drivers with a few mouse clicks,
but when these take up half the available program space, I prefer to read a
little of the datasheet and replace about 1.5 KB of junk with about 6
program lines (honestly, I'm not making these numbers up!).  Such guis are
attempts to bring the world of visual basic to the world of small-systems
embedded programming - they patronise and irritate experianced developers,
hide essential learning skills from newbies and hobbyists, and fool PHB's
into thinking anyone can dive straight in and make reliable efficient
embedded systems.

But there is definitely a place for graphic interfaces in tools to augment
the fundamental development tools.  Most people these days use windowed
editors, and windowed file managers, and read their avr-libc documentation
using a windowed browser.  For some types of debugging, a windowed debugger
is a lot more productive than command-line gdb (I sometimes use gvd as a
front-end to gdb).  What's important here is for people to be able to choose
the tools that they feel productive and familiar with.  I work with about
half a dozen different microcontroller architectures on a daily basis - I
want to be able to choose the same tools for each of these, rather than
being forced into some marketing robot's idea of a "perfect" IDE.  That's
one of the major reasons why I use gcc and friends.

Many people, however, like the idea of a more complete, integrated package -
especially when starting with a new system.  I've often found "project
wizards" to be useful for setting up a project, generating makefiles,
picking compiler flags and the like.  Once I'm familiar with the tools, I
can hand-edit the makefile and work on with my tools of choice.  It's
imporant that it is easy to use external tools along with parts of the IDE.

As for your work so far, Eric, I look forward to trying it.  It certainly
sounds like you are putting together a package that will suit a wide range
of users.  There are a few things that I hope you have included in the new
IDE.  To start with, I hope you are using a third-party editor component
such as Scintilla - there is no point in re-inventing the wheel here.  I
hope you've included a solid debugger (using gdb underneath) - especially if
it has templates for different devices, so that you can easily show input
and output pins and registers.  I hope it is not too avr-specific - the
msp430-gcc project could benifit from such an IDE too.  And I hope is it
fairly fast and light-weight - maybe written in Python rather than a monster
heavyweight Java system like Eclipse.  (Of course, you may have simply made
Eclipse plugins - trading the resource requirements of Eclipse for the
development benifits of using Eclipse as a starting point.)

mvh,

David