In this post we are going to set up the Arduino Uno to measure light intensity. Furthermore, we configure and recompile the Pandaboard’s kernel to communicate with the Arduino Uno through USB-serial.

For measuring light, we will require some kind of photoresistor. If you do not have any spare ones around, you can easily get them on ebay. A photoresistor is a resistor that changes its resistance depending on the current light intensity. In the end, we will simply measure an analogue voltage that changes depending on the attached photoresistor.

For this tutorial you will need:

• Pandaboard with Linaro’s Android build from Part I
• Arduino Uno
• 1 Photoresistor
• 1 Resistor with a value around 3 kilo-ohm (we are using 3.9kOhm)
• Breadboard
• 3 jumper wire cables (male-male)

Lets get started with setting up the Arduino Uno
The following diagram shows the components and connections for interacting with the Arduino Uno. As can be seen, we will measure the voltage in between the photoresistor and the common resistor, as this terminal is connected to the Arduino’s analog in pin A0. At normal daylight, our photoresistor has a resistance of around 3kOhm (measured with a multimeter). So we choose the other resistor at around the same value of 3.9kOhm (this was just the closest resistor value we had lying around). This way, when there is normal light, the voltage at the A0 pin will be about half of 5V, so 2.5V, and yielding an ADC value of 128. If there is more light, the photoresistor’s resistance drops and the voltage at the terminal rises. And vice versa if there is less light.

So take out your breadboard and said components and try to rebuild the above diagram. If you do not have a photoresistor, you can also just attach a jumper cable to the A0 pin and measure different voltages such as the on-board 5V, 3.3V and GND pins.

Depending on your setup, this should look something like that …

… and like this when connected to the Arduino Uno

We will of course also need some firmware running on the Arduino. The following code will measure the voltage at the A0 pin 10 times per second and send back the values over the serial communication interface. So build and upload the following source file:
serverbox_arduino_lighlogger.c

Communication between the Arduino and your host computer

Once this is done, we can already try if everything works so far by connecting the Arduino to our host computer via USB. Right after connecting, run dmesg in a terminal. You should see something like new USB device, and the corresponding name, ttyACM0 in our case:

user@host:~$ dmesg
...
[185930.828750] usb 1-2.4.2: new full-speed USB device number 21 using ehci_hcd
[185930.924549] cdc_acm 1-2.4.2:1.0: ttyACM0: USB ACM device

Let’s have a look at the newly created device node on the host computer:

user@host:~$ ls -l /dev/ttyACM*
crw-rw---- 1 root dialout 166, 0 Nov 28 17:38 /dev/ttyACM0

The Arduino shows itself as a device node with major number 166, which is used for USB ACM devices. You can double check that in the kernel documentation under /opt/android/source/kernel/Documentation/devices.txt. The actual ACM device is the small ATmega16u2 controller right next to the USB connector. We will use this device node for serial communication, so we need to adjust the permissions:

user@host:~$ sudo chmod 666 /dev/ttyACM0

Now there are many different ways to read from the serial console. I personally like to use hterm (you will need the ia32-libs package if your host is 64 Bit.. which should already be installed if you followed the guide in part 1). You can also use gtkterm, or even minicom. Our firmware on the Arduino simply writes the current ADC value (0…255) to the serial console. So if this output is interpreted as ASCII symbols, this will pretty much look like bogus. Some terminal programs such as hterm allow you to change the output type to hex or dec. Minicom does not have this functionality however. If you want to use a terminal program, just remember to use the following settings:

Port: /dev/ttyACM0
Speed: 9600baud
Data-Parity-Stopbits: 8N1

In this tutorial we will use a small program which reads directly from the created serial device node.
termios.c
Download the above source file, compile it with gcc and run it.

user@host:~$ gcc termios.c -o termios
user@host:~$ ./termios
read 136: 166
read 1: 157
read 1: 159
read 1: 160
read 1: 160
read 1: 158
...

If you do not see any output, make sure the device node still has the appropriate permissions as set above (sudo chmod 666 /dev/ttyACM0), also the device node name /dev/ttyACM0 is hard-coded in this example. So if your device node is called ttyACM1 for example, make sure to adjust it in termios.c as well. If everything works, try to shade your photoresistor or brighten it up with a flash light. The values should update accordingly.

Configuring the Pandaboard to communicate with the Arduino
One can communicate between the Arduino and the Pandaboard pretty much in the same way. However, the current Pandaboard kernel does not have USB ACM support yet. So we need to reconfigure and recompile the kernel with this configuration enabled. With the new kernel running, a device node /dev/ttyACM0 will be created on the Pandaboard as soon as the Arduino is connected, just like on our host computer.
The current kernel configuration is called android_omap4_defconfig. We will use this config and add USB ACM support.

user@host:/opt/android/source/kernel$ cp arch/arm/configs/android_omap4_defconfig .config
user@host:/opt/android/source/kernel$ make menuconfig ARCH=arm

Now navigate to Device drivers, USB support, and enable USB Modem (CDC ACM) support by pressing “Y”. Navigate back with Escape and save your changes. We will also save the new config for later:

user@host:/opt/android/source/kernel$ mv .config arch/arm/configs/android_omap4_cdc_defconfig
user@host:/opt/android/source/kernel$ make clean
user@host:/opt/android/source/kernel$ make mrproper

Our kernel was automatically built through the Android build system and we need to make adjustments so that from now on our modified kernel configuration is used.

user@host:/opt/android/source/kernel$ cd ..
user@host:/opt/android/source$ gedit device/linaro/pandaboard/BoardConfig.mk

In the above BoardConfig.mk file, we replace all occurences of android_omap4_defconfig with our new config android_omap4_cdc_defconfig. Now we are ready to rebuild the kernel:

user@host:/opt/android/source$ . build/envsetup.sh
user@host:/opt/android/source$ choosecombo 1 pandaboard 3
user@host:/opt/android/source$ make boottarball TARGET_TOOLS_PREFIX=../android-toolchain-eabi/bin/arm-linux-androideabi-

