QNX-App-development-and-deployment: Difference between revisions
No edit summary |
Henri Vikki (talk | contribs) No edit summary |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
[[Category:QNX]] | [[Category:QNX]] | ||
| Line 9: | Line 11: | ||
Once the QNX board has been set up and received a valid IP address, a connection to it can be established using telnet. The username and password are both by default to "root". | Once the QNX board has been set up and received a valid IP address, a connection to it can be established using telnet. The username and password are both by default to "root". | ||
<code>> telnet <qnx-board-ip><code> | <code>> telnet <qnx-board-ip></code> | ||
== Deploying the Qt5 runtime == | == Deploying the Qt5 runtime == | ||
| Line 15: | Line 17: | ||
In order make your application to be executable, the Qt5 libraries, plugins and qml import files have to become accessible from the location you want to run the application from. There are two choices for this: | In order make your application to be executable, the Qt5 libraries, plugins and qml import files have to become accessible from the location you want to run the application from. There are two choices for this: | ||
1. You copy the Qt runtime to a persistent storage on the target board, e.g a folder on the SD card, internal flash or USB stick. | |||
2. The folders with the Qt runtime and/or with binaries of your application on your host machine can also be mounted from the board over NFS. This way is very useful during the daily development process because the files remain on the host PC and can be modified more easily making develop-test cycles very short. | |||
=== Deploying Qt5 to the file system === | === Deploying Qt5 to the file system === | ||
| Line 23: | Line 25: | ||
On the target side (i.e. the QNX board) we only need libraries plugins and qml imports from the Qt5 installation. These three folders ("lib", "plugins", "qml") should be copied to the QNX filesystem using, for example, "scp": | On the target side (i.e. the QNX board) we only need libraries plugins and qml imports from the Qt5 installation. These three folders ("lib", "plugins", "qml") should be copied to the QNX filesystem using, for example, "scp": | ||
< | <code> | ||
> cd <qt-for-qnx-installation-folder> | > cd <qt-for-qnx-installation-folder> | ||
> scp -r lib qml plugins root@my-qnx-board-ip:/path-to-the-destination-folder | > scp -r lib qml plugins root@my-qnx-board-ip:/path-to-the-destination-folder | ||
<code> | </code> | ||
Please note that if you have a debug build the runtime reach a size of 1GB. The above command copies all files from the host which is more than actually needed on target. If space matters, delete files which are not needed. Moreover, "scp" follows symbolic links and so copies Qt libraries multiple times. This can increase the size of the runtime as well. You can use "tar" and copy the files via a ssh pipe: | Please note that if you have a debug build the runtime reach a size of 1GB. The above command copies all files from the host which is more than actually needed on target. If space matters, delete files which are not needed. Moreover, "scp" follows symbolic links and so copies Qt libraries multiple times. This can increase the size of the runtime as well. You can use "tar" and copy the files via a ssh pipe: | ||
< | <code> | ||
cd <qt-for-qnx-installation-folder> | cd <qt-for-qnx-installation-folder> | ||
tar cpf- lib qml plugins | ssh -i ~/.ssh/id_rsa root@my-qnx-board-ip tar xpf- -C /path-to-the-destination-folder | tar cpf- lib qml plugins | ssh -i ~/.ssh/id_rsa root@my-qnx-board-ip tar xpf- -C /path-to-the-destination-folder | ||
<code> | </code> | ||
The location of the destination folder does not matter as long as it is persistent and can be accessed by applications. | The location of the destination folder does not matter as long as it is persistent and can be accessed by applications. | ||
| Line 39: | Line 41: | ||
=== Mounting Qt5 over NFS === | === Mounting Qt5 over NFS === | ||
A very convenient way to work with Qt5 during the development process is to mount the Qt5 installation directory (that is on your host PC) via | A very convenient way to work with Qt5 during the development process is to mount the Qt5 installation directory (that is on your host PC) via [http://en.wikipedia.org/wiki/Network_File_System NFS] on the QNX board. This has the advantage that the files don't have to be copied over to the QNX file system on the target and remain on the development PC, from where they can be edited and changed any time. | ||
==== Setting up NFS ==== | ==== Setting up NFS ==== | ||
| Line 47: | Line 49: | ||
===== Installation on Linux ===== | ===== Installation on Linux ===== | ||
< | <code>> sudo apt-get install nfs-common nfs-kernel-server</code> | ||
Add the folder you want to export over NFS e.g.: | Add the folder you want to export over NFS e.g.: | ||
<code>/home/user/development *(rw,no_root_squash,subtree_check)<code> | <code>/home/user/development *(rw,no_root_squash,subtree_check)</code> | ||
to "/etc/exports". Afterwrads the NFS server has to be restarted. | to "/etc/exports". Afterwrads the NFS server has to be restarted. | ||
< | <code>> /etc/init.d/nfs-kernel-server restart</code> | ||
Note: that this NFS export has as much as no security measures set. If this aspect matters, please change the configuration accordingly. | Note: that this NFS export has as much as no security measures set. If this aspect matters, please change the configuration accordingly. | ||
| Line 63: | Line 65: | ||
On the QNX board you can now mount the folder to "/home/user/development" (<host-ip> is the IP address of your host machine): | On the QNX board you can now mount the folder to "/home/user/development" (<host-ip> is the IP address of your host machine): | ||
<code>> fs-nfs3 <host-ip>:/home/user/development /home/user/development<code> | <code>> fs-nfs3 <host-ip>:/home/user/development /home/user/development</code> | ||
== Application development == | == Application development == | ||
| Line 77: | Line 79: | ||
Before starting a build, make sure to "source" the QNX environment script: | Before starting a build, make sure to "source" the QNX environment script: | ||
< | <code>> source <path-to-the-qnx-sdp>/qnx660-env.sh</code> | ||
Before compiling the application, '''qmake''' (the one from the Qt5 for QNX installation you use, and not one from a Qt build for desktop!) has to be executed against your project file and will produce a "Makefile": | Before compiling the application, '''qmake''' (the one from the Qt5 for QNX installation you use, and not one from a Qt build for desktop!) has to be executed against your project file and will produce a "Makefile": | ||
| Line 87: | Line 89: | ||
The build process can then simply be started with: | The build process can then simply be started with: | ||
<code>> make<code> | <code>> make</code> | ||
=== Executing the application === | === Executing the application === | ||
| Line 93: | Line 95: | ||
Once the application is built it must either be deployed (i.e. copied) to the QNX filesystem (with all asset/media files) or be located in a folder mounted over NFS. The application binary can then be simply executed from a remote shell on the target. There are two preconditions: | Once the application is built it must either be deployed (i.e. copied) to the QNX filesystem (with all asset/media files) or be located in a folder mounted over NFS. The application binary can then be simply executed from a remote shell on the target. There are two preconditions: | ||
* The QNX target board already runs the "Screen Graphics Subsystem" (see | * The QNX target board already runs the "Screen Graphics Subsystem" (see [http://www.qnx.com/developers/docs/660/topic/com.qnx.doc.screen/topic/manual/cscreen_about.html this link] for details) | ||
* Qt runtime environment variables are set as described in the next section | * Qt runtime environment variables are set as described in the next section | ||
| Line 109: | Line 111: | ||
Addtionally, the Screen requires the "QQNX_PHYSICAL_SCREEN_SIZE" environment variable to be set, e.g. | Addtionally, the Screen requires the "QQNX_PHYSICAL_SCREEN_SIZE" environment variable to be set, e.g. | ||
<code> | |||
export QQNX_PHYSICAL_SCREEN_SIZE="150,90" | |||
</code> | </code> | ||
It defines the height and width of the app's display area on the screen in millimeters. Some QNX boot images define set this variable on start-up globally. | It defines the height and width of the app's display area on the screen in millimeters. Some QNX boot images define set this variable on start-up globally. | ||
If you have a build which does not use | If you have a build which does not use [http://en.wikipedia.org/wiki/Fontconfig Fontconfig], you have to point the Qt runtime to the location of the Qt fonts in "<path-to-the-destination-folder>/lib/fonts": | ||
<code> | |||
export QT_QPA_FONTDIR=<path-to-the-destination-folder>/lib/fonts | |||
</code> | </code> | ||
Note that this is probably not needed in most cases. | Note that this is probably not needed in most cases. | ||
| Line 125: | Line 127: | ||
==== Accessing application logs ==== | ==== Accessing application logs ==== | ||
Application logs from "QDebug" go to the | Application logs from "QDebug" go to the [http://www.qnx.com/developers/docs/660/index.jsp?topic=/com.qnx.doc.neutrino.utilities/topic/s/slogger2.html slogger2-framework] by default. This framework provides by far a better performance that text logs on flash file systems, has categorization and some other additional facilities. | ||
In order to retrieve logs you can either launch | In order to retrieve logs you can either launch '''slog2info -w''' on the QNX board or install a [http://doc.qt.io/qt-5/qtglobal.html#qInstallMessageHandler custom qt message handler] that would redirect the logs to the console again. | ||
==== If you feel that Qt Quick animations run too slow… ==== | ==== If you feel that Qt Quick animations run too slow… ==== | ||
Qt5 on QNX uses fixed step animation timing. That means it advances the animations by 16ms (if the display refresh rate is 60Hz) per frame, no matter how long a frame takes to render. While this gives perfect results if your application is running at a frame rate equal to display refresh rate (usually 60Hz), this will lead to slow animations when the frame rate drops is is generally slower on a given hardware. If your target can not maintain a constant frame rate consider setting the "QSG_FIXED_ANIMATION_STEP" environmental variable to "no", or use a custom animation driver. | Qt5 on QNX uses fixed step animation timing. That means it advances the animations by 16ms (if the display refresh rate is 60Hz) per frame, no matter how long a frame takes to render. While this gives perfect results if your application is running at a frame rate equal to display refresh rate (usually 60Hz), this will lead to slow animations when the frame rate drops is is generally slower on a given hardware. If your target can not maintain a constant frame rate consider setting the "QSG_FIXED_ANIMATION_STEP" environmental variable to "no", or use a custom animation driver. | ||
Latest revision as of 11:22, 30 March 2015
Qt application development and deployment on QNX
Application development using QNX and Qt5 is as convenient as on other Qt platforms, yet there are some differences the developer should be aware of. This wiki page will briefly walk you through the steps of setting up the environment and configuring a QNX board in to establish an efficient development process. While this page only focuses on the command line, it is also worthwhile to read if you plan to using the QtCreator for development.
Connecting to a QNX board
Once the QNX board has been set up and received a valid IP address, a connection to it can be established using telnet. The username and password are both by default to "root".
> telnet <qnx-board-ip>
Deploying the Qt5 runtime
In order make your application to be executable, the Qt5 libraries, plugins and qml import files have to become accessible from the location you want to run the application from. There are two choices for this:
1. You copy the Qt runtime to a persistent storage on the target board, e.g a folder on the SD card, internal flash or USB stick.
2. The folders with the Qt runtime and/or with binaries of your application on your host machine can also be mounted from the board over NFS. This way is very useful during the daily development process because the files remain on the host PC and can be modified more easily making develop-test cycles very short.
Deploying Qt5 to the file system
On the target side (i.e. the QNX board) we only need libraries plugins and qml imports from the Qt5 installation. These three folders ("lib", "plugins", "qml") should be copied to the QNX filesystem using, for example, "scp":
> cd <qt-for-qnx-installation-folder>
> scp -r lib qml plugins root@my-qnx-board-ip:/path-to-the-destination-folder
Please note that if you have a debug build the runtime reach a size of 1GB. The above command copies all files from the host which is more than actually needed on target. If space matters, delete files which are not needed. Moreover, "scp" follows symbolic links and so copies Qt libraries multiple times. This can increase the size of the runtime as well. You can use "tar" and copy the files via a ssh pipe:
cd <qt-for-qnx-installation-folder>
tar cpf- lib qml plugins | ssh -i ~/.ssh/id_rsa root@my-qnx-board-ip tar xpf- -C /path-to-the-destination-folder
The location of the destination folder does not matter as long as it is persistent and can be accessed by applications.
Mounting Qt5 over NFS
A very convenient way to work with Qt5 during the development process is to mount the Qt5 installation directory (that is on your host PC) via NFS on the QNX board. This has the advantage that the files don't have to be copied over to the QNX file system on the target and remain on the development PC, from where they can be edited and changed any time.
Setting up NFS
A NFS server has to be installed and running on the host (e.g. the PC your are developing on).
Installation on Linux
> sudo apt-get install nfs-common nfs-kernel-server
Add the folder you want to export over NFS e.g.:
/home/user/development *(rw,no_root_squash,subtree_check)
to "/etc/exports". Afterwrads the NFS server has to be restarted.
> /etc/init.d/nfs-kernel-server restart
Note: that this NFS export has as much as no security measures set. If this aspect matters, please change the configuration accordingly.
Mounting NFS
On the QNX board you can now mount the folder to "/home/user/development" (<host-ip> is the IP address of your host machine):
> fs-nfs3 <host-ip>:/home/user/development /home/user/development
Application development
Developing a Qt5 application with QNX is not much different from using Qt5 on other platforms. Yet there are some things the developer should be aware of.
Setting up a new project
A Qt project typically consists of a project file (.pro), sources and headers. Additionally, there might be QML files, and/or Qt resource (.qrc) and asset (images, sounds, etc) files.
Compilation
Before starting a build, make sure to "source" the QNX environment script:
> source <path-to-the-qnx-sdp>/qnx660-env.sh
Before compiling the application, qmake (the one from the Qt5 for QNX installation you use, and not one from a Qt build for desktop!) has to be executed against your project file and will produce a "Makefile":
> <path-to-the-qt-for-qnx-installation-folder>/bin/qmake my_qt_app.pro
The build process can then simply be started with:
> make
Executing the application
Once the application is built it must either be deployed (i.e. copied) to the QNX filesystem (with all asset/media files) or be located in a folder mounted over NFS. The application binary can then be simply executed from a remote shell on the target. There are two preconditions:
- The QNX target board already runs the "Screen Graphics Subsystem" (see this link for details)
- Qt runtime environment variables are set as described in the next section
Setting up the Qt5 environment on the board
A Qt5 application needs to be able to find the Qt runtime (libraries, plugins and qml imports) on application start-up. Therefore following environment variables must be set on the QNX board:
- "LD_LIBRARY_PATH" should be set to "<path-to-the-destination-folder>/lib"
- "QT_PLUGIN_PATH" defines where the Qt plugins are located. It should be set to "<path-to-the-destination-folder>/plugins"
- "QML2_IMPORT_PATH" defines where the Qt Quick 2 / QML2 plugins are located. It should be set to "<path-to-the-destination-folder>/qml"
- QML_IMPORT_PATH" is required only when using the QtQuick1 compatibility module. It should be set to "<path-to-the-destination-folder>/imports"
The <path-to-the-destination-folder> is the directory we mentioned above. The one where you copied the Qt5 runtime to the target. This folder can also be a folder mounted over NFS as discussed above.
Addtionally, the Screen requires the "QQNX_PHYSICAL_SCREEN_SIZE" environment variable to be set, e.g.
export QQNX_PHYSICAL_SCREEN_SIZE="150,90"
It defines the height and width of the app's display area on the screen in millimeters. Some QNX boot images define set this variable on start-up globally.
If you have a build which does not use Fontconfig, you have to point the Qt runtime to the location of the Qt fonts in "<path-to-the-destination-folder>/lib/fonts":
export QT_QPA_FONTDIR=<path-to-the-destination-folder>/lib/fonts
Note that this is probably not needed in most cases.
Accessing application logs
Application logs from "QDebug" go to the slogger2-framework by default. This framework provides by far a better performance that text logs on flash file systems, has categorization and some other additional facilities.
In order to retrieve logs you can either launch slog2info -w on the QNX board or install a custom qt message handler that would redirect the logs to the console again.
If you feel that Qt Quick animations run too slow…
Qt5 on QNX uses fixed step animation timing. That means it advances the animations by 16ms (if the display refresh rate is 60Hz) per frame, no matter how long a frame takes to render. While this gives perfect results if your application is running at a frame rate equal to display refresh rate (usually 60Hz), this will lead to slow animations when the frame rate drops is is generally slower on a given hardware. If your target can not maintain a constant frame rate consider setting the "QSG_FIXED_ANIMATION_STEP" environmental variable to "no", or use a custom animation driver.