| Access Server: User's and Developer's Guide | ||
|---|---|---|
| <<< Previous | Next >>> | |
This manual describes how to create and use applications by using Access Server's Software Development Environment. The relationships between the applications in the Access Server Software Platform are shown in Figure 6-1.
Note: The Software Development Environment can only be installed on a Personal Computer (PC) running the Linux operating system.
The following hardware and software are required to run the Access Server Development Environment:
A PC with:
CD-ROM drive
The Linux operating system (the SDK has been tested with RedHat Enterprise Linux 3 and above, Fedora Core 2 and above; Suse and Ubuntu are reported to work too)
make and gawk must be installed
Devel libraries (especially zlib-devel, e2fsprogs-devel and ncurses-devel) must be installed
modutils-2.4.26 or newer must be installed
300MB of available hard disk space
An Ethernet connection to a Local Area Network (also connected to Access Server) is highly recommended.
Mount the Access Server SDK CD-ROM or ISO image, change the current working directory to where it is mounted, and run the install script. If the user running install does not have privileges to create the directory for the toolchain, normally /usr/local/arm, the install script prompts for root's password.
Example (user input is printed like this):
$ mount /dev/cdrom /mnt/cdrom
$ (or mount -o loop /path/to/sdk2.iso /mnt/cdrom)
$ cd /mnt/cdrom
$ sh install
|
During the installation, the system will prompt you with some questions (described below) regarding the components to install and the paths to install them to. If you are not familiar with Linux, just press enter to these questions to accept the default values. The default values are suitable for most users and systems.
Access Server toolchain directory (default: /usr/local/arm)
This is the path where you want the Access Server Software Development tools (arm-linux-gcc, etc.) to be installed.
Note: If you change this value, the Access Server tools and libc must be recompiled. The recompilation process is complicated and lengthy, and it can also fail, depending on your system. Recompilation is automatically done by the install script, if necessary.
Development directory (default: [home_of_current_user]/asdk)
This is the path where you want the Access Server Software Development Environment to be installed.
Development directory owner (default: [current_user])
(Asked only if run as root.) This is the development directory owner's username.
Note: If this is not the username of the developer for whom the Software Development Environment is being installed, the user will not have rights to use the development files and therefore can not develop any Access Server software.
Install toolchain sources (default: no - unless the tools directory was changed)
This value indicates whether the toolchain sources will be installed. The sources are only required if the Access Server tools directory was changed from the default target location in step 1.
Compile image after installation (default: yes)
If set to yes, the install script will compile the Access Server filesystem image to test that the installation was successful and that the Development Environment is working correctly.
The fastest way to start developing Access Server applications is to study, change, and recompile the example files in the asdk/examples directory.
To demonstrate the software development features of Access Server, the Access Server Software Development Environment comes with several example applications.
The compiled example files are located in WPK packets on the Access Server SDK tree in subdirectories of directory asdk/examples.
The examples can be manually uploaded and installed on Access Server by sending them to the /tmp/obex directory. The wpkgd server automatically installs them. Uploading can be done over Bluetooth, SCP, SFTP or WWW Setup → Advanced → Upload a software update (see Figure 2-14).
The examples, with their usage and purpose, are described in Table 6-1.
Table 6-1. Examples, Their Usage and Purpose
| Example | Usage | Purpose |
|---|---|---|
| helloworld | /usr/bin/helloworld | The "Hello, world!" application. |
| serial | /usr/bin/serial /dev/ttyAT1 | "Hello, world!" to the serial port. Notice that /dev/ttyAT1 must be free (no WRAP SMS Gateway or Bluetooth Serial Port Profile is using it). |
| forkserver | SET BLUETOOTH LISTEN 11 /usr/bin/forkserver | This is the simplest Bluetooth RFCOMM server example. Use, for example, btserver as a client to test this example. This example waits for a full line from the client, echoes is back and then exits. |
| btlogger | SET BLUETOOTH LISTEN 11 /usr/bin/btlogger /tmp/logfile | This is a simple Bluetooth RFCOMM server example, which logs lines received from the connected client, and answers with "ACK". Use, for example, btserver as a client to test this example. |
| btserver | /usr/bin/btserver - for server mode (if no forkserver is running), /usr/bin/btserver <bdaddr of btserver in server mode or forkserver> 11 for client mode | This is an advanced iWRAP client example, which can run both as an RFCOMM server, when it works as forkserver, or as a client, when it sends "YooHoo" to remote server, waits, displays the response, and quits). |
| ledtest | /usr/bin/ledtest | I/O: LED example. |
| m2n | echo testmessage | /usr/bin/m2n | This is a Machine-2-Network (M2N) example. System Logger (syslogd) configuration is needed for actual remote connection. Without it, the example simulates it locally. |
| www | Browse to http://wrap-ip-address/example.html | Demonstration of the web server capabilities. |
| makesms | Browse to http://wrap-ip-address/send.html. Notice that this example assumes that WRAP SMS Gateway is up and running (see Section 3.5.3). | This example demonstrates WRAP SMS Gateway by sending SMS messages with it. |
| setup-helloworld | This example demonstrates how to add a new helloworld submenu to the WWW Setup, with two menu items that change the variables in /etc/sysconfig/helloworld file. |
To start a new project, you must create a new subdirectory in your Development Environment's directory (asdk/) and add your application source files and Makefile to that directory.
A project skeleton can be automatically created by using the Access Server Project AppWizard. Just give the make appwiz APP=dir/to/newapp command in the Development Environment's top level directory (asdk/). A "hello world" example ANSI C project is then created.
To use C++ compiler, replace $(do_link) with $(do_link_cc) in Makefile.
The details of the compile process and variables you may need to modify before compiling your application, such as CFLAGS, LDFLAGS and CXXFLAGS, can be seen in file asdk/Rules.mak.
Now you have a new project waiting for coding. To compile the project, run make in the asdk/dir/to/newapp directory.
The build system also creates the installation packet (hello-timestamp.wpk), which can be transferred to the /tmp/obex directory of Access Server from where it is installed automatically.
The Access Server Development Environment uses the ARM port of the GNU bintools and compilers to build applications. If you are not familiar with Linux development, use the method explained in the previous section instead of writing your own makefiles.
If you still want to use your own development environment, there are two minor issues to remember:
Tools are prefixed with arm-linux-, so for calling the gcc C-compiler, you must call arm-linux-gcc, and so on.
Tools are located in /usr/local/arm/3.4.5/bin/ directory, which is not in PATH by default.
To run an application on Access Server, it must first be transferred to it. There are several ways of doing this (see Section 2.3.3). The most convenient ways in conjunction with software development are discussed in the following subsections.
An SCP transfer is done with a single command. In the following example, myapp is transferred to the /tmp directory in Access Server:
$ scp myapp root@<wrap-ip-address>:/tmp
root@<wrap-ip-address>'s password: buffy (not echoed back)
/path/to/myapp/myapp 100% 20KB 20.0KB/s 00:00
$
|
An SFTP transfer is almost similar, but the command procedure resembles an FTP session (FTP can also be used if the FTP server is enabled):
$ sftp root@<wrap-ip-address>
Connecting to <wrap-ip-address>...
root@<wrap-ip-address>'s password: buffy (not echoed back)
sftp> cd /tmp
sftp> put myapp
Uploading myapp to /dev/shm/tmp/myapp
/path/to/myapp/myapp 100% 20KB 20.0KB/s 00:00
sftp> quit
$
|
With SSHFS, the Access Server filesystem can be securely mounted to be a part of the development host's filesystem.
To download and install SSHFS, visit http://fuse.sourceforge.net/sshfs.html. After installation you can mount the whole filesystem and copy the myapp application to the /tmp directory in Access Server by using the following commands:
$ mkdir mnt
$ sshfs root@<wrap-ip-address>: mnt
root@<wrap-ip-address>'s password: buffy (not echoed back)
$ cp myapp mnt/tmp
$ fusermount -u mnt
$
|
If your Access Server is not connected to a LAN, you can use terminal software of your choice to transfer data to Access Server.
Access Server contains an X/Y/Zmodem protocol application, which allows you to transfer data over the console using almost any terminal software available:
Connect your computer to the Access Server management UART using a cross-over serial cable, and start your terminal software (use settings: 115 200bps, 8 data bits, no parity, 1 stop bit).
Change your working directory to where you want to upload your application, and run the Xmodem application with your application name as a parameter.
Start Xmodem send from your terminal software.
Example 6-1. Transfering Files with Xmodem
[root@wrap /] cd /tmp
[root@wrap /tmp] rx testapp
rx: ready to receive testapp.
now start xmodem (checksum, not CRC) send from your terminal
[root@wrap /tmp]
|
If you want to save the application to /usr/local/bin (on the flash file system), you will have to replace cd /tmp with cd /usr/local/bin (and possibly create the directory, if it does not exist). To examine Access Server directory structure, please see Appendix A.
To run the application you just transferred to Access Server, you need access to the Access Server console, either using terminal software connected to the Access Server management UART or using the SSH connection (log in as user root and the root password, which is buffy by default).
Having established a connection to Access Server, change the directory to where your application is located and change file permissions so that it can be executed, then run it.
You can use GNU debugger GDB and a graphical user interface, such as DDD, for debugging applications in Access Server. This requires that you install gdbserver to Access Server. It can be installed from a software package located in directory asdk/arch/arm/gpl/gdbserver/
You have to compile with debug options and without symbol stripping to make debugging work. This can be done by overriding the default CFLAGS variable set in asdk/Rules.mak. You can do this by adding line
CFLAGS = -Wall -Os -ggdb -I$(SDKBASE)/include
|
include /home/user/asdk/Rules.mak
|
After you have compiled your application with these options and transferred your application to Access Server, you can start debugging the application as follows:
Start gdbserver on Access Server
Usage:
gdbserver :<port> <your application> |
Example: gdbserver :6789 ./hello
Start debugger on the host PC. (This example is for the DDD)
Example: ddd --debugger /usr/local/arm/3.4.5/bin/arm-linux-gdb hello
Create a connection to Access Server.
Usage:
target remote <node IP>:<port> |
Example: target remote 192.168.42.3:6789
Run the program by using command continue.
It is also possible compile applications for Access Server using native toolchain. To use it, copy files sdk.iso and sdkmount.wpk from directory lib in the Access Server SDK CD-ROM (or ISO image) to the root directory of an USB memory dongle, and insert it to Access Server's USB port. (You can also use Compact Flash memory card for this purpose in similar manner). The native SDK is automatically mounted and you can start using the compiler (gcc) in Access Server. All tools now available can be found in directory /usr/sdk/bin.
| <<< Previous | Home | Next >>> |
| Obexsender | iWRAP - Bluetooth Interface |