-
Notifications
You must be signed in to change notification settings - Fork 23
Remote Debugging
As we want to develop on embedded systems, there is often no IDE available on the target. So it would be nice to compile all code in an IDE on another more powerful machine and do only debugging on the target.
What do we need therefore?
- Cross compile toolchain on the development pc.
- IDE with debugging capabilities.
- gdbserver running on the target.
- Some clever makefile to automate things.
Alternative text from Wolfgang Rosner, still to be merged.
There are some different basic ways to develop for a remote target:
- use terminal connection and command line tools
- use X11 forwarding to run IDE on remote device, but displaying on your workstation
- Use cross compile setup as outlined above.
- attach a keyboard, mouse and HDMI screen to your (no longer remote) device (developper-butt-networking)
There are some basic situations which might favour different setups:
- Participate in depth in complex development
- Try to setup, test, debug and maybe apply minor changes of existing projects
- Emergency repair, maybe out in the field
- quick and dirty small project development from scratch / from template
Maybe you forgot already, but the raspberry ships with USB and HDMI connectors and a full fledged GUI preinstalled on the rasPi wheezy distribution. So, you might even connect keyboard, mouse and your home TV set to login locally. People coming fromthe WIN-DOSe world may find this naturally, linux/network people will find this really odd. But maybe it is the only mean on some situations out there.
The whole linux build can easily done with gcc, vi, gdb, make and tools like that from a silly command line. Usually, you will connect via network using ssh. You can arrange multiple ssh connected terminals on your workstation window to have parallel things done on your target device. Remember: linux is really multitasking, even on a raspberry.
Having terminal windows open for editing with vi (no reason for only one of them), executing, watching file content, debugging, building ... gives you quite the power of an IDE at much lower system load. However, all your info you have to collect from manpages, internet pages and similar sources. There are no such nice tools like object tree browsers, that help you to complete half known commands. There is however syntax highlighting available in proper configured setups.
The smaller the problems, the leaner the systems available, and the more experienced you are in programming, building and adminsitrating, the more you will prefer the command line access. There are ssh clients available for android mobiles, so this might be the best way for a quick fix out there in the fields. Then it may be wise if you have learned to use command line tools in the warm programmers office.
No question, this is the professional way to develop for embedded gadgets. Your workstation will have at least 10 times the computing power, much more diskspace and memory than your raspberry. And maybe you want to feed more than one of the tiny thingies, then your installation setups on your workstation is still the same.
As it appears, rasPi developpers themselves work with eclipse. So if you go for cross plattform development, take a look at this one first.
The good news is, that neither eclipse nor the cross compiler tool chain seem to rely on specific system requirements. Even on my old, beyond end-of-live SuSE 11.0, both install and run without trouble.
Following this https://github.com/tyler123durden/rtklib/wiki/Getting-Started guideline, you will easily have an Eclipse installed on your workstation. But when you are not a C-geek, you may be shocked on the sheer complexity of this toolbox.
Fortunately, for people like you and me, there is an set of tutorials which perfectly fits our needs to get a first idea of crosscompiling and remote debugging for rasPi on linux x86-*** Workstations:
http://hertaville.com/2012/09/28/development-environment-raspberry-pi-cross-compiler/
http://hertaville.com/2013/01/11/remote-debugging/
When googling for tutorials, don't be trapped into armel-based architectures, if you have a current rasPi wheezy installed. We are on armhf, not armel, as the link above explains in more detail. You may find out your system details by typing:
pi@raspberrypi ~ $ uname -a
Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux
pi@raspberrypi ~ $ cat /proc/version
Linux version 3.2.27+ (dc4@dc4-arm-01) (gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro- 1.13.1+bzr2458 - Linaro GCC 2012.08) ) #250 PREEMPT Thu Oct 18 19:03:02 BST 2012
Working through the remote debug tutorial, I did not manage to run the Automatic example. It managed to copy the executable to the device, but then threw a file system error. However, the manual setup (starting the gdbserver with your executable from a seperate console) works. I left a comment on this issue at the tutorial page. If fixed, feel free to update this wiki page.
Of course, you could also do cross compiling using the toolchain on the terminal of your workstation. This might be relevant for highly automated tasks like package building, kernel configuration or setup routines. So, when you start marketing your gadget in lots > some dozens, think again.
Whenever you decide for cross compiling, keep in mind that you have to keep your libraries and header files in sync. This may be an advantage or disadvantage, if you work with multiple devices on the same workstation. rsync might be your friend then, but rtfm.
Since we are on linux, not on highly marketing cost loaded stuff, there is little reason not to run your beloved graphical tools on the raspi - yust because you do not sit in front of it. You don't need expensive things like terminal servers or citrix. X11 forwarding is the trick, and it comes as inherent capability of any X11 setup. Not only in your client, but also in your raspberry.
Setup is at simple as removing the comment # from one line in your /etc/ssh/ssh_config from the line
ForwardX11 yes in your workstation. The sshd_config on the X-client side (the raspberry) must match.
Don't blame me if this is not sufficient. I configured mine many years ago (still on SuSE 11.0). Connecting to pristine raspberry, X-forwarding worked out of the box. So, obviously it is enabled by default.
Basically, your workstation runs as an X-Server, to which any X-aware application of your X-Client, the raspberry, can connect. The X-Server provides features such as keyboard, mouse, screen, and of course a user sitting in front of it to the X-client. They communicate over the ssl channel you establish once you log in.
To test X-forwarding, yust ssh into your raspberry and call any tiny X aware application, like xterm. It is not installed by default, so do an sudo apt-get install xterm. Log into your raspberry using ssh and simply type xterm. Now an additional console window will pop up on your workstation screen, which runs not in your workstation, but in the raspberry. With xterm & you may send it in the background and have your launching console available again.
If it does not work, try
pi@raspberrypi ~ $ echo $DISPLAY
localhost:10.0
and ask google for help.
Raspberry wheezy is a fully fledged debian. Type apt-cache search eclipse and be surprised.
So you might simply type sudo apt-get install eclipse-cdt.
When I did this, it announced to install > 400 MB, which exceeded my free SD-card space, so I pressed ^C.
However, looking into
pi@raspberrypi ~ $ cat /proc/cpuinfo
Processor : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 697.95
Features : swp half thumb fastmult vfp edsp java tls
there is a feature "java" listed in the processor Features. Does this mean, the ARM in the Raspberry can natively execute java byte code? If so, the performance of java based eclipse might even be better on the Raspberry than on your workstation. If you have tried, please let us know and update this page.
Searching for a lightweighted alternative to eclipse to run natively on raspberry, I came across geany.
http://www.geany.org/Documentation/Screenshots looks promising.
Check with dpkg -l | grep geany what you have and with apt-cache search geany what you might want to have. Install what you desire. I had a look on:
geany - fast and lightweight IDE
geany-common - fast and lightweight IDE -- common files
geany-plugin-debugger - debugger plugin for Geany
geany-plugin-gdb - GDB plugin for Geany
geany-plugin-vc - VCS plugin for Geany
geany-plugins-common - set of plugins for Geany (translations)
There are some tutorials around, but the ones I found were addressed to really kiddies. So I tried to copy the "HelloWorld" example from the Eclipse tutorial. It took me about 30 min to build it.
To activate plugins, select "Tools/Plugin Manager" from the menue. There you will find tickboxes for any plugins you have installed, to activate them. Have a look on all menues, tabs, subwindows etc after activating a plugin to find out added functionality.
There are two different debugger plugins, which appear exchangeable. I think the geany-plugin-debugger is the better one. Its more stable than the geany-plugin-gdb (which does not mean that it is stable, however), and has a more intuitive GUI for setting breakpoints and watching variables, while the pure gdb variant is more like a bare wrapper around console gdb. And I think it can debug other language, too, not only C by using gdb.
To debug with geany, you must build your executable with the -ggdb flag enabled.
In the Hello-World-Example, I used the menue [ Build / Options / C++ commands ] and changed the setting to
g++ -Wall -ggdb -c "%f".
Activate the Debugger Plugin and find a new "Debug" tab in the bottom window with the compiler output.
Have fun, or google for addional help.
The VCS plugin promises integration to subversion systems such as git. See http://plugins.geany.org/geanyvc.html I expected the wohle workflow of forking, cloning, committing pulling etc being available in the GUI. However I was disappointed on that. You still have to start with a manual git clone. You can then open a file in the cloned tree. Then you will find some options available in the Tools/VC menue. I haven't worked yet with git workflow, so I can't tell much on the usability. This is your chance to contribute.
Comparing the 3 different debug approaches:
- remote debug with eclipse on workstation
- IDE debug with geany on device
- commandline debug with bare gdb on device
I would prefer the eclipse way, if you develop in eclipse anyway. Even if automatic deployment does not work, the manual path is simple, quick and straightforward. The commandline gdb might be the choice if you are experienced with it or if out there in the field you only have a limited terminal, such as an android mobile. For hands-on quick debug approch of software not developped or heavily adopted by yourself, I recommend to give the geany setup your first try.