Decent debugger for linux on embedded devices

I have been spoilt using MS Visual Studio for the last few years. Now
I am back to using gdb and ftp'ing to the target. Tell me there is a
better way. Ie, compile, deploy and debug (think IDE). Target is
currently AVR AP7. Used ddd today for debugging on recommendation from
someone but I think I would rather stab myself in the eye with a
pencil. Can anyone recommend a better tool to save me from wasting a
week trying everything out?

The Real Andy wrote:
> I have been spoilt using MS Visual Studio for the last few years. Now
> I am back to using gdb and ftp'ing to the target. Tell me there is a
> better way. Ie, compile, deploy and debug (think IDE). Target is
> currently AVR AP7. Used ddd today for debugging on recommendation from
> someone but I think I would rather stab myself in the eye with a
> pencil. Can anyone recommend a better tool to save me from wasting a
> week trying everything out?

Have you tried AVR32 Studio?  It's the obvious choice for AVR32 
development.  It's Eclipse based, which you may consider a good thing or 
a bad thing.  I haven't used it much (I *like* command-line gdb...) 
myself, but it seemed ok.

There are also other front-ends to gdb if you want to play around and 
set things up yourself or if Atmel's choice of Eclipse doesn't appeal. 
I've used gvd (<https://libre.adacore.com/gvd/>) with gdb for a number 
of embedded systems of different sizes.  These days gvd is integrated 
into an IDE called gps (GNAT programming studio - it works for C and C++ 
as well).  You can also build gdb itself with a windows interface.  Then 
there are other cross-platform IDEs such as JEdit and CodeBlocks, and 
Linux tools such as KDevelope.  And of course there is ddd, which is 
good for some sorts of data visualisation, but not ideal for embedded 
development and not exactly what one would call "modern".  There's 
plenty to choose from when you have gdb at the backend, each with 
advantages and disadvantages, but AVR32 Studio is probably the one to 
try first.

One point about use ftp - if you are running embedded Linux, it's not 
the only way to get your code across.  You can have a shared directory 
on your PC (samba or nfs) and mount it locally on the AVR board.  That 
way you don't have to copy anything across - the embedded Linux system 
accesses it directly over the network.

On Thu, 30 Apr 2009 13:23:38 +0200, David Brown
<david@westcontrol.removethisbit.com> wrote:

>The Real Andy wrote:
>> I have been spoilt using MS Visual Studio for the last few years. Now
>> I am back to using gdb and ftp'ing to the target. Tell me there is a
>> better way. Ie, compile, deploy and debug (think IDE). Target is
>> currently AVR AP7. Used ddd today for debugging on recommendation from
>> someone but I think I would rather stab myself in the eye with a
>> pencil. Can anyone recommend a better tool to save me from wasting a
>> week trying everything out?
>
>Have you tried AVR32 Studio?  It's the obvious choice for AVR32 
>development.  It's Eclipse based, which you may consider a good thing or 
>a bad thing.  I haven't used it much (I *like* command-line gdb...) 
>myself, but it seemed ok.

I have not tried AVR32 studio. I thought it was geared up for stand
alone development rather than use with an OS. Can you debug over
ethernet or do I need JTAG?

>
>There are also other front-ends to gdb if you want to play around and 
>set things up yourself or if Atmel's choice of Eclipse doesn't appeal. 
>I've used gvd (<https://libre.adacore.com/gvd/>) with gdb for a number 
>of embedded systems of different sizes.  These days gvd is integrated 
>into an IDE called gps (GNAT programming studio - it works for C and C++ 
>as well).  You can also build gdb itself with a windows interface.  Then 
>there are other cross-platform IDEs such as JEdit and CodeBlocks, and 
>Linux tools such as KDevelope.  And of course there is ddd, which is 
>good for some sorts of data visualisation, but not ideal for embedded 
>development and not exactly what one would call "modern".  There's 
>plenty to choose from when you have gdb at the backend, each with 
>advantages and disadvantages, but AVR32 Studio is probably the one to 
>try first.

That gives me a good start. Will give AVR Studio a spin tomorrow. OVer
the last 4 weeks I have managed to get the app to a point where it is
nearly ready to go to test, just one last bug that I cant find without
a debugger. I am keen to take a look at gvd and gps to.

>One point about use ftp - if you are running embedded Linux, it's not 
>the only way to get your code across.  You can have a shared directory 
>on your PC (samba or nfs) and mount it locally on the AVR board.  That 
>way you don't have to copy anything across - the embedded Linux system 
>accesses it directly over the network.

I was using NFS and TFTP when I was getting the kernel running on the
board. Worked a treat. FTP is not really an issue, would be nice just
to have all that stuff rolled into one neat package.

Thanks.

The Real Andy wrote:
> On Thu, 30 Apr 2009 13:23:38 +0200, David Brown
> <david@westcontrol.removethisbit.com> wrote:
> 
>> The Real Andy wrote:
>>> I have been spoilt using MS Visual Studio for the last few years. Now
>>> I am back to using gdb and ftp'ing to the target. Tell me there is a
>>> better way. Ie, compile, deploy and debug (think IDE). Target is
>>> currently AVR AP7. Used ddd today for debugging on recommendation from
>>> someone but I think I would rather stab myself in the eye with a
>>> pencil. Can anyone recommend a better tool to save me from wasting a
>>> week trying everything out?
>> Have you tried AVR32 Studio?  It's the obvious choice for AVR32 
>> development.  It's Eclipse based, which you may consider a good thing or 
>> a bad thing.  I haven't used it much (I *like* command-line gdb...) 
>> myself, but it seemed ok.
> 
> I have not tried AVR32 studio. I thought it was geared up for stand
> alone development rather than use with an OS. Can you debug over
> ethernet or do I need JTAG?
> 

