Re: [avr-gcc-list] [ANN] WinAVR 20030312 Released

[David Brown]

> On 12 Mar 2003 at 23:49, David Brown wrote:
>
> >
> > This is great!  I'm now using avarice and avr-gdb instead of AVR
> > Studio - finally I can inspect structures, arrays, pointers,
> > bitfields, enums, etc. I have a couple of questions/comments:
> >
> > I don't think it is a good idea for the installer to add winavr bin
> > directories to the path in this way.  It is a pain if you already have
> > similar unix-type utilities on your path - suddenly the winavr
> > versions are first in line.  To avoid conflicts with existing paths, I
> > would prefer the path modifications to be optional, and to be added to
> > the end of the path rather than the beginning.  Of course, the changes
> > are of a help to many people, and users like me who like to have
> > complicated systems can modify our paths manually afterwards.
>
> Ok, ok, ok. I added the automatic installation of the path because
> there were more newbies out there who didn't know the first thing
> about what an environment variable was much less how to change it.
> There's no pleasing everybody.
>
> I've seen other software automatically install dirs on the path
> without user permission for the simple fact that the software cannot
> easily run without it. I put if first in the path because somebody
> may have an old AVR Freaks version. In that case, if the WinAVR path
> came later, then the toolset will default to old versions from AVR
> Freaks, definitely a no no. The best I could do would probably be to
> add more docs in the README about how to change the PATH environment
> variable. At least I currently document what dirs get put on the path
> and what is included in the directories; and I specifically say that
> this is for the user to be able to swap out sets of Unix utilities if
> they want to.

As you say, there's no pleasing everybody!  It's certainly easy enough to
change afterwards - people who have good reason for not wanting it on the
path are probably going to know how to change the path.  If it is possible
to make it an option in the installer, then that would be great - otherwise,
catering for newbies is probably best.

>
> > The gdb build is command-line only.  Did you try to build insight?  As
> > an alternative, I like gvd ( http://libre.act-europe.fr/gvd/ ) as
> > front-end for gdb.  It is very easy to get it running (use
> > "c:\gvd-1.2.5\bin\gvd --debugger c:\winavr\bin\avr-gdb program.elf" ).
>
> The GDB build and the AVaRICE build were donated by Marc Wetzel (as
> stated in the README.txt). These were added relatively recently so I
> hadn't had time to look into building Insight.
>
> I recently discovered the link to gvd. I don't know much about it
> other than it looks like one can download binaries for NT (according
> to web site) and that it works with a command-line version of GDB. I
> couldn't figure out from their website if gvd will work on Win 98 /
> 95 though.
>

I believe it will, but I don't know for sure (I only have Win98 at home for
games, so I haven't tried it).

> To be honest, I have had zero experience with either GDB or AVaRICE.
> Perhaps you or others can share their experience with the Windows
> platform versions?
>

GDB has its advantages and disadvantages compared to AVR Studio.  It does
not have the I/O view window, and it is not as smooth to run.  But the
command-line interface is very flexible (once you have learned a bit about
it :-), and the ability to properly view structured data is very useful.
With GVD, you get a more graphical view of the data - it is particularly
strong when working with pointers, lists, and such complex data structures,
and uses arrows to show the links between things.

> > Am I right in thinking that I need to use avarice to burn a new
> > program into the flash before debugging, or is it possible to do it
> > via gdb?
>
> FYI, you can also program your device using the included avrdude
> software.

I'll be trying that later, with my avrisp programmer, to see how it compares
to the stk500 program (from avr studio 3).  I often run such programmers as
part of my "make" process - very often, I do development without bothering
to use a debugger at all, but just burn the new program and test it.

>
> Eric Weddington