Using Android in Industrial Automation

The title says it all, finally it is complete:
the long-awaited Technical Report of our project
… which you can download from here

Using Android in Industrial Automation – Technical Report

This report aims to cover all important aspects when setting up an appropriate hardware and software platform for Android, and also leads the reader through our spectrum analyzer application development. On top of that, you will find a setup guide in the appendix, containing detailed instructions on how to build your Kernel and the Android root file system, and further information on how to make use of the DSP, etc. Although some chapters are not as detailed as others, we always try to provide you with a good starting point by leading you into the right direction. Also, dont be afraid of the length of this report since you should be able to pick only these chapters that are of most interest to you

Come and see for yourself

Größere Kartenansicht

We finally managed to get a simple DSP task node running on our Beagleboard using Android. The sources were taken from felipec’s dsp-dummy at github. Many thanks for sharing this!

In this post we will provide you with a step by step guide for doing the exact same thing:

1. Get the dsp-dummy sources aswell as a C6x compiler and doffbuild tools. Make sure that you get the latest dsp-dummy sources by downloading them with git (the provided ZIP and TAR files may contain older versions)

git clone git://github.com/felipec/dsp-dummy.git

The C6x Compiler for the DSP can be downloaded from Texas Instruments . We have been using the linux version of C6000 Code Generation Tools v6.1.12. Preferably install to /opt/dsptools

Doffbuild tools are downloaded through

git clone git://gitorious.org/ti-dspbridge/userspace.git

You will end up with three subfolders called binaries, documents and source. Doffbuild tools are located in ./source/dsp/bdsptools/packages/ti/dspbridge/dsp/doffbuild. Copy the doffbuild folder to /opt/doffbuild or anywhere you like.

2. Now that we have all needed sources and programs, we will build the ARM and DSP side applications (you may notice that we only build the DSP side though ). Change to the dsp-dummy folder previously downloaded and issue

make DSP_TOOLS=/opt/dsptools DSP_DOFFBUILD=/opt/doffbuild CROSS_COMPILE=/opt/arm-2009q3/bin/arm-none-linux-gnueabi-

of course, you will have to adapt CROSS_COMPILE to whatever cross-compiler you are using. If everything went well, there will be two important files created, namely ‘dummy.dll64P’ for DSP-side, and ‘dummy’ for ARM-side. Copy dummy.dll64P to /lib/dsp on the android filesystem. If you try to run dummy on Android, you will end up with an error
dummy: not found

But dont panic, continue with step 3!
(or alternatively, set LDFLAGS to -static in the Makefile, and jump over to step 4… Oh no, now I spoiled everything! )

3. Now we will build the dummy userspace application especially for Android. In the Android sources, create a new folder under external/dsp-dummy

mkdir /external/dsp-dummy

Copy and paste everything from the dsp-dummy source folder into it. Also create an Android.mk file in that new folder containing the following lines

LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)

LOCAL_SRC_FILES:= \
 dummy_arm.c \
 dsp_bridge.c \
 log.c

LOCAL_C_INCLUDES:= external/dsp-dummy/

LOCAL_MODULE := dsp-dummy

LOCAL_STATIC_LIBRARIES := libcutils libc
include $(BUILD_EXECUTABLE)

Now source envsetup.sh followed by choosecombo, to set all environment variables and dependecies

. build/envsetup.sh
choosecombo

… and finally we create the dsp-dummy for Android …

mmm external/dsp-dummy/

If everything went well, you will find dsp-dummy in ./out/target/product/generic/system/bin/dsp-dummy. Copy this to the target file system.

4. In this step we will load a base image onto the DSP. We used to have DSP Bridge Driver statically included in the android omap.git kernel. One would normally load a base image with a DSP/BIOS Bridge Driver utility called ‘exec’ (sometimes called exec.out). However, until now we couldn’t get exec working on android so we will do this in a slightly different way. One can also load a DSP base image when inserting the bridgedriver.ko module into the kernel, and this is exactly what we’ll do!

First of all run

make menuconfig

inside the kernel folder. Go to device drivers, and in the bottom you will find DSP Bridge driver. Press M to modularize it. Now you can try to build the modules with

make -j4 modules CROSS_COMPILE=<path to crosscompiler> CC_PATH=<path to crosscompiler>

However, the bridgedriver module will not succeed. We have to modify a source file in the kernel (this is probably not nice!)

gedit ./kernel/fork.c

and add the following on line 161; just after the function void __put_task_struct(struct task_struct *tsk) ends.

EXPORT_SYMBOL(__put_task_struct);

Now you can build the modules! As a result, you’ll get dspbridge.ko and bridgedriver.ko. Copy these two to the Beagleboard. We will load the dspbridge.ko module using insmod, and also load the bridgedriver.ko with an additional paramter specifying the location of a DSP base image.

insmod dspbridge.ko
insmod bridgedriver.ko base_img=<path to base image>

For the base image we use the provided dynbase_tiomap3430.dof64P, which can be found in the binaries subfolder from step 1 of this guide. Do you still remember? Therefore copy dynbase_tiomap3430.dof64P to the target filesystem and issue the command above.

5. Now you can finally run the dsp-dummy application on Android Beagleboard, what a relief!

# dsp-dummy
info external/dsp-dummy/dummy_arm.c:67:create_node() dsp node created
info external/dsp-dummy/dummy_arm.c:114:run_task() dsp node running
info external/dsp-dummy/dummy_arm.c:124:run_task() running 14400 times
info external/dsp-dummy/dummy_arm.c:161:run_task() dsp node terminated
info external/dsp-dummy/dummy_arm.c:81:destroy_node() dsp node deleted

