Debugging Applications
Debugging applications
This page describes some of the techniques commonly used to debug and modify software that runs on AsteroidOS. It assumes that the development host (that is, the machine on which you are writing and compiling your code) is running Linux as the operating system, since it is much simpler to write Linux code on Linux machines and makes the descriptions much shorter and easier. With that said, some Windows users have reported success in using [WSL].
Build methods
If you have followed Creating an Asteroid app you will already have some idea of how to create an application that runs on AsteroidOS. There are three ways that developers create applications:
- Build from the command line
- Build with QtCreator
- Build with
devtool
The first two are described on the Creating an Asteroid app page. The use of devtool
is described on OpenEmbedded.
Method | Advantages | Drawbacks |
---|---|---|
command line | simple, fast, easy to set up | doesn't always create .ipk file
|
QtCreator | good for GUI development | difficult to set up, doesn't create .ipk file
|
devtool |
creates .ipk file |
complex to set up, slow |
Having a properly constructed .ipk
file not only allows simplified installation on the watch, but also includes dependencies (other libraries on which the code might depend). All of the .ipk
files on our nightly builds are created using the OpenEmbedded tool bitbake
.
The command-line version build of asteroid-helloworld
creates a simple installable .ipk
file by adding build instructions for that directly to the CMakeLists.txt file. This works as a temporary fix, but is generally not done for AsteroidOS projects because it would interfere with the way bitbake
builds and because it does not automatically include dependencies, as mentioned above.
Debug methods
Just as there are multiple ways to build software for AsteroidOS, there are also many techniques that can be useful to debug them and test them. A few are described below.
Native build
One simple method is to write the code so that it runs on the host machine and debug the application there. Then once it's working as you intend, you can compile it for the watch and make sure it also works as expected there.
However, most non-trivial programs for AsteroidOS will use specific watch features that are not generally available on host machines. One way to accommodate that is to write stub code for the watch-specific features and then when everything seems to be working with that, change to use the real code and compile for the watch.
Develop QML separately
The graphical user interface (GUI) code for AsteroidOS watch is generally written with [QML]. This code can be prototyped using the [qml] tool on the desktop. If it requires interaction with watch-specific things, as with the native build approach, these can be "faked" with stub code.
Another approach is to use asteroid-qmltester on the watch and copy the QML file to the watch for testing.
If you use [vim] one very handy and fast technique is to edit the QML file on the watch, but from your desktop, connected to the watch via ssh
. For example, a command might be something like this:
vim scp://ceres@localhost:2222/Prototype.qml
That connects as the user ceres
to the emulator which is running on port 2222 on the localhost
. With a real watch, the command is similar:
vim scp://ceres@192.168.2.15/Prototype.qml
Then you can use asteroid-qmltester
on the emulator or watch to see the result.
Other techniques
Other techniques could and should be described here such as:
- using
gdbserver
on the watch - profiling QML code on the watch