Developing for the Iliad (1): Cross-compiling, runnning and diagnostics

Disclaimer: The following information was largely obtained experimentally by trial and error. In the absence of official developer documentation from iRex on these topics, it may no tbe correct in all circumstances or for all versions of the Iliad. Check it for your device before you rely on it.

Setting up the toolchain

The toolchain for developing applications for the Iliad can be downloaded from this location on the iRex website. (From what I have heard, there is another alternative toolchain, but I have not tried it.) It is meant to be unpacked to the root directory of your (Linux) system. I wanted to keep it separate from the rest of my system and therefore unpacked it somewhere else, which works too.

This shell script sets the paths to the toolchain executables, include files and ARM libraries. You have to adapt the variable TOOLCHAINDIR to your toolchain installation directory before you can use it. The script has to be run (obviously) on your development Linux box, not the Iliad, and it has to be sourced rather than run as an executable shell script, by one of these commands:

source iliadpaths.sh
. iliadpaths.sh

not like this:

./iliadpaths.sh

Afterwards, your shell prompt will have an additional suffix "(arm)" to indicate that you can now compile for the Iliad. You can then use the ARM cross compiler, linker and other binary tools by running arm-linux-gcc and other commands starting with arm-linux-... .

Running applications from the content lister

The simplest test applications that you might want to run, which only produce console output, can be run from the ssh command prompt. But as soon as you want to receive button input, this is not possible, because the X events relating to the buttons are generated by the content lister, and this is only done when it knows an application is running.

When you test a display program for a specific file type, you will anyway create an application type entry in registry.xml. However, wenn you run a string of small test programs which do not display files, creating such an entry every time is a hassle. This problem can be easily solved by creating one common application type entry referring to a symbolic link:

<application type="TEST">
  <appCategory>viewer</appCategory>
  <argMask>_FILENAME_ _MANIFEST_</argMask>
  <execute>/home/root/homebrew/testapp</execute>
  <supportFormat>
    <extName>tst</extName>
  </supportFormat>
  <xResourceName>testapp</xResourceName>
  <ipcChannel>14</ipcChannel>
  <appIconPath/>
</application>

Here, /home/root/homebrew/testapp is a symbolic link which you point to whichever test application you want to run. All you need in addition is a file with the file extension .tst in one of the document directories. Clicking on it will run the test program from the content lister. The .tst file is passed as the first argument of the program, and if a file named manifest.xml exists in its directory, it is passed as the second argument.

Debug output

When the content lister starts an application, its standard output and error channels are swallowed up. In order to get diagnostic information out, you have to choose different channels.

The simplest option is to write to a log file, which can then be read with less. One should remember to flush the file with the fflush C function, or it may be written only when the program terminates.

A more elegant way of printing debug messages is to write them to the terminal on which you are logged in via SSH. The relevant terminal device is /dev/pts/0, which can be opened for writing like an ordinary file. (Using SSH requires the SSH server to be installed on the Iliad, as described here.)

Finally, of course you can output debug messages on the screen. But the previous methods work also if you are having trouble with screen output, and do not clobber your normal screen output.

TOS / Impressum