I have released AVaRICE version 2.8 today.
Release Notes:
http://sourceforge.net/project/s...
Download Link:
http://sourceforge.net/project/s...
I expect the package maintainers of precompiled packages (like WinAVR,
or the individual Linux and FreeBSD package maintainers) to pick up that
version with their next major releases.
Release notes look great, thanks for the update, Jörg!
EW 
I expect the package maintainers of precompiled packages (like WinAVR,
or the individual Linux and FreeBSD package maintainers) to pick up that
version with their next major releases.
Hmm. You might want to have a talk with that FreeBSD guy. He's been a bit of a slacker lately. ;) :lol:
Hmm. You might want to have a talk with that FreeBSD guy. He's been a bit of a slacker lately. ;) :lol:
LMAO :lol: :lol:
Btw: In order to comply with the "guru's" chanting above :wink: :wink:
I have just made a test compile , and i had to install the binutils-dev package Ubuntu-8.0.4.1 (hardy) .
./configure was missing something in libbfd.a
Ps: do also tell the same bsd guy about the patch problem in the linux buildscript thread ...
/Bingo
EW wrote:
> Hmm. You might want to have a talk with that FreeBSD guy. He's been a bit of a slacker lately. ;)
Oh, I did, and he meanwhile got approval from the FreeBSD
portsmeisters to commit the change despite of the ports
freeze that just started today. ;-) (Fortunately, the
upgrade revealed another fault in the location the man
pages have been installed to which was fixed in the same
run as the upgrade to AVaRICE-2.8, so this was a good
excuse to request permission.)
EW
Oh, I did, and he meanwhile got approval from the FreeBSD
portsmeisters
Hey, is that an official title? ;)
to commit the change despite of the ports
freeze that just started today. ;-)
Oh, well, then all is forgiven. It's obvious this guy has some clout, being able to halt FreeBSD in it's tracks with a lift of his finger. I mean, one might think that this guy used to be on some FreeBSD committee or something...
;)
priyend Hi.
How do I get AVARICE working in Windows with AVR Dragon?
I have tried the "-g" and "-j usb" both separately and together but I still get an error stating :
did not find any USB device "usb"
Hardware setup is correct since AVR Studio debugging works.
I need AVARICE to work because I use the Eclipse CDT environment for development and want to use the GDB debugger.
Please help.
Best regards
Priyend
Hi.How do I get AVARICE working in Windows with AVR Dragon?
I've written a simple howto here: https://www.avrfreaks.net/index.p.... Look a little down the page.
> did not find any USB device "usb"
Go to the libusb-win32 project on sourceforge.net, get the "filter"
package, and install it instead of the standalone driver that ships
with WinAVR. The standalone driver is meant to work without the
Jungo driver AVR Studio is installing, while the filter package will
work /on top/ of the Jungo driver.
jesper 
Jörg, any comments on the debugging problems I noted with Avarice in this thread?
https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=65939
> Jörg, any comments on the debugging problems I noted
> with Avarice in this thread?
Not really, except that I neither use Eclipse nor Insight so I
cannot judge about their GDB interface (I use Emacs for about
every software work, be it AVR-related or on the host system
itself), and I haven't really observed similar behaviour except
in cases where I could blame the compiler inlining for. In the
case of an inlined function call, GDB has no chance to "step
over" because it wants to single-step until the end the current
stack frame. In the end, I tend to much more frequently use temporary
breakpoints instead of extensive single-stepping.
AVR Studio can perhaps handle the latter since they use an entirely
different implementation. Essentially, they offload the knowledge
about the high-level language line numbers into the JTAG ICE itself.
This is a unique solution which is quite efficient for the job but
so much out of scope for the concepts of GDB that it cannot be used
there -- for example, AVR32 thus cannot use it either. OTOH, GDB's
knowledge about stack frames, while not always 100 % correct (there's
a lot of guesswork involved) offers other features AVR Studio could
not offer at all, like displaying variables in non-current stack
frames (remember all those "out of scope" messages?), or displaying
the call stack including the arguments. (On the AVR, GDB often
gets the arguments wrong because they are placed in registers which
subsequently get overwritten -- this feature works better on architectures
like IA32 which have so few registers to spare that all arguments are
always passed on the stack).
jesper The problems were the same, whether I used Eclipse, Insight or straight GDB.
Code was compiled with -O0 -g, so all debug info should be there. There was no inlining.
I've tried a few variants, but step-over or finish just doesn't work at all. Step and regular breakpoints work fine though, as long as you remember the nreakpoint limit.
A shame, becase Eclipse with OOCD on ARM works just beautifully. It would have been nice to have an Eclipse solution for AVR too.
But Atmel seems to be working on something there. Hopefully.
> Step and regular breakpoints work fine though, as long as you
> remember the nreakpoint limit.
Except for the ATmega128 that has no (working) BREAK instruction, there
should not be a breakpoint limit anymore at all. You just have to keep
in mind that soft BPs are contributing to flash wear.
Funny enough, whenever I debug a debugWIRE device (which /only/ offers
soft BPs), debugging using AVaRICE/GDB appears to be faster in response
than JTAG is. I don't really have an explanation for this.
It's probably time to write a GDB-taylored custom firmware for the JTAG
ICE... The existing firmware is highly optimized for AVR Studio and thus
quite pessimizes GDB usage on it. Not that I'd claim that AVaRICE itself
were already optimal in every respect though, it could benefit from a lot
more self-intelligence, like caching certain results, or clustering requests
before sending them to the ICE. As it is right now, it's rather a straight
1:1 translation of the GDB remote backend commands into ICE commands.
> A shame, becase Eclipse with OOCD on ARM works just beautifully.
The difference is that JTAG debugging an ARM is well documented, whereas Atmel
considers the JTAG debugging instructions proprietary stuff they don't want to
document. Thus we are bound to the JTAG ICE as mediator between GDB and the
target AVR.
