Tuesday, October 10, 2006
Import existing project
Setting up a TinKer project for Kdevelop is pretty stright-forward, and the debug integration is both fast and robust. However, you are probably limited to hosts that run either Linux or any similar OS. If you intend to use Windows as your host and need a set-up for Windose (and if you're not willing to go through the mess of setting up KDE for Cygwin), I'd recomend reading the Eclipse guide instead: http://tinker-eclipse.blogspot.com/
The easiest way to start off with a TinKer based project with KDE is by first having built and installed both kernel and your application from command line.
When you've done that, start up Kdevelop and select "Project->Import existing project" from the menu.
Fill in the options as shown by the above example.
Note: the project must be "Automake-based" (this enables you to choose cross develop tools).
Monday, October 09, 2006
Configure options
Sunday, October 08, 2006
Run options
Here's where it makes sense to have built the application once first. You're supposed to select the binary to debug, but without your application built allready, it's not very easy to find it ;)
Besides KDE seems to be a bit buggy here, so even if you know the name of the binary at before-hand, you still have to restart Kdevelop for this setting to take. Better build from command-line first...
Besides KDE seems to be a bit buggy here, so even if you know the name of the binary at before-hand, you still have to restart Kdevelop for this setting to take. Better build from command-line first...
Saturday, October 07, 2006
Debugger
If you want to take advantage of the projects work-arounds to be able to debug applications in ROM/Flash, fill in the debugging entries as above.
Do not select your cross debugger directy, use the wrapper script as shown above.
NOTE: If you use a GDB simulator you can still use this guide. Just replace the "Rund GDB script" with bin/gdb_sim.cfg instead of bin/gdb3.cfg.
Do not select your cross debugger directy, use the wrapper script as shown above.
NOTE: If you use a GDB simulator you can still use this guide. Just replace the "Rund GDB script" with bin/gdb_sim.cfg instead of bin/gdb3.cfg.
Monday, October 02, 2006
Debug session
It doesnt make much sense to use Kdevelop without a working debugger. So before you do anything else, try debugging the application you just imported.
You should get the debug view up. Don't run yet!
First try set and unset a breakpoint some where. If it toggles AND if the color where set is red, then the integration should be OK.
Depending on the the underlaying GDB, stopping/interrupting a running program might not work. You might want to set anothe breakpoint somewhere in youre application first (see next part).
Note: Make sure the application is downloaded to the target and that any GDB backend stuff is set up and in order first. Try using the projects build supports for downloading: ' make flashit'
You should get the debug view up. Don't run yet!
First try set and unset a breakpoint some where. If it toggles AND if the color where set is red, then the integration should be OK.
Depending on the the underlaying GDB, stopping/interrupting a running program might not work. You might want to set anothe breakpoint somewhere in youre application first (see next part).
Note: Make sure the application is downloaded to the target and that any GDB backend stuff is set up and in order first. Try using the projects build supports for downloading: ' make flashit'
Sunday, October 01, 2006
Set breakpoint and "ruuun Forrest, ruuun"
Sunday, August 06, 2006
Some hints and tweeks
Kdevelop is not 100% bugfree (as of todays writing).
One annoying thing is that when you have build errors, the build just keeps going. Yet if you inspect the "Project options -> Make options" it says that the build should stop on first build.
To make this work, you have to untoggle that setting first., then toggle it again.
Subscribe to:
Posts (Atom)