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


Select "Project->Project options" from the menu and start filling in the options as in the following examples.

Note that the above picture shows where you define which cross-develop tool-chain to use.

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...

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.

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'

Sunday, October 01, 2006

Set breakpoint and "ruuun Forrest, ruuun"

Now run your application. In the example shown above, we've set a break-point i a thread. Notice how the threads local data is inspecatbla just as if it were any normal single threaded program.

If you've come this far, CONGRATS!

Now "knock yourself out" with hours of joy with your own applications ;)

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.