Re: [avr-gcc-list] AVaRICE and gdb windows port

[David Brown]

> On 21 Feb 2003 at 8:39, David Brown wrote:
>
> >
> > Cygwin provides a posix api for programs running under windows, which
> > takes a lot of the effort out of such a port.  I think I read
> > somewhere that the most recent versions of Cygwin support /dev/tty
> > addressing for serial ports - even before that, the actual serial port
> > handling was the same, and it was just the addressing and openning of
> > the port that had to be changed. The socket side of the program should
> > be identical, as should the main part of the program.  Of course, it
> > all depends on someone who has a fair understanding of the program
> > also having a an understanding of porting to cygwin so that they can
> > get the details right.  I've fiddled a bit with ported programs (like
> > the equivilent program for the msp430), but my knowledge is limited to
> > having an idea of what is possible rather than an understanding of how
> > to do it (I use python for cross-platform programming).
>
> FYI, I provide the WinAVR distribution of the open source toolset for
> AVR software development for Windows. So I've built binutils, GCC,
> and avr-libc under MinGW; I've also built SRecord under Cygwin, and
> am doing some other stuff under Cygwin. WinAVR:
> <http://sourceforge.net/projects/winavr>
>

I'd better start off by thanking you, then - I expect I could have got the
tools compiled and working under cygwin (I've never really had much success
with MinGW - cygiwn seems to me to be slower but easier), but your
ready-to-run builds make life much easier!

Also, I appologise for directly emailing you - I had intended to post to the
list (I use a somewhat limited mail program that can't deal with replying to
lists like these automatically, and occasionally I forget and press the
wrong button).

>
> > >
> > > > avr-gdb is probably already working under windows (I haven't
> > > > tried it yet, since I could not get avarice to compile), given
> > > > that there are lots of other gdb's running under windows.
> > >
> > > AFAIK, it isn't working under windows.
> >
> > As I said, I haven't tried it yet - but do you know that it doesn't
> > work, or is it just that few people have tried it?
>
> Actually I misspoke and David Gay corrected me on this list. It *can*
> be built under Cygwin and there is an AVR target provided. However, I
> don't know if a Windows executable is provided at his nescc project.
> I haven't gotten around to building GDB for Windows because either
> SimulAVR is required or AVaRICE is required to work with it. Up until
> now, I haven't heard much requests for either one, though I would
> eventually like to build up all 3 and include them (as binaries) in
> the WinAVR project.

That would certainly be great.  Unfortunately, I have a demonstration of my
current project tomorrow, and it's not working yet, so I'm not going to get
a chance to try anything before then.  But I will have a shot at compiling
them under cygwin, and see how it goes.  I've had trouble in the past
getting Insight to work on Windows, but it seems to be ok for the msp430
port, and I have also found gvd to be great as a front-end under windows.

>
> > I am not looking for simulation (although that might be interesting
> > for the future), I am looking for in-circuit debugging.  As far as I
> > understand it, that means running gdb, connected (via a tcp/ip socket)
> > to AVaRICE, which connects to the jtag debugger hardware via a serial
> > port.  This is exactly the arrangement I use for the msp430 (replacing
> > "AVaRICE" with "rproxy" and "serial port" with "parallel port").
>
> I've taken a look around the msp430 project on SourceForge. That
> project and WinAVR seem to be trying to do a lot of similar things.
> Though WinAVR doesn't seem to have the number of tools that msp430
> has, yet.

I've used the msp430 gcc and friends for a couple of projects now, and find
them great.  Of course, the architecture of the msp430 is a better fit for
gcc (16-bit wide, single address space), making it a bit easier.

>
> Right now WinAVR includes:
> 1. binutils
> 2. GCC (C, C++)
> 3. avr-libc (Standard C library)
> 4. objtool (ELF to COFF converter)
> 5. Programmers Notepad 2 (editor)

I hadn't noticed that!  I normally use jedit, but pn could be very useful
too (jedit is powerful, but it's not exactly small and fast).

> 6. Unix / GNU utilities for Windows
> 7. Sample stuff (makefile and batch files)
> 8. Lots of documentation.

The documentation is very good - I've started using doxygen for my programs
too.

>
> So this provides the tools to edit, compile, assemble, link, and do
> some file conversions. There are still other tools that would be
> usefull to add to the set for more completeness and other
> improvements to it as well.
>
> Some future directions for WinAVR:
>
> 1. Programmers Notepad 2 will soon provide the ability to call
> command-line tools, i.e. become an IDE.

It's certainly very useful to be able to run a "make" from within the
editor, and get a list of the warnings and errors from the compilation.

>
> 2. Right now there is a big hole concerning debugging / simulating.
> There are a couple of different directions for this mainly having to
> do with converting ELF to AVR Extended COFF that way Atmel's AVR
> Studio can be used for debugging / simulating. Hopefully in the near
> future there will be some improvements in this area.
>

As far as I understand it, the latest version of AVR Studio 4 can deal with
extended coff debugging information.  In particular, that means that
structure and array debugging information from ImageCraft's compiler is
visible in the latest AVR Studio.  I haven't tried that myself (I have
recent version of the compiler, but am still running an older version of AVR
Studio - I have heard too many horror stories of new versions of AVR Studio
partially updating the jtag ice and leaving it unusable).

> 3. Add open source programmer software. This is coming along nicely.
> And I would really like to include this in the next release of WinAVR
> (schedule allowing). :-)

Will that support the AVR ISP programmer?

>
> 4. Add open source software for ICE.
>
> 5. Add the SRecord utilities. These are general purpose utilities for
> manipulating load files such as Intel Hex, Motorola S-Record, raw
> binary, etc.
>
> 6. Any other open source projects that would be useful for the AVR
> users community.
>
> The above list is by no means in order of priority. Though right now
> my current priorities are a better solution for debugging /
> simulating and programmer software.
>
> And before people get worried about how big the WinAVR package is
> going to get, I know that the open source installer package that I
> use to build the WinAVR installation will be adding (at some point) a
> new compression method that should show significantly more
> compression. :-)
>
> All of these projects are open-source and run by volunteers. Any help
> on any of these projects is certainly appreciated. There is a list of
> these projects with their web URLs in the README.txt file that comes
> with WinAVR.

If I can get anywhere with gdb and AVaRICE, I will certainly let you know.

Many thanks for the summary of the WinAVR project.

mvh.

David


>
> Eric
>
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden
> http://www.avr1.org/mailman/listinfo/avr-gcc-list