The Abstraction Layer
Once the prototype works and could establish a great communication between the Xoom and the FT232 IC, I decided to separate the project in order to let anyone creates a VCP Driver adding just a few methods.
The Abstraction Layer is present in the USB VCP Library for Android. It consists of 5 classes as you can see in the following picture:
It is the main class. It represents the driver which lets the user connect and disconnect from the device. It also handles the low level connection and disconnection from the USB Device, and provides 5 abstract methods.
The user should call “connect” with a valid RS232 Configuration and a (may be null) object that implements the Async. Receveiver Interface. The “disconnect” method should be used in order to de-initialize variables but must call VCPDriver.closeDevice() in order to release all the USB stack.
“transfer” is a generic method that lets the user do synchronised transactions. The user can call this method in order to send and/or receive a package from the device.
“initialize” should be called from “connect” and will perform several controlTransfer commands in order to setup the device (including the RS232 configuration).
Finally, the AsyncReceiver is an interface with a very simple method. If your class implements this interface, you will receive async information from the driver.
As the VCPDriver has some abstract methods, all the class is abstract. So for every IC manufacturer, you should create a specialised Driver class, as I have created the FT232Driver class.
In the long way that my project must walk, I decided to start testing some small things in order to understand how the Android USB Host API and Open Accessory API (two different things) work.
Basically the USB Host API lets your Android device acts as a computer. With this API you can connect from a Bluetooth USB adapter to any standard USB device that you can find in a store. The Open Accessory API works the other way, your Android acts as a device, so you have to connect a USB Host controller in the other side. I don’t find this second approach very useful. First because not all the microcontrollers in the world support USB Host (Remember, your Android is a Device for the Open Accessory API) Second because it does not allow seemless development of a product using a computer and a natural port to Android using the USB Host API. I still cannot find three nice examples of when I will prefer to use my Tablet as a USB Device, but I can find millions of application for my Tablet (and Phone) to be a USB Host.
So in this short post, I will show you how it a USB Device attached to a Honeycomb-enabled device looks like. Take special attention to the fact that even though Android 2.x has an option USB toolkit, and the classes have the same name, they belong to a different package (so the imports are not the same).
The Motorola Xoom with Android 3.2 is USB Host capable, and even thought I connected a USB keyboard and it didn’t work in the OS, the following short example demonstrates that the Motorola Xoom detects a USB Bluetooth adapter.
When attaching the USB Bluetooth adapter the following message can be seen using “logcat” (connected via TCP as the USB port is busy with the adapter)