USB & Android

It is long overdue to talk about porting specific projects to Android. It is astonishingly easy to do so with the Android platform.
Since we are using USB for our project we found it convenient to work with libusb 1.0. Using the Beagleboard we are able to make use of the USB 2.0 high speed functionality of libusb.

Libusb itself consists of a shared library and two sample applications. One of those applications is the lsusb command which lists connected USB devices in the console.

These five Steps is all it takes to port the existing libusb open source project to the Android platform.

1. Get the libusb-1.0 sources [link] and create an empty “libusb-1.0.3″ folder in the external directory of your Android sources. Unpack the libusb folder into the new directory.

2. Create Android.mk files in each of the libusb directories. In the top folder your Android.mk just calls your mk files in the libusb subfolders :

LOCAL_PATH := $(call my-dir)
ubdirs := $(addprefix $(LOCAL_PATH)/,$(addsuffix /Android.mk, \
		libusb \
))
include $(subdirs)

in the libusb folder add the following Android.mk

LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)

LOCAL_SRC_FILES:= \
   core.c \
   descriptor.c \
   io.c \
   sync.c \
   os/linux_usbfs.c 

LOCAL_C_INCLUDES += \
 external/libusb-1.0.3/ \
 external/libusb-1.0.3/libusb/ \
 external/libusb-1.0.3/libusb/os 

LOCAL_MODULE:= libusb
include $(BUILD_SHARED_LIBRARY)

You see the syntax of these Android.mk files is very simple. You just tell the compiler what modules you want to include and where your header files are.

3. Soon we are ready to compile the library; if we do so now, we will notice that the macro TIMESPEC_TO_TIMEVAL is not defined by the sources inside Android. To overcome this problem we just need to define the macro in the lubusb/io.c file.

#define TIMESPEC_TO_TIMEVAL(tv, ts)                                     \
        do {                                                            \
                (tv)->tv_sec = (ts)->tv_sec;                            \
                (tv)->tv_usec = (ts)->tv_nsec / 1000;                   \
        } while (0)

If you compile your libusb now, there is going to be the following error: build/tools/apriori/prelinkmap.c(137): library ‘libusb.so’ not in prelink map. This is because Android keeps track of all the shared libraries of the root file system (RFS). Therefore we need to add the library to the prelinked map found in ./build/core/prelink-linux-arm.map. We did so and just added libusb.so below libqcamera.so.

libqcamera.so       0xA9400000
libusb.so           0xA8000000

You are now all set to compile libusb. Execute the following commands in your Android root directory:

$ . build/envsetup.sh
$ choosecombo

Choose your build variant. Afterwards you can compile the whole RFS with make or just that one project:

mmm -j4 /external/libusb

4. Your library is ready… but your usb-file system is almost certainly not mounted yet. In your init.rc of the RFS add the following command to mount your USBFS.

mount usbfs none /proc/bus/usb -o devmode=0666

Add the line somewhere below the “on boot” event.

5. Now we need to compile lsusb. The sources are located in the examples folder of libusb. Create a folder lsusb in the ./external directory of the Android sources. Copy the lsusb.c module into it and create a Android.mk file:

LOCAL_PATH:= $(call my-dir)

include $(CLEAR_VARS)
LOCAL_SRC_FILES:= lsusb.c
LOCAL_MODULE := lsusb
LOCAL_C_INCLUDES += external/libusb-1.0.3/
LOCAL_SHARED_LIBRARIES := libc libusb
include $(BUILD_EXECUTABLE)

Execute the build command:

mmm -j4 /external/lsusb

and we are done! Congratulations! You just ported an entirely non-Android specific project to your Android platform!

Simply execute lsusb in your Android shell to verify if everything worked properly.

Application access to the DSP

The Beagleboard features a Digital Signal Processor (TMS320C64x+ DSP). For our spectrum analyzer it would be a very nice feature to calculate the FFT in the DSP.

To access the DSP the Kernel needs to implement the DSP-Bridge driver. However, it is quite challenging to get the driver into the Kernel. Several attempts to patch the Embinux Kernel with the original patches failed. [Embinux Kernel Git Repository]

The good news is that the omap-kernel (linked in the Android Git repository) features the DSP-Bridge driver that we were looking for. [Android omap Kernel Git Repository]

The challenge was to get the Kernel running on the Beagleboard. We had first given up on it since the USB-Host Controller was not working. But after trying every other Kernel (Embinux, 0xdroid, mainline omap kernel, etc.) we gave it another try. Since we are booting an NFS Root File System we needed USB and Ethernet support on startup time. The key is to configure the Beagleboard’s USB-OTG as a Host Device. This can be done in the menuconfig of the Kernel. This was not the only challenge. A Kernel panic occurred when looking for the init file.
The solution was to configure the Kernel properly and including all Android driver modules (which seems kind of obvious at this point). To give you an idea of how the config of the 2.6.29 Android Omap Kernel could look like you can check our .config out here. [.config file]

Android now boots correctly.

Well, there is still one problem though. The Input Event Subsystem seems to be messed up, thus our keyboard and mouse is not working at all.
The Event Input Subsystem works now properly with the above .config file.

To break it down:

Working with the omap-Kernel of the Google Git repositories we can state the following:
Pro:

• DSP-Bridge Driver
• Nicely maintained by a big community

Con:

• USB-Host Controller not working yet (USB OTG in host mode works)