The new kernel will be found in the out folder and needs to be copied onto the SD card’s boot partition:

user@host:/opt/android/source$ cp out/target/product/pandaboard/boot/uImage /media/boot
user@host:/opt/android/source$ sync
user@host:/opt/android/source$ umount /media/*

Congratulations! You have just recompiled and deployed the kernel to support USB ACM devices. On the Pandaboard’s Android terminal, run ‘dmesg’ right after connecting the Arduino to your Pandaboard. You should see that a new device node /dev/ttyACM0 was created.

So what now? We have ACM support enabled on our Pandaboard’s kernel, now we need a user space program to actually read from the created device node. The cool thing is that we already have an existing command line program, the exact same as above – termios.c – which we used on the host computer. Earlier we used gcc to compile this program for the host computer, this time however we need to cross-compile the exact same program for our target, the Pandaboard, and thus compile it for an ARM architecture.

Again, there are multiple ways to do this. Here we will present a method that is very similar to the way that Android’s external projects are built. First of all download the Android Native Development Kit (Android NDK). Make sure that you choose the right version (Linux 64-bit). Extract the Android NDK anywhere you like, it’s also a good idea to add the installation directory to your PATH variable. Inside the extracted Android NDK folder, there are many good sample applications for using JNI and also a well-written documentation in html form. Be sure to check that out some time. For now, we are only going to use the ‘ndk-build’ executable inside the Android NDK top folder. When calling the ‘ndk-build’ executable from the command line, it will look for a sub-folder called ‘jni’ (relative to the current working directory), and within this folder it will parse a file named Android.mk. The reason for that is that ndk-build is normally used in conjunction with a Java/Android project (just like the ones created with Eclipse ADT Bundle), and all native C code inside an Android project source folder is placed in a sub-folder called jni. Inside this jni folder there should be at least said Android.mk file and also of course the native source file, termios.c in our case.

user@host:~$ mkdir termios
user@host:~$ cd termios
user@host:~/termios$ mkdir jni
user@host:~/termios$ cd jni
user@host:~/termios/jni$ gedit termios.c
user@host:~/termios/jni$ gedit Android.mk

The contents for termios.c can again be downloaded here. The contents for the Android.mk file should be :

LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES:= termios.c
LOCAL_MODULE := termios
include $(BUILD_EXECUTABLE)

(compare this to /opt/android/source/external/ping/Android.mk)
Within the created termios folder call ‘ndk-build’

user@host:~/termios$ ndk-build

This will cross-compile the program termios.c as an executable for our ARM target architecture and save it under termios/libs/armeabi/termios. Use the Android Debug Bridge (adb) to push this file to the target, and then execute it on the Pandaboard. You should see a similar output as on the host computer.

user@host:~/termios$ adb push libs/armeabi/termios /termios
user@host:~/termios$ adb shell
root@android:/# chmod 777 termios
root@android:/# ./termios

In this tutorial’s next part we will show you how to create a JNI wrapper function and thus how to use JNI to communicate with external hardware from within an Android Java application.

Recently we have been setting up the Pandaboard with Android to get started with Embedded System Development.

In this first post we would like to share of what steps were necessary to set up the build environment, Android source from Linaro and toolchain to get started on an Ubuntu 12.04 64 Bit machine.

Android Build and Version: Linaro Android Build, 4.1.1 Jellybean
Host Machine: Lenovo T420, Ubuntu 12.04 64 Bit
Hardware Target: Pandaboard
Deployment Target: SD-Card

Please note that since the Android ICS release, the Android Source can (sadly) only be built on a 64 bit OS, without the need to do workarounds.

Important Links for further reading:

Linaro Android Project
Build Environment Initializing
Current Linaro Build version information

Setting up the build environment

Before you can get started to build the Android Source code and Kernel, you need to set up the build environment properly. Part of this is installing packages from the Ubuntu repositories (for instance build tools like make and host side gcc etc.) and also the java version (from sun/oracle) which cannot be found in the current Ubuntu repositories.

Also we recommend you set up some primary build workspace for instance in “/opt/android/”. If you are new to Ubuntu and the Bash you will find countless excellent tutorials in the net. For this guide you should already be familiar with the command line and some of Linux most prominent tools.

Let’s get started

We assume you are user user on a machine host.

First of all grab a terminal on you Host machine either by finding it in the start menu or by hitting ctrl+alt+t.

Now let’s set up some workspace for our source in the /opt directory.

user@host:~$ sudo mkdir /opt/android
user@host:~$ sudo chown -R user.user /opt/android
user@host:~$ cd /opt/android
user@host:/opt/android$ 

Following the guide on the source.android.com site we set up the packages required for building android.

user@host:/opt/android$ sudo apt-get install -f git-core gnupg flex bison gperf build-essential zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 libgl1-mesa-dev g++-multilib mingw32 openjdk-6-jdk tofrodos python-markdown libxml2-utils xsltproc zlib1g-dev:i386
user@host:/opt/android$ sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so
user@host:/opt/android$ sudo apt-get install lib32ncurses5-dev

Also we need some additional packages for debugging over the serial console and to set up the bootloader for android.

user@host:/opt/android$ sudo apt-get install minicom
user@host:/opt/android$ sudo apt-get install ia32-libs
user@host:/opt/android$ sudo apt-get install u-boot-tools

At some point we noticed some libraries had problems installing. Be sure to do this command after installing all the packages…

user@host:/opt/android$ sudo apt-get install -f

That should do it.

user@host:/opt/android$ java -version
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.5) (6b24-1.11.5-0ubuntu1~12.10.1)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)

Now we need to install java. This is a tricky part, since it used to be much easier to do this in Ubuntu a while back. As far as we know Oracle forced Canonical to take down the binaries of java from their repositories. What a shame …
For the setup we configured the java installation by hand.

Navigate here and select the .bin of the 64 bit download (jre-6u34-linux-x64.bin). Because they seem very interested of who downloads their java they want you to register on their website. We actually did not try to build the source with iced-tea java, so we do not know if that works as well. However we cannot wait to be able to skip oracle’s java for building android.

As soon as you grabbed the binary you can do the following to install it and let Ubuntu know where to find all the commands.

user@host:~/Downloads$ chmod a+x jre-6u34-linux-x64.bin
user@host:~/Downloads$ mv jre-6u34-linux-x64.bin /opt/android && cd /opt/android
user@host:/opt/android$ ./jre-6u34-linux-x64.bin
user@host:/opt/android$ sudo update-alternatives --install "/usr/bin/java" "java" "/opt/android/jdk1.6.0_34/bin/java" 1
user@host:/opt/android$ sudo update-alternatives --install "/usr/bin/javac" "javac" "/opt/android/jdk1.6.0_34/bin/javac" 1
user@host:/opt/android$ sudo update-alternatives --install "/usr/bin/javaws" "javaws" user@host:/opt/android$ "/opt/android/jdk1.6.0_34/bin/javaws" 1
user@host:/opt/android$ sudo update-alternatives --config java
user@host:/opt/android$ sudo update-alternatives --config javac
user@host:/opt/android$ sudo update-alternatives --config javaws

To be sure check what happens if you execute the “java” command and check the version with “java -version”. The output should look something like this:

user@host:/opt/android$ java -version
java version "1.6.0_34"
Java(TM) SE Runtime Environment (build 1.6.0_34-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.9-b04, mixed mode)

Fetching the Android Source Code

For this step you should probably get a few cups of coffee ready since depending on your network connection it might take quite a while.
First you need to fetch “repo” which is a tool that helps you to keep track of all the necessary Android GIT repositories (GIT is by the way awesome, you should look into it if you have not done that already).

user@host:/opt/android$ mkdir ~/bin/
user@host:/opt/android$ curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
user@host:/opt/android$ chmod a+x ~/bin/repo

Before we fetch the source code we also fetch the Linaro toolchain which is needed to cross compile the Android source code. Also we install the linaro image tools to deploy the Android/Kernel/uBoot images to the SD-Card once built.

Note: Before you do the next two steps, decide which build version you want to use. Have a look at the build version table for the latest releases.

user@host:/opt/android$  wget http://snapshots.linaro.org/android/~linaro-android/toolchain-4.7-2012.10/1/android-toolchain-eabi-linaro-4.7-2012.10-1-2012-10-15_16-19-17-linux-x86.tar.bz2
user@host:/opt/android$ tar -xvf android-toolchain-eabi-linaro-4.7-2012.10-1-2012-10-15_16-19-17-linux-x86.tar.bz2
user@host:/opt/android$ sudo apt-get install linaro-image-tools

At this point we create a “source” subdirectory and start fetching the Android source code from the Linaro repository.

user@host:/opt/android$ mkdir source && cd source
user@host:/opt/android$ repo init -u git://android.git.linaro.org/platform/manifest.git -b linaro-android-12.10-release -m staging-panda.xml
user@host:/opt/android$ repo sync

The upper commands may differ from what version you are using.

Building the Source Code

As soon as the source is downloaded you are ready to give it a first build. In the source directory do the following to start building for the pandaboard:

user@host:/opt/android/source$ . build/envsetup.sh
user@host:/opt/android/source$ choosecombo 1 pandaboard 3
user@host:/opt/android/source$ make -j4 TARGET_TOOLS_PREFIX=../android-toolchain-eabi/bin/arm-linux-androideabi- boottarball systemtarball userdatatarball

Make sure though that the toolchain is actually in the folder “/opt/android/android-toolchain-eabi”.

Now depending on if your package installation process from the beginning was successful or not, the build will complete successfully and output three tarballs (boot.tar.bz2, system.tar.bz2 and userdata.tar.bz2).

If the build is not successful then go back to the start of the guide and make sure ALL your packages install correctly (if apt throws errors just do a “sudo apt-get install -f” with no packages as arguments).

After completion of compiling source code (the kernel was compiled as well with the command before) you should now format an SD card and deploy the images.

If you are using GNOME (if you are not sure that you are then you ARE using GNOME ), then you also need to do a few tricks so the SD-Partitioning runs without problems. Linaro has just updated their deployment guide recently for this.

user@host:/opt/android/source$ TMP1=$(dconf read /org/gnome/desktop/media-handling/automount)
user@host:/opt/android/source$ TMP2=$(dconf read /org/gnome/desktop/media-handling/automount-open)
user@host:/opt/android/source$ dconf write /org/gnome/desktop/media-handling/automount false
user@host:/opt/android/source$ dconf write /org/gnome/desktop/media-handling/automount-open false

The above steps are currently untested, but we trust that the guys did a good job on this

Now insert you SD-Card into your card-reader. Check with “sudo fdisk -l” which devices are available for you. Be really careful here to not pick the wrong device, since all contents of the chosen one will be DELETED irrecoverably.

So if your SD-Card is on “/dev/mmcblk0″ then you would do the following command. Note that depending on your SD-Card Reader it is possible the device is found under “/dev/sdX”.

user@host:/opt/android/source$ cd out/target/product/pandaboard
user@host:/opt/android/source/out/target/product/pandaboard$ linaro-android-media-create --mmc /dev/mmcblk0 --dev panda --boot boot.tar.bz2 --system system.tar.bz2 --userdata userdata.tar.bz2

During this time the SD-Card is being formated and partitioned properly. We had sometimes difficulties on some hosts with running this script, however, the automount trick should fix the issue.

Now restart the automount feature of gnome

dconf write /org/gnome/desktop/media-handling/automount $TMP1
dconf write /org/gnome/desktop/media-handling/automount-open $TMP2

The last thing we need to do is to install the proprietary drivers of the OEM for the Pandaboard. This is done by grabbing the binaries and pushing them to the system partition of the SD-Card.

For this purpose remove the SD-Card and Plug it back in after re-enabling the automount feature of gnome.

The second partition of your SD-Card holds the contents of the “system” image. In our case this was /dev/mmcblk0p2, it might differ for you depending on your SD-Card reader it could be something like /dev/sdXp2 as well.

user@host:/opt/android/source/out/target/product/pandaboard$ wget http://people.linaro.org/~vishalbhoj/install-binaries-4.0.4.sh
user@host:/opt/android/source/out/target/product/pandaboard$ chmod a+x install-binaries-4.0.4.sh
user@host:/opt/android/source/out/target/product/pandaboard$ ./install-binaries-4.0.4.sh dev/mmcblk0p2

You are almost done. Be sure to ALWAYS do a “sync” and an “umount” BEFORE you remove your SD-Card. Doing otherwise can screw up your files!

user@host:/opt/android/source/out/target/product/pandaboard$ sync
user@host:/opt/android/source/out/target/product/pandaboard$ sudo umount /dev/mmcblk0

Now put your SD-Card into your Pandaboard and see it booting.

Console via USB-Serial Converter

For debugging you can now use minicom. To do so, hook up your USB-Serial converter to your Beagleboard and on the host run minicom.

In the config go to “Serial port setup” then press “a” and change the device according to your serial device node (“/dev/ttyUSB0″ or something), then press ENTER to confirm and hit “f” to disable hardware flow control. Now hit ENTER twice and select “save setup as panda”.

user@host:/opt/android/source/out/target/product/pandaboard$ sudo minicom -s panda

Exit the terminal at any time using “ctrl+a, z, q” and reconnect with your new config using

user@host:/opt/android/source/out/target/product/pandaboard$ sudo minicom panda

You should now be able to start with the real fun. You downloaded and compiled the Android source and set up the SD-Card for deployment.

Today, it is my pleasure to announce the release of our all new open source Android application of the OsciPrime Oscilloscope. We worked eagerly to bring a large amount of requested and desired features to our Android application, and guess what, it is all Open Source.

With the new release we also announced that we are in the process of making our hardware board available for ordering. Check all news out on our product website www.osciprime.com.

Features and improvements of the new application are:

=> Mutlitouch Interface
=> Control Interleave, Attenuation, Offset, Zoom, etc.
=> Using the new Android USB API for communication with the hardware board
=> Neat new User Interface, as modular as possible
=> Improved processing performance for both Audio and USB

If you want to support our open source development and always receive the newest version of the scope, then consider purchasing our application from the Android Market here.

If you want to meet us and find out more about the project, then join us on the 10. of July 2012 at the Libre Software Meeting in Geneva, where we are going to present our Open Source Project.

Head over to our OsciPrime Website to catch the latest source code and APK. here.

We are eager to hear your thoughts and improvements of the applications in the comments section.

OsciPrime Website
OsciPrime Android Market Site
OsciPrime Source Code

Intro

In the past two posts we have explained the basics of USB communication with the Arduino Uno (also applicable for Arduino Mega).

• Programming the Arduino Uno with Eclipse on Linux
• Arduino USB transfers

Galaxy Nexus to Arduino UNO via USB

In this post we’ll put everything together and show you how to communicate between your Android application and the Arduino using nothing but the Android USB host API. Remember, this approach has nothing to do with Android ADK! Unlike Android ADK, your Android device will act as the USB host, while your Arduino board will act as the USB device.

For the following application to work, you will require an Android device that supports USB host mode as well as the USB host API. Most Android 3.1+ tablets will suffice (some may require an USB OTG adapter). Also, the Galaxy Nexus has host mode enabled and matches the requirements (you will need an USB OTG adapter however).

This example consists of two parts:

• The Android application that makes use of the USB API
  A simple Android app that let’s you regulate the brightness of an LED on the Arduino using a slider. It also features a button to “enumerate” the USB device.
• Firmware for the Arduino that does some serial I/O with the Android app
  Very basic firmware for the Arduino. An interrupt is generated when a new byte is received. The received data controls the brightness of the Arduino’s on-board LED.
  (implemented via usleep-style software pwm in the main loop).

The Arduino firmware

In the main loop the firmware asserts and clears the LED pin of the Arduino (PB5). Here is a shortened excerpt:

	
int main(void) {
	//initialization
	initIO();
	uart_init();
	sei();

	uint8_t i = 0;
	volatile uint8_t pause;

	for(;;){//this is the main loop
		pause = data;
		PORTB |= (1 << LED);
		for(i = 0; i < pause; i++)
			_delay_us(10);
		PORTB &= ~(1 << LED);
		for(i = 0; i < 255-pause; i++)
			_delay_us(10);
	}
}

During a period of 2550[us], the LED is asserted for a duration of pause*10 [us] and cleared for (255-pause)*10[us]. Simply put, this is a very simple software PWM.

During that time, "data" and consequently "pause" may be changed within an interrupt routine form the serial USART port. This happens when the Android side sends data to the Arduino. The interrupt routine is extremely basic:

ISR(USART_RX_vect) {//attention to the name and argument here, won't work otherwise
	data = UDR0;//UDR0 needs to be read
}

The RX data has to be read in the ISR (interrupt service routine) from UDR0; have a look at the Atmega328P reference manual for further details. Since we are doing no multi-buffering shenanigans the handling is extremely simple (no need to call cli() or anything).

The rest of the code is initialization of the I/O pins and UART functionality. Download the complete example here: led_pwm.c

Controlled LED on the UNO by the firmware

The Android app

The Android application uses the basic knowledge of the preceding blog post Arduino USB transfers. During USB initialization, the Arduino USB serial converter is set up and after that, communication is done using the bulk IN endpoint of the very same serial converter.

With both the aforementioned firmware installed your Arduino board and the Android application installed on your phone or tablet, you will be able to control the brightness of the Arduino Uno's built-in LED with a slider on your Android device. Again, please note that this will only work with devices that actually support both USB host mode (hardware, kernel requirement) as well as the Android USB host API (Android OS requirement).

The source code is available here: UsbController.tar.gz*
* You may need to change the PID value in UsbControllerActivity.java on line 38, if you have an Arduino Uno Rev3 or higher. You can check the VID/PID value with 'lsusb' after connecting the Arduino to your computer.

Many parts of the code are probably familiar to Android SW engineers. The most interesting section is in the class UsbController where the Arduino device is set up and communication is initiated. So let's have a closer look at the inner class UsbRunnable within UsbController:

private class UsbRunnable implements Runnable {
	private final UsbDevice mDevice;

	UsbRunnable(UsbDevice dev) {
		mDevice = dev;
	}

	@Override
	public void run() {//here the main USB functionality is implemented
		UsbDeviceConnection conn = mUsbManager.openDevice(mDevice);
		if (!conn.claimInterface(mDevice.getInterface(1), true)) {
			return;
		}
		// Arduino USB serial converter setup
		conn.controlTransfer(0x21, 34, 0, 0, null, 0, 0);
		conn.controlTransfer(0x21, 32, 0, 0, new byte[] { (byte) 0x80,
				0x25, 0x00, 0x00, 0x00, 0x00, 0x08 }, 7, 0);

		UsbEndpoint epIN = null;
		UsbEndpoint epOUT = null;

		UsbInterface usbIf = mDevice.getInterface(1);
		for (int i = 0; i < usbIf.getEndpointCount(); i++) {
			if (usbIf.getEndpoint(i).getType() == UsbConstants.USB_ENDPOINT_XFER_BULK) {
				if (usbIf.getEndpoint(i).getDirection() == UsbConstants.USB_DIR_IN)
					epIN = usbIf.getEndpoint(i);
				else
					epOUT = usbIf.getEndpoint(i);
			}
		}

		for (;;) {// this is the main loop for transferring
			synchronized (sSendLock) {//ok there should be a OUT queue, no guarantee that the byte is sent actually
				try {
					sSendLock.wait();
				} catch (InterruptedException e) {
					if (mStop) {
						mConnectionHandler.onUsbStopped();
						return;
					}
					e.printStackTrace();
				}
			}
			conn.bulkTransfer(epOUT, new byte[] { mData }, 1, 0);

			if (mStop) {
				mConnectionHandler.onUsbStopped();
				return;
			}
		}
	}
}

After the USB interface has been claimed the Arduino USB serial converter is initialized by issuing the following control transfers:

conn.controlTransfer(0x21, 34, 0, 0, null, 0, 0);
conn.controlTransfer(0x21, 32, 0, 0, new byte[] { (byte) 0x80,
				0x25, 0x00, 0x00, 0x00, 0x00, 0x08 }, 7, 0);

The first call sets the control line state, the second call sets the line encoding (9600, 8N1).
For communication, an additional thread is used to send data without blocking the Activity's main UI thread. By notifying sSendLock of the UsbController the data will be transferred. After submission, the thread will go into "wait" again. This way, even if submission takes more time than expected, the Activity's main thread will not be blocked and hence the app will not become unresponsive.

Screenshot of the Android App

Also note that in the Android Manifest none of the XML-style device filters are needed, since enumeration happens by the user in the app when pressing the "enumerate" button. Device filters - and therefore automatic activity launch when connecting the Arduino - are not used in this example in order to make the code simpler to comprehend. However, this could be easily implemented with a few lines of additional code.

For developing this example we have used a Galaxy Nexus Phone with an USB-OTG adapter cable. It has also been successfully tested with an Android Tablet, the Acer Iconia Tab A500, this tablet does not need any additional adapter cables.

This post concludes the 3-Part Arduino USB communication series. Feel free to post any questions or feedback/ideas in the comments section or contact us via E-Mail (http://www.nexus-computing.ch).

All code you find in this post can be used under GPL for your own projects.

The following section "About Android and USB Host" again concludes why USB-Host is becoming more and more important for mobile devices and points out main differences between Android ADK (Android Accessory Development Kit) and the Android USB Host API.

EDIT: control transfers for FTDI equiped Arduinos

Since we got requested a lot if the FTDI Usb-Serial converter will work too, here ist the control transfer code that needs to be exchanged. No warranties though

conn.controlTransfer(0x40, 0, 0, 0, null, 0, 0);// reset
conn.controlTransfer(0x40, 0, 1, 0, null, 0, 0);// clear Rx
conn.controlTransfer(0x40, 0, 2, 0, null, 0, 0);// clear Tx
conn.controlTransfer(0x40, 0x03, 0x4138, 0, null, 0, 0);

Source Links

Android App: UsbController.tar.gz*
Arduino main: led_pwm.c

* You may need to change the PID value in UsbControllerActivity.java on line 38, if you have an Arduino Uno Rev3 or higher. You can check the VID/PID value with 'lsusb' after connecting the Arduino to your computer.

About Android and USB Host

Lately it has become more and more popular to use tablets or mobile phones to communicate with the outside world over USB. After all, many devices now feature a full USB Host, either with a USB-OTG converter or even with a full sized USB Type A interface. Also, the future promises even more host availability on mobile phones. This opens up an entire range of new possibilities for already existing hardware as well as newly designed hardware for phones.

Not too long ago, Android received its own USB API. It was at the Google I/O in summer 2011 when the "Android Open Accessory Development Kit" was announced and released. However it lacked of a few crucial points. The API implied that there is an external USB host, acting as a "master" if you will.
On the one hand, this means that an already existing USB device mode gadget cannot work with your Android device. Therefore, if a manufacturer wanted to support Android phones it was necessary to create new hardware as well as new firmware. Secondly, the new hardware had to be designed to power itself and also deliver power the Android device; this implied that mobile gadgets require their own power source. And secondly, there was another issue: only devices running Android 2.3.4+ were shipped with the new API. Even then, it was up to the manufacturer to actually include the required stack in the OS.

But wait, there is another way to communicate over USB. At the same time (Google I/O) the Android USB Host API has been published for Android 3.1+. Starting with the second half of 2011, Android devices appeared which supported USB OTG (although devices with Android version < 3.1 were not supporting the API). With an appropriate adapter it has become possible for Android to act as USB Host. This meant that already present USB hardware has become compatible with the OS. As long as the kernel on the Android device supported the USB standard driver of the hardware (mass storage, input, etc.), Android would be able to use it and therefore open up a new range of extra devices compatible with the system.

However, there are many devices that have not been "compatible" from the beginning. For instance, let's say your common RFID reader. It most likely uses a USB-serial port and probably comes with a Linux or Windows driver as well as some software. Most Android tablets will come without the usb-serial driver for your RFID reader however. Therefore, if you want to load your driver you will need to root your tablet, determine the version of your current kernel, find the kernel sources online, hope that everything compiles to have your driver ready and then load it onto your tablet. In the end, when you finally have your kernel driver running, you will be required to write C code as well as some JNI glue to communicate with your Activity or Service in Android. All in all, this approach is not very straightforward.

Writing your own USB soft driver

There is a very elegant solution to aforementioned problem. It requires far less skills in hacking and porting than the mentioned approach. However, you will require some advanced knowledge in Android programming as well as some USB know-how.
You can write your own "soft driver" in Android. Since the USB Host API has been released, it is now possible to communicate with any USB device using the most commonly seen USB transfers (control, interrupt, bulk). In the end, your result will be portable across all Android devices that have USB host enabled and have Android version 3.1+. Moreover, this solution does NOT require root access to the tablet or phone. It is currently the only viable solution that does not require the user to have any know-how of rooting/hacking the device and risk losing warranty in the process.
The above Android application uses exactly this approach. It represents a very basic soft driver for the Arduino's on-board USB-to-serial converter.

In this post we will show you how to communicate between the Arduino Uno and your computer using plain USB bulk and control transfers, not relying on a serial communication interface. Our development computer runs Ubuntu 11.10 (Oneiric Ocelot).

This is a follow up to Programming the Arduino Uno with Eclipse on Linux. The next post in this series is Android USB Host + Arduino: How to communicate without rooting your Android Tablet or Phone.

The Arduino Uno has an on-board USB-to-serial converter (ATMega8u2 or ATMega16u2 since rev. 3). The preloaded firmware on this converter presents itself as an USB Communication Device Class (CDC). Usually, no further software driver is needed on the host computer. You can simply plug in the Arduino Uno to your computer, and you will be able to communicate with the Arduino’s main microcontroller, the ATMega328, over an emulated serial communication interface.

For many applications, a serial communication interface is just fine. You can use minicom, gtkterm or a similar terminal application to send and receive data from your microcontroller. Or even use a python serial library and start off from there. In some circumstances however, you might not have the possibility to open a serial communication. Android for instance does not have a native serial communication interface, instead it features an USB host API. In this case, you must rely solely on USB control and bulk transfers.

When you connect an Arduino Uno to your linux computer with an USB cable, you will notice that a new device node /dev/ttyACM0 or similar is created. For this purpose, check out the last few lines from dmesg right after connecting the Arduino Uno.
$ dmesg | tail
...
[] usb 1-5.2: new full speed USB device number 43 using ehci_hcd
[] cdc_acm 1-5.2:1.0: ttyACM0: USB ACM device

In the above example, the Arduino Uno is assigned to USB device number 43, and a new device node /dev/ttyACM0 is created. This device node is automatically created by the module cdc_acm and represents a serial communication interface which you can use with minicom, gtkterm, etc. However, we are not going to do that. We want to find out how to talk to this device using USB transfers, right?

Further investigations with the vendor (0×2341) and product (0×0001) id …
lsusb -v -d 2341:0001
… yield more interesting information about this device. For instance, bNumInterfaces = 2 shows that there are two available interfaces. This stems from the mentioned pre-loaded Arduino firmware. There you will see two projects:

• arduino-usbdfu is the Arduino USB DFU bootloader firmware, which is used for flashing the ATmega8u2 or ATmega16u2 respectively.
• arduino-usbserial is the real firmware of the USB-to-serial converter. This is where the magic happens

Again, looking at the output of …
lsusb -v -d 2341:0001
… you will see two interface descriptors. The first one with bInterfaceNumber=0 is the DFU bootloader, and the second one with bInterfaceNumber=1 is our usb-serial firmware interface descriptor. You can double-check that in arduino-usbdfu/Descriptors.c and arduino-usbserial/Descriptors.c respectively.

The starting point of the usb-serial project is in firmwares/arduino-usbserial/Arduino-usbserial.c. At the top, a variable VirtualSerial_CDC_Interface is initialized, and it is then passed in the main’s for-loop:
...
CDC_Device_USBTask(&VirtualSerial_CDC_Interface);
USB_USBTask();

The function CDC_Device_USBTask() is part of the LUFA-lib (Lighweight USB Framework Library), and is defined in CDCClassDevice.c. Likewise, this source file can be considered as the heart-piece of the usb-serial firmware. There we find all important functions such as CDC_Device_SendByte and CDC_Device_ReceiveByte. You will notice that almost every function returns immediately if no LineEncoding/Baudrate has been set. Luckily, the function CDC_Device_ProcessControlRequest (also in CDCClassDevice.c) unravels the mysteries of setting the LineEncoding, Baudrate, LineState, etc. Here is a shortened excerpt:

void CDC_Device_ProcessControlRequest() {
 switch (USB_ControlRequest.bRequest){
  case CDC_REQ_SetLineEncoding:
  if (USB_ControlRequest.bmRequestType == (REQDIR_HOSTTODEVICE | REQTYPE_CLASS | REQREC_INTERFACE)){
   CDCInterfaceInfo->State.LineEncoding.BaudRateBPS = Endpoint_Read_32_LE();
   CDCInterfaceInfo->State.LineEncoding.CharFormat  = Endpoint_Read_8();
   CDCInterfaceInfo->State.LineEncoding.ParityType  = Endpoint_Read_8();
   CDCInterfaceInfo->State.LineEncoding.DataBits    = Endpoint_Read_8();
  }
...

Now we’re cooking . To set the LineEncoding we therefore need to send an USB control request with bRequest = CDC_REQ_SetLineEncoding = 0×20 (as defined in CDCClassCommon.h) and with bmRequestType = 0×21. Also, the data must hold 7 bytes with corresponding values.

Once you know which requests to look for, it is pretty straightforward. Use an USB sniffer like wireshark and observe what happens when you plug in your Arduino board. With wireshark, you can also search for a specific bmRequestType by applying a filter like:
usb.bmRequestType == 0x21

As it turns out, there are two important control transfers when connecting the Arduino board to the computer. The first one has bRequest = CDC_REQ_SetControlLineState = 0×22 = 34 and the second one bRequest = CDC_REQ_SetLineEncoding = 0×20 = 32.

If you want to try it for yourself, download and run this python script (with sudo). This script will initialize the usb-serial-converter with USB control transfers and then send single bytes from your computer to the Arduino Uno using bulk transfers. Just make sure to remove the cdc_acm module beforehand by issuing:
$ sudo rmmod cdc_acm
As this module will otherwise lock access to the USB device. Also, you will need appropriate software running on your Arduino board. You may download this source code and flash it onto the device. This will set the duty cycle of a PWM signal on PIN3 according to the byte received from the computer. Also it will light up the on-board LED if the received byte is an odd value and shut it off when an even value is received.

This is the first of a series of three posts. The ultimate goal is to setup a communication interface between an Arduino Uno/Mega board and an Android tablet over USB. Everything will be as user-friendly as possible, i.e. no root will be required on your Android tablet. The following posts Arduino USB transfers and Android USB Host + Arduino: How to communicate without rooting your Android Tablet or Phone conclude the series.

The Arduino Uno is a popular and affordable hardware platform which comes with its own IDE and core libraries for programming. If you like the Arduino IDE you may skip this post, however, if you feel more comfortable developing in Eclipse this might help you out.
We are using Ubuntu 11.10 (oneiric ocelot) and Eclipse 3.6.1 (helios), although this should not play an important role (as it turns out, Eclipse Indigo might need a few tweaks, check the end of this post). Also, setting up Eclipse for programming the Arduino Uno Atmega328P is pretty straightforward. Nevertheless, here is a quick how-to for the Arduino Uno (Arduino Mega 2560 below):

1. Install avrdude and AVR libraries:
   sudo apt-get install gcc-avr avr-libc avrdude
2. Start Eclipse and install CDT Plugin (C/C++ Development Tools):
   • Help -> Install New Software…
   • Work with: (your current Eclipse version)
     i.e. “Helios – http://download.eclipse.org/releases/helios”
   • Download the “pending” software package (don’t worry, download starts automatically )
   • Choose “Programming Languages” and select “C/C++ Development Tools”
   • Accept and continue by restarting Eclipse
3. Install AVR Eclipse Plugin:
   • Help -> Install New Software…
   • Add new repository: http://avr-eclipse.sourceforge.net/updatesite/
   • Re-download the “pending” software package, download will be faster since it is probably cached
   • Download AVR Eclipse Plugin and restart Eclipse
4. Create new C project named “BlinkBlink”:
   • Project Type AVR Cross Target Application (Empty Project, AVR-GCC Toolchain)
   • Click next…
   • Untick “Debug” (in Debug mode, no hex-files are generated and avrdude can’t flash the device)
   • Click Advanced settings…
   • AVR -> AVRDude -> Programmer configuration…
   • Create a new programmer and name it “Arduino Uno”. Make sure this newly created programmer configuration is selected for the current project.
     • Programmer Hardware: Arduino
     • Override default port: /dev/ttyACM0 or similar
     • Override default baudrate: 115200
   • AVR -> Target Hardware:
     • MCU Type: ATmega328P (or load from MCU)
     • MCU Clock Frequency: 16000000 (default external clock source of Arduino Uno)
5. Click Apply and OK to leave the properties window and click Finish to create the new project in the workspace.
6. Create a new source file main.c and copy the contents from this link. Make sure to save main.c before proceeding (File -> Save).
7. Project -> Build Project
8. Click on the AVR Button within Eclipse to upload the generated hex file from BlinkBlink/Release/BlinkBlink.hex.
   Your Arduino Uno’s LED should be blinking on and off repeatedly. If somehow it doesn’t work, right-click your Project and select Properties. Make sure all AVR and Programmer settings are active as mentioned above.

For the Arduino Mega 2560 you should choose Atmel STK500 Version 2.x firmware as Programmer Hardware, and ATMega2560 as target hardware, the rest is the same as with the Arduino Uno. Also, if you are using the above source file for testing, you should change the definition of LED from PB5 to PB7, since the LED on the Arduino Mega is on Pin7 of Port B.

Update: if you are using Eclipse Indigo, some specific AVR symbols such as DDRB (data direction register of port b) may not be recognized.
To solve this problem go to preferences…

• C/C++
• Language Mappings
• Add the following mappings:
  • Content Type: C Header File / Language: GNU C
  • Content Type: C Source File / Language: GNU C

Your Language Mapping preference window should look like the following screenshot:

If it still does not work, also try adding this line at the beginning of your main.c source file:
#include <avr/iom128.h>

Lately we have received many concerns about using the serial interface on Android (Honeycomb with USB-Host). The way to usually communicate with a USB-Serial device in Linux, is to create a virtual serial interface and use it like a normal serial interface. For instance if you connect an FTDI controller via USB, a device /dev/ttyUSBX will be created.

USB-Serial Connection connects streams to Bulk Endpoints

However, behind the scenes you are actually communicating with the device using plain USB Bulk transfers. This job is done by the USB-Serial driver for you (ftdi_sio for instance). If you like to avoid using the kernel driver for some reason you can do this by using a library based on libusb called “libftdi”.

If you look at the source code you will notice that this library manages the connection (depending on the chip type) to the serial controller. Part of this task for instance is resetting TX/RX or setting the baudrate, which is not entirely trivial as it turns out.

Reading data is pretty simple (if your IN packet returns more than two bytes there is data ready). While when sending data you have to be sure not to write more than the max packet size defined by the controller. For details see the source code of libftdi.

Looking at Android there is a core problem with serial devices. As shown in a previous article it is pretty complicated to get started with building the driver. However, the even more painful part is, that there is no API-featured way to receive permissions for the /dev/USBX device node! So root is required.

But Hey! With libftdi, or it’s implementation it is now possible to write your own driver using the Android USB Host API. In the attached example application a connection to a VNC2 Controller is opened and each seconds one byte is transferred. For the example LEDs on the board are toggled. Using the Bulk OUT EP a rs232 “write” is emulated.

Download the Android source
Note that you should change the VID_PID String according to your device “VVVV:PPPP”.
Also note that if you would like to test if this works on your computer you should first remove the ftdi_sio driver using:
$ sudo rmmod ftdi_sio.

Debugging on your Ubuntu machine:
It’s probably much easier to debug on your workstation. Recently I found pyusb pretty helpful:
$ sudo apt-get install python-usb.
Here is a python script that will get you started: main.py.

The ultimate goal of our Bachelors Thesis one year ago was to deliver a “market-ready” version of our oscilloscope project where you can just install an app from the market and connect the oscilloscope over USB.

Before the “Tablet Age” our idea was to set up the OTG port of a phone for host mode. However, this requires rooting the phone as well as adding a voltage supply to the connector. Not a very elegant solution.

When the first tablets with honeycomb arrived (3.0) we managed to use the host port on a rooted device to get our oscilloscope working. Still, root was required.

With Honeycomb 3.1 it was not only possible to acquire permission of the USB device it also became possible to program USB with the Java API rather than to go native with libusb.

Therefore we have written a tablet optimized version of our oscilloscope. With the all new user interface comes the ability to connect to our USB oscilloscope. You can get the application from the Android Market with your 3.0 and up tablet. Get the source code: HoneyOsciPrime.tar.gz, or the APK HoneyOsciPrime.apk. You can always download our Layout Files here and build your own oscilloscope or contact us for support.

Acer A500 running OsciPrime

Screenshot of the new Honeycomb OsciPrime App

Scrolling long documents can be tiring for your index finger on a mouse wheel or on a touch pad. What if you could use your phones touch screen to scroll a document on your computer? While maybe not the most ergonomically solution it may well be a good example of how to work with bluetooth, uinput and Android.

Setup
Android Phone ( >= 2.1)
Ubuntu Laptop with Bluetooth
Two great Tutorials:
Bluez: http://people.csail.mit.edu/albert/bluez-intro/x604.html
uinput: http://thiemonge.org/getting-started-with-uinput

Concept
The application consists of two parts:

• A client side on the phone that serves as touch pad to scroll.
• A server part on the computer that receives commands from the phone and emulates scroll movement for uinput.

The Client is a simple Android Activity spawning a Bluetooth Thread. Touch events then result in a Bluetooth packet that tell the server if the user moved up or down. The source code is very straight forward; only Thread synchronization is a bit tricky as well as the way how the application is stopped (locks etc.).

The Server application connects the world of Bluetooth (RFCOMM/SDP) with the uinput event input system. Basically the server registers an SDP entry and then listens on an RFCOMM channel for incoming connections. As soon as a connection is established a new input device is created and scroll events are sent. Note that you probably need to be root (or use sudo) on the Linux machine to feed uinput new events.

Instructions

• Pair your Android phone with the Linux device
• Start the server on your Linux device: $ sudo ./btserver (make sure BT is turned on, else there could be a segfault -> working on that)
• Install and start the app on the phone. In the menus select your Linux device.

Building Dependencies
To build the dev-libbluetooth package was necessary on our Ubuntu machine.

The code is available under GPL. Have fun playing around with it
Note: It’s very straight forward to create a remote control for your Linux machine with the sources. Key presses can be emulated very easily with uinput.

Source Code
Android Sources
Android APK
Server code for Linux
Our App on the Android Market

Leave a comment if you like what we did or have some improvements

Without the system bar it is almost impossible to control your Honeycomb tablet. Since no hardware control buttons are enforced for the tablet the system bar is the only way to control your slate.

However, if your application incorporates a way of removing the bar and on leaving restarting the bar there is no reason why not to support such a feature.

The easy part: Restarting the bar

Restarting the bar is pretty simple, drop to a shell and start the service using the “am” command:
# am startservice -n com.android.systemui/.SystemUIService

The difficult part is to shut it permanently down. One way is to navigate to the application settings and shut it down with the “force close” button. However, attempting to kill the process with

# killall com.android.systemui

will remove the bar for a few seconds. Sadly, it will return eventually since in the applications manifest file the “persistent” parameter enforces the system to restart the service unless it is shut down properly by the “system” user itself.

The following magic line will shut down the bar permanently if executed as root:

# service call activity 79 s16 com.android.systemui

What it does is sending the Activitymanager a shutdown signal for the systemui service.
This method was tested on an Iconia A500 with Android 3.01; although it should work with other devices as well (since the source code that we use is common).

Putting it together

To remove the system bar from your application create and execute a process:

Process proc = Runtime.getRuntime().exec(new String[]{"su","-c","service call activity 79 s16 com.android.systemui"});
proc.waitFor();


To restore the system bar use the following code snippet:

Process proc = Runtime.getRuntime().exec(new String[]{"am","startservice","-n","com.android.systemui/.SystemUIService"});
proc.waitFor();