I believe you can do debugging over Ethernet with it, but I didn't 
really do more with it than a "getting started" tutorial, and 
downloading a newer version of uboot to an STK1000 card - both of which 
were over JTAG.  You can certainly use the C/C++ support in Eclipse for 
debugging with any gdb - but I can't say for sure if remote gdb over 
Ethernet is built into the various wizards and plugins of AVR 32 Studio.

>> There are also other front-ends to gdb if you want to play around and 
>> set things up yourself or if Atmel's choice of Eclipse doesn't appeal. 
>> I've used gvd (<https://libre.adacore.com/gvd/>) with gdb for a number 
>> of embedded systems of different sizes.  These days gvd is integrated 
>> into an IDE called gps (GNAT programming studio - it works for C and C++ 
>> as well).  You can also build gdb itself with a windows interface.  Then 
>> there are other cross-platform IDEs such as JEdit and CodeBlocks, and 
>> Linux tools such as KDevelope.  And of course there is ddd, which is 
>> good for some sorts of data visualisation, but not ideal for embedded 
>> development and not exactly what one would call "modern".  There's 
>> plenty to choose from when you have gdb at the backend, each with 
>> advantages and disadvantages, but AVR32 Studio is probably the one to 
>> try first.
> 
> That gives me a good start. Will give AVR Studio a spin tomorrow. OVer
> the last 4 weeks I have managed to get the app to a point where it is
> nearly ready to go to test, just one last bug that I cant find without
> a debugger. I am keen to take a look at gvd and gps to.
> 
>> One point about use ftp - if you are running embedded Linux, it's not 
>> the only way to get your code across.  You can have a shared directory 
>> on your PC (samba or nfs) and mount it locally on the AVR board.  That 
>> way you don't have to copy anything across - the embedded Linux system 
>> accesses it directly over the network.
> 
> I was using NFS and TFTP when I was getting the kernel running on the
> board. Worked a treat. FTP is not really an issue, would be nice just
> to have all that stuff rolled into one neat package.
> 
> Thanks.

I've only done some evaluation on the AVR32 as yet, not real application 
development, but TFTP for loading the kernel and NFS for the root mount 
is *really* nice - there's no downloading stage.  I also used nbd for a 
network block device swap file - slow, but a lot more flexible and 
reliable than trying to add more SDRAM to the STK 1000 with a soldering 
iron!  And it let me run Doom on the little LCD display...

All the servers and development tools ran happily in a VirtualBox Ubuntu 
machine within my main PC, include AVR 32 Studio and USB to the JTAG ICE.

In addition to the other poster's ideas, look into remote debugging
with gdb.  You run a small program on the target (gdbserver for
example) and run gdb on your development machine.  Then, look into
insight - a Tcl/Tk GUI for gdb that's part of the gdb source
repository (subdir gdbtk).

Now wrap all those commands up in a Makefile - "make debug" does it
all, from compile through popping up gdb.

DJ Delorie wrote:
> In addition to the other poster's ideas, look into remote debugging
> with gdb.  You run a small program on the target (gdbserver for
> example) and run gdb on your development machine.  Then, look into
> insight - a Tcl/Tk GUI for gdb that's part of the gdb source
> repository (subdir gdbtk).
> 
> Now wrap all those commands up in a Makefile - "make debug" does it
> all, from compile through popping up gdb.

Insight's plain, but nice.  Not many bells or whistles, a few things 
that could be done better -- but it works for me.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

On Apr 30, 5:16=A0am, The Real Andy <thereala...@nospam.com> wrote:
> I have been spoilt using MS Visual Studio for the last few years. Now
> I am back to using gdb and ftp'ing to the target. Tell me there is a
> better way. Ie, compile, deploy and debug (think IDE). Target is
> currently AVR AP7.

I'm using code::blocks as an IDE and spent a very long weekend hacking
session at home figuring out how to set up scripts and a few helper
programs to spawn an xterm running a script which ftp's the executable
over and runs it under gdbserver, so I can see console output from the
embedded system in that window.   It was a real pain to set up, and
I'm not even sure anymore how I did it, but it's been working fairly
well.   Actually made it go under both linux and windows/cygwin/Xming.

(Part of what was really hairy was not being able to get the right
options to gdb - I finally wrote a program that pretends to be gdb in
that toolchain, takes the given options and mangles them appropriately
then forks off my xterm with remote gdbserver and my local gdb)

Another nice thing is that I've got the target selection option in
code::blocks and appropriate toolchains and ifdef's in the code so
that I can build my firmware either to run on the embeded device, or
to do a simulated run on a linux or windows machine, in which case a
window pops up with a picture of the embedded device's front panel
with a simulated display and keyboard... some things are better to
debug on real hardware, sometimes faster in the simulator.

I then added some things to the tools menu - run git on my source
tree, launch the (makefile-based) build process for a flashable
firmware image, etc...