Previous Section

Index

Next Section

Remote Access and Debugging

This topic is a crash course in accessing remote devices on the QNX operating system. For new QNX developers, it is an essential quick start to remote development. The techniques in this section are directly applicable to every day QNX development.

Part 1: Remote Access

To enable almost all of our networking software, io-net networking service must be started. This service is active by default on QNX RTP machines as well as the default installation of the iPAQ Reference Platform. Each networking client or server connects to io-net to efficiently interoperate on local and remote network. Once this connectivity is put into place, you can frequently skip the process of burning or flashing your device. Instead, you can run your applications over your ethernet connection.

Here a brief overview to enable you to use our remote access technologies:

QNet If you are developing with QNX RTP, you may want to use our native networking protocol, QNet. With QNet you can communicate between remote processes without TCP/IP, access remote file systems and directly communicate with hardware on remote devices. It is designed to be a lightweight service for local area networks. QNet is enabled by default of QNX RTP machines as well as on the iPAQ Reference Platform. Once a PCMCIA card is inserted into an iPAQ sleeve, the appropriate TCP/IP, io-net and QNet drivers are active as well a DHCP client, used to resolve your network information. Once started, each QNet device will be mounted under the /net directory. From here, all QNX devices running QNet will be accessible. Please read our complete documentation to understand the nature of QNet. It is perfect for pervasive devices, distributed computing and other shared services. Note: QNet is a low level protocol that has no concept of files or file systems. As such, if your application is expecting that a file system layer will be performing caching for fast seeks and read performance, you will notice reduced performance. Consider using NFS first. Although QNet is active by default, here is how you manually start it: The default iPAQ BSP image uses the network driver: ne2000 Use this command to start the QNet service: io-net -d ne2000 -p qnet If QNet is started but you do not see any device under /net, you may need to manually set your hostname: Let's assume the hostname for our device is: ipaq.qnx.com Use this command to set the hostname: hostname ipaq.qnx.com Mount File system via NFS We support file sharing through Network File system 2 (NFS2). This is a relatively efficient sharing protocol used by most modern operating systems include QNX, Linux and Microsoft Windows. A server may be started, allowing other devices to access the exported directories. To start the NFS server on an QNX RTP machine: Create the file: /etc/exports, add the name of each directory you want to share, one per line. Start the Remote Procedure Call (RPC) server: portmap &. Use this command to start the nfs server: nfsd &. To mount a shared NFS directory: Let's assume the machine which is running the server has the IP: 192.168.1.1 Let's assume the server is exporting the directory: /share Let's assume we want this to appear at: /nfs/share Use this command to start the nfs client using TCP/IP: fs-nfs2 -t 192.188.1.1:/share /nfs/share & Mount Windows File system via CIFS If you are using our Windows development tools, or have a Windows file server which is sharing a drive, you may want to run a Common Internet File system (CIFS) client. This will allow you to connect to most SMB shared connection To mount a shared windows directory: Let's assume the machine has the name: My_Computer Let's assume the machine has the IP: 192.168.1.5 Let's assume the Windows shared drive is called: C_DRIVE Let's assume we want this to appear at: /nfs/share Use this command to start the CIFS client: fs-cifs -v -l //My_Computer:192.168.1.5:/C_DRIVE /nfs/share If you want to provide a login or password, remove the -l and append your Windows user name and password. Remote Display It is extremely easy to run a photon application locally and have it display on a remote machine. The Photon widget library can communicate with a remote Photon server via QNet, QNX's native networking protocol. If you are developing in the QNX Realtime Platform environment, you can instruct your applications to communicate with the Photon server on your iPAQ with the single environment variable: PHOTON. To display a single process on a remote Photon server - only once: Let's assume the Photon application is called: ipaq-guantlet Let's assume you want to send it to a machine running QNet with the domain name: ipaq.qnx.com Use this command to display it remotely: ipaq-guantlet PHOTON=/net/ipaq.qnx.com/dev/photon To have all photon applications display remotely: Let's assume you want to send it to a machine running QNet with the domain name: ipaq.qnx.com Use this command to define your remote Photon server: export PHOTON=/net/ipaq.qnx.com/dev/photon To clear the environment variable: Use this command to have Photon apps dispay locally: export PHOTON= Ditto Display Photon uses custom events for message passing. Photon events move through Photon space to signify drawing, user input or other interprocess communication which relate to geometry. Because of this patented architecture, it is extremely easy to capture the events and relay them to a remote Photon server. To allow users to collaborate simultaneously and to optimize the data which is sent between the client and server Photon servers, we use a relay server. To connect we establish a ditto session. The relay service is started by the inetd network service daemon on both the iPAQ and the QNX Realtime Platform. Note: If you are using the Windows development environment, you may want to consider purchasing the Photon client for Windows, Phindows. Please contact our sales department for the latest price and availability for immediate shipping. The iPAQ Board Support Kit includes an iPAQ interface client for Photon Ditto. This will allow you to see nice presentation of the iPAQ hardware, around the ditto region. To start a basic ditto of a remote Photon environment: Let's assume that inetd is running on the remote machine. Let's assume you're connecting to the default Photon server: /dev/photon Lets assume the machine has the IP: 192.168.1.4 Use this command connect to the relay service: phditto -w240 -h320 -n /dev/photon 192.168.1.4 To start an iPAQ ditto of a remote iPAQ session: Let's assume that inetd is running on the iPAQ. Let's assume you're connecting to the default Photon server: /dev/photon Lets assume the iPAQ has the domain name: ipaq.qnx.com Use this command connect to the relay service: ipaq-ditto -n /dev/photon ipaq.qnx.com To start a phindows session from a Windows development environment: Launch the Phindows application and supply the IP address of the iPAQ. Click Apply and a you should have access to your iPAQ. By default, Phindows connects to the exisitng Photon session on the remote device.     Access via telnet Telnet is a remote access service common to practically all UNIX/QNX environments. It allows access to a machine via a login and password. Once you've logged in, you'll be able to control the device as if you have a regular local terminal. The default image from the iPAQ Software Reference Platform automatically starts the telnet daemon via the inted network service. By default there is only a single account, root, with no password.  Feel free to use the passwd utility on the iPaq to change the password. To telnet into a device running inetd: Let's assume the device has the domain name: ipaq.qnx.com Use this command to connect to the device: telnet ipaq.qnx.com Access via Slinger (HTTP) The QNX RTP and the iPAQ Software Reference Platform contain slinger, an extremely small, embeddable web server. Slinger allows you to easily add embedded HTTP services to your device. It supports Server Side Includes (SSI) and Common Gateway Interface (CGI) scripts to build dynamic content. Overall, this makes it very useful for remote monitoring and control of embedded devices. By default, your iPAQ includes default HTML documents which are accessible with a web browser. In the default iPAQ image, sliger is instructed to load its data from /system/data/html/www/. Slinger can run on any TCP port you specify. If you are not logged into the root account, you must run slinger on a port above 1024. Port 8080 is commonly used for non-root HTTP services. To simulate the iPAQ slinger configuration in the QNX RTP environment: Let's assume the html files are in the directory: /armle/ipaq/system/data/html/www Let's assume the starting document has the name: index.html Let's assume we want server to answer on port: 8080 Use this command to set the root directory: export HTTPD_ROOT_DIR=/armle/ipaq/system/data/html/www Use this command to set the root document: export HTTPD_ROOT_DOC=index.html Use this command to start the web server: slinger -p8080 & To connect to a local web server running on a specific port: Let's assume we are connecting locally using the default name: localhost Let's assume the web server is listening on port: 8080 Use this command to start the voyager web client: voyager -u http://localhost:8080/ To connect to the web server running on a default iPAQ installation: Let's assume the ipaq has the name: ipaq.qnx.com Use this command to start the voyager web client: voyager -u http://ipaq.qnx.com/ The QNX Utilities Reference has excellent documentation on the slinger web server. It goes into great detail about the SSI and CGI support. It can be an extremely powerful tool for anything from statistics to remote administration. Feel free to experiment and take advantage of this embeddable web server.

Part 2: Remote Debugging

The pdebug program runs on your target device and attaches itself to either a character device (like a serial port) or to a tcp port. Once pdebug is running on the target device, gdb can to told to connect to the pdebug service. Once connected, you are able to attach to an existing process or start a new process to debug. At that point, you may continue debugging as if you were debugging a local process.

Important: You should have installed the C/C++ toolset for the arm processor. This installs a custom version of the GNU Debugger for the Strong Arm processor. With this, you will be able to connect to a pdebug service and debug programs compiled for an iPAQ.

To start pdebug, on your remote device, using TCP:

To debug a process running on an armle device, such as an iPAQ, using TCP:

To start pdebug, on your remote device, using serial:

To debug a process running on an armle device, such as an iPAQ, using serial:

Finally, you can also use gdb and pdebug to upload new binaries to your remote device. This allows you to install and test your programs without having to leave gdb.

To upload and debug a new program on a remote device:

This concludes your introduction to remote debugging and cross platform development. Please consult the Reference Documentation on gdb, pdebug and Compiling and Debugging in the QNX Help Viewer or on http://qdn.qnx.com/ for more in depth information on these tools.
 

Previous Section

Index

Next Section