Android Open Accessory for LUFA?
Brian Dickman
the Android Open Accessory specs? It's really just a custom USB host
controller, and the protocol looks simple. I'd love to see this
implemented as a LUFA host mode demo. The Google Accessory Development
Kit (ADK) uses an atmega running Arduino connected to a discrete host
controller, but it's very practical to roll the whole device into a
single usb-host-enabled atmega. Any takers?
http://developer.android.com/guide/topics/usb/adk.html
--
Brian
G Bulmer
http://developer.android.com/guide/topics/usb/host.html
which says that from Android 3.1 the "Android-powered-device" supports
being a USB host.
So, it is less clear to me; it looks like the need for a custom USB-
host controller will reduce from here on, but I may be optimistic :-)
Casainho
> I was very interested in this until I noticed:
> http://developer.android.com/guide/topics/usb/host.html
> which says that from Android 3.1 the "Android-powered-device" supports
> being a USB host.
> So, it is less clear to me; it looks like the need for a custom USB-
> host controller will reduce from here on, but I may be optimistic :-)
Forget the ARM port of LUFA? most the cheap ARM microcontrollers have
USB host. Microcontrollers with USB host are cheap nowadays.
G Bulmer
USB accessory:
1. USB host controller
2. 5V 0.5A power supply
3. interface electronics to control Android phone or allow the Android
USB accessory to become a USB device so that it can be programmed
4. USB host controller software
5. Android-powered-device+USB-accessory application
I think 1 is the easiest part.
I think it would be easier to instead build a dumb USB device and use
the Android-powered device to be the USB host running the application
with the microcontroller as a 'slave'.
On May 11, 11:40 pm, Casainho <casai...@gmail.com> wrote:
> 2011/5/11 G Bulmer <gbul...@gmail.com>:
Dean Camera
and partly due to my hatred of typing on a touchscreen) so I can't
test this out myself, but there's no reason it can't be done with LUFA
from what I can see, with either an AVR32 or AT90USB1287 or AT90USB647
acting in USB host mode. The USBKEY should in theory be able to supply
enough current (actually I'm not certain about this - the VBUS
regulator can handle it, but I'm not sure the primary regulator will
take the strain) to power and charge the device.
- Dean
Brian Dickman
> ...
> I think it would be easier to instead build a dumb USB device and use
> the Android-powered device to be the USB host running the application
> with the microcontroller as a 'slave'.
That would be easier from the accessory's perspective, but it's harder
for the phone manufacturer. Especially for the phones already released
with no host controller! This way the phone only needs to support
device mode, and switch out its VID/PID. Existing phones can run the
new controller code and get accessory support. All the actual
accessory protocol is done over basic USB bulk endpoints and the phone
is really the one in charge, despite the backwards host/device
relationship.
I think either AVR or ARM are good candidates for a single-chip
accessory solution, but I don't have an Android device either.
From the other direction, it would also be an interesting project to
write a LUFA "Android device" as a stand-in for the phone. Talk to it
via UART (PC->USB serial->UART->LUFA device), and it could speak Open
Accessory to the accessory host controller. All sorts of
possibilities.
--
Brian
Casainho
> I don't have an Android phone (I'm a holdout party due to the expense,
> and partly due to my hatred of typing on a touchscreen)
Thanks to success of Android, here in Portugal I can by a very
expensive or very cheap model. I bought a cheaper one of 130€ but the
cheaper on the market was 99€!
The new models have dual core ARM, 1GB RAM, etc. We can use bluetooh
keyboard and mouse and there is a technology already on some TVs and
Android to send the video and audio wireless!! I bet this devices will
be soon our portable computers, where we can type on their small
screens while on travel and use larger external screens and keyboard
and mouse, all wireless!
There are already in the market netbook "shells" where we can connect
an Android phone and we end with a working netbook.
There are even wireless power chargers fir this kind of devices :-)
Android/smart phones are the future of computers, mainly because of
being portable and so every user will buy one and also because of
business models of apps.
G Bulmer
On May 12, 7:56 am, Casainho <casai...@gmail.com> wrote:
> 2011/5/12 Dean Camera <abcminiu...@gmail.com>:
> > I don't have an Android phone (I'm a holdout party due to the expense,
> > and partly due to my hatred of typing on a touchscreen)
>
> Thanks to success of Android, here in Portugal I can by a very
> expensive or very cheap model. I bought a cheaper one of 130€ but the
> cheaper on the market was 99€!
>
> The new models have dual core ARM, 1GB RAM, etc.
trivial addition.
Some of the existing phones already have it:
http://adq.livejournal.com/95689.html
http://www.androidcentral.com/usb-host-motorola-droid-droid-does
also Windows Mobile: http://www.wpcentral.com/treo-800w-usb-host-port-works
> We can use bluetooh
> keyboard and mouse and there is a technology already on some TVs and
> Android to send the video and audio wireless!! I bet this devices will
> be soon our portable computers, where we can type on their small
> screens while on travel and use larger external screens and keyboard
> and mouse, all wireless!
sophisticated too.
I agree.
That is why the Android phone will carry a USB host controller.
I looked at the stats for the market, e.g.
http://www.prnewswire.com/news-releases/comscore-reports-march-2011-us-mobile-subscriber-market-share-121396514.html
It says for the three month average ending March 2011 there were 234
million mobile phone users in the USA
Of that same period 72.5 million owned smart phones, an increase of 15
percent over the previous quarter, or 10.9 million smart phones sold
in a quarter
Google android accounted for 34.7%, the largest market share in the
USA for any smart phone provider (RIM 27.1%, Apple 25.5%, 12.7% the
rest)
The current user base of smart phone users is modest compared to the
number of users of mobile phones.
I believe smart phone users changes phone every few of years.
Based on a quick google, it looks like the hardware spec for some
phones already includes the USB host hardware, it is built into the
chip. It is waiting for the software.
So, I think there are an awful lot of new smart phones to be designed
and sold.
G Bulmer
On May 12, 4:23 am, Brian Dickman <brian.dick...@gmail.com> wrote:
> > ...
> > I think it would be easier to instead build a dumb USB device and use
> > the Android-powered device to be the USB host running the application
> > with the microcontroller as a 'slave'.
>
> That would be easier from the accessory's perspective, but it's harder
> for the phone manufacturer.
Some chipsets already have USB host controllers, and some do not.
For the chipsets without USB host controllers, it will not happen,
they won't get USB host controllers.
> Especially for the phones already released
> with no host controller!
don't appear to have a host controller might have one because the chip
set had it built in.
> This way the phone only needs to support
> device mode, and switch out its VID/PID. Existing phones can run the
> new controller code and get accessory support. All the actual
> accessory protocol is done over basic USB bulk endpoints and the phone
> is really the one in charge, despite the backwards host/device
> relationship.
>
> I think either AVR or ARM are good candidates for a single-chip
> accessory solution, but I don't have an Android device either.
The number of users already with Android phones will become the
minority of Android owners in a few quarters time.
So when you get around to getting an Android device (or any smart
phone) get one with a USB host controller.
>
> From the other direction, it would also be an interesting project to
> write a LUFA "Android device" as a stand-in for the phone. Talk to it
> via UART (PC->USB serial->UART->LUFA device), and it could speak Open
> Accessory to the accessory host controller. All sorts of
> possibilities.
I'd thought it'd be much nicer to be: PC... USB Serial ... -> LUFA
device with two USB's -> Android accessory
Which might be two LUFA devices with one USB tied 'back to back' e.g.
with SPI
G Bulmer
On May 12, 9:38 am, G Bulmer <gbul...@gmail.com> wrote:
> On May 12, 7:56 am, Casainho <casai...@gmail.com> wrote:> 2011/5/12 Dean Camera <abcminiu...@gmail.com>:
> It says for the three month average ending March 2011 there were 234
> million mobile phone users in the USA
> Of that same period 72.5 million owned smart phones, an increase of 15
> percent over the previous quarter, or 10.9 million smart phones sold
> in a quarter
1. The number grew by 15% to reach 72.5 million, so it was about
63million, a growth of about 9.5million
2. the survey yields the numbers of smart phone users, and not phones
sold
Sorry folks
Donald Delmar Davis
it would take to get an Android Open Accessory project into LUFA. It
seems that this conversation would be better if we looked at the
protocol used and how to implement it.
I think its nice that android actually opened this up to developers and
it seems like a good candidate for deans host side work.
Don.
Casainho
> This is all very interesting but it would be nice if we got back to what
> it would take to get an Android Open Accessory project into LUFA. It
> seems that this conversation would be better if we looked at the
> protocol used and how to implement it.
As user, I do not want to use wires with my Android phone, I expect
all to be wireless. I think USB wired connection will be useless in
near future and the Wireless USB or something other alike will be the
"thing".
Android have a very good support of bluetooth and wifi. For point to
point connections to hardware, I believe bluetooth is the best choice.
LUFA already have some experimental code for bluetooth...
For example, there is already a good project that provides Arduino +
Bluetooth + Android API, for controlling all kind of devices:
http://www.amarino-toolkit.net/
Dean Camera
out:
https://code.google.com/p/lufa-lib/source/browse/trunk#trunk%2FDemos%2FHost%2FIncomplete%2FAndroidAccessoryHost
It should connect to the device, correctly switch it into accessory
mode, then stream out bytes sent to the LEDs on the board. If this
works at all, I'll make a proper class driver for it, and add in all
the missing features.
- Dean
On May 13, 1:39 am, Donald Delmar Davis <ddelmarda...@gmail.com>
wrote:
dandumit
I have managed to get a phone that has Android 2.2 and I would like to
make this test.
But recently I have seen that it's needed at least Android 2.3.4 or
upper 3.1.
Did someone else tried your version ? Anyway I will try to compile
the library and I will let you know.
Kind Regards,
Daniel
On May 13, 3:19 am, Dean Camera <abcminiu...@gmail.com> wrote:
> It's very rough, but if anyone with anAndroidphone could try this
> out:
>
> https://code.google.com/p/lufa-lib/source/browse/trunk#trunk%2FDemos%...
Dean Camera
No, no testers that I know of yet sadly. If you do happen to upgrade,
let me know how it goes!
- Dean
pic.micro23
Dean Camera
the demo - a logic error in the Device Descriptor parsing code
(DeviceDescriptor.c) was causing the application to think that the
Android device was never in Accessory mode. That should be all fixed
now in the latest SVN/GIT.
If we can get a properly debugged version of this going, I can create
up a proper class driver for it inside the library code for the next
release.
Cheers!
- Dean
Inopia
for those who don't have an Android 2.3.4 phone, you can use the ADB
protocol instead of ADK. Both IOIO and MicroBridge (code.google.com/p/
microbridge) use it and it works fine on Android 1.6 and upwards. I'm
planning on porting microbridge to LUFA, but unfortunately I don't
have hardware to work with right now.
I'll post updates as soon as I get my hands on a board.
- Niels
dandumit
@Niels - thank you for info. However ADK seems to be more appropriate
for connecting to external devices.
@ pic.micro23 : would you please give some more details about your
test ? for example from where did you get the Micropendus board, what
connection did you used ?
Kind Regards,
Daniel
pic.micro23
I took your latest code and try it quickly. I will add more debug info
to get more details....
**************** log from
running.
Getting Device Data.
Android Device Detected - Non-Accessory
mode.
Device Unattached.
Getting Device Data.
Android Device Detected - Non-Accessory mode.
Device Unattached.
Getting Device Data.
Android Device Detected - Non-Accessory mode.
Device Unattached.
Dev Enum Error
-- Error Code 2
-- Sub Error Code 0
-- In State 5
Device Unattached.
**********************************
Dean Camera
not entering Accessory mode correctly -- perhaps if you could make it
print out the device's exact detected PID I can diagnose what is going
wrong. It is doing the correct system reboot in response to the
special command I send it, so that appears to be functioning
correctly, the device just isn't entering the desired mode upon
reboot.
Perhaps the documentation is a little wonky, as I used that as a
reference over the Arduino code they put out. I'll dig through the
supplied code and see if there's a difference between what I'm doing
and what the (allegedly) working official code does.
Thanks for testing!
- Dean
Dean Camera
aren't optional as I thought. I've updated the demo in /trunk/ to
include support for correctly querying (and checking) the device's
reported Accessory Mode protocol verion, and sending of some default
device information strings. Hopefully this time it'll work.
Cheers!
- Dean
pic.micro23
uint8_t ProcessDeviceDescriptor(void)
{
USB_Descriptor_Device_t DeviceDescriptor;
/* Send the request to retrieve the device descriptor */
if (USB_Host_GetDeviceDescriptor(&DeviceDescriptor) != HOST_SENDCONTROL_Successful)
{
//printf_P(PSTR("\r\nProcDevDsc #1 DevControlError : %d\r\n"), DevControlError);
return DevControlError;
}
/* Validate returned data - ensure the returned data is a device descriptor */
printf_P(PSTR("\r\nProcDevDsc #2 Header.Type: %d\r\n"), DeviceDescriptor.Header.Type);
if (DeviceDescriptor.Header.Type != DTYPE_Device)
return InvalidDeviceDataReturned;
/* Validate returned device Class, SubClass and Protocol values against the Bluetooth spec values */
printf_P(PSTR("\r\nProcDevDsc #3 VendorID: %d\r\n"), DeviceDescriptor.VendorID);
if (DeviceDescriptor.VendorID != ANDROID_VENDOR_ID)
return IncorrectAndroidDevice;
/* Check the product ID to determine if the Android device is in accessory mode */
printf_P(PSTR("\r\nProcDevDsc #4 ProductID: %d\r\n"), DeviceDescriptor.ProductID);
if ((DeviceDescriptor.ProductID != ANDROID_ACCESSORY_PRODUCT_ID) &&
(DeviceDescriptor.ProductID != ANDROID_ACCESSORY_ADB_PRODUCT_ID))
{
return NonAccessoryModeAndroidDevice;
}
return AccessoryModeAndroidDevice;
}
Dean Camera
Looks like it is indeed dependant on the exact procedure in the ADK
documentation - i.e. you are *required* to send the strings to the
host before trying to switch to Accessory Mode. Looking at that log it
looks like the reboots are being processed still, but we're still not
getting into the right mode.
Since the strings are important, perhaps it's baked into the Android
app to only work if a known set of strings are applied. Can you use
these strings please?
AndroidAccessory acc("Google, Inc.",
"DemoKit",
"DemoKit Arduino Board",
"1.0",
"http://www.android.com",
"0000000012345678");
That's from the official ADK documentation, which means that the
Android device shouldn't be able to tell the difference between my
code and the existing real Accessory Mode code running on your
dedicated host shield. If that still doesn't work, then I'm going to
have to tear some more hair out and see what could be going wrong.
Cheers!
- Dean
Jake Anderson
tablets ;->
dandumit
working ?
@Jake - I agree with demo handset/tablet for DEan, however I do have
an issue with those cheap chinese products. Basically some of them
should have support for USB host , so it wouldn't be needed ADK. On
the other hand until this protocol isn't "adopted"/certified by Google
it wouldn't be the smartest way to invest time...
Opendous Support
AndroidAccessoryHost and successful ADK communication.
LUFA completely resets and drops off the USB Bus after telling
Android to switch to Accessory Mode whereas successful communication
just requires a delay between the Accessory Mode command and
subsequent communication.
http://developer.android.com/guide/topics/usb/adk.html#accessory-protocol
Once an ADK device has "Attached" to LUFA it should not "Unattach"
until it is physically unattached. In its current state
AndroidAccessoryHost needs to re-enumerate after the Accessory Mode
call. Dropping off the bus causes Android to reset its USB interface
from Accessory Mode.
I have included Nexus-Computing GmbH's USBTest and simplectrl.c which
allows Linux to act as a USB Accessory and demonstrates successful
communication.
http://android.serverbox.ch/?p=262
== Unsuccessful Communication between Nexus S and LUFA:
D/Tethering( 110): interfaceAdded :usb0
D/Vold ( 71): usb_mass_storage function disabled
D/UsbService( 110): entering USB accessory mode: UsbAccessory...
I/ActivityManager( 110): Starting: Intent { flg=0x10000000...
W/Vold ( 71): Ignoring unknown switch 'usb_connected'
I/ActivityManager( 110): Displayed com.android.systemui/.usb...
D/UsbService( 110): exited USB accessory mode
== Successful Communication between Nexus S and Linux (simplectrl.c):
D/Vold ( 71): USB disconnected
D/UsbService( 110): entering USB accessory mode: UsbAccessory...
I/ActivityManager( 110): Starting: Intent { flg=0x10000000...
W/Vold ( 71): Ignoring unknown switch 'usb_connected'
I/ActivityManager( 110): Displayed com.android.systemui/.usb...
E/Tethering( 110): active iface (usb0) reported as added, ignoring
D/Vold ( 71): USB connected
E/Tethering( 110): active iface (usb0) reported as added, ignoring
== Successful communication sequence (simplectrl.c) between Nexus S and Linux:
libusb_init(NULL);
handle = libusb_open_device_with_vid_pid(NULL, VID, PID)
libusb_claim_interface(handle, 0);
response = libusb_control_transfer(
handle, //handle
0xC0, //bmRequestType
51, //bRequest
0, //wValue
0, //wIndex
ioBuffer, //for data returned from Android device
2, //wLength
0 //timeout);
usleep(1000);
response = libusb_control_transfer(handle,0x40,52,0,0,(char*)manufacturer,strlen(manufacturer),0);
response = libusb_control_transfer(handle,0x40,52,0,1,(char*)modelName,strlen(modelName)+1,0);
response = libusb_control_transfer(handle,0x40,52,0,2,(char*)description,strlen(description)+1,0);
response = libusb_control_transfer(handle,0x40,52,0,3,(char*)version,strlen(version)+1,0);
response = libusb_control_transfer(handle,0x40,52,0,4,(char*)uri,strlen(uri)+1,0);
response = libusb_control_transfer(handle,0x40,52,0,5,(char*)serialNumber,strlen(serialNumber)+1,0);
libusb_control_transfer(handle,0x40,53,0,0,NULL,0,0); // accessory mode
//attempt to connect to new (Accessory Mode) PID
for(;;){
tries--;
if((handle=libusb_open_device_with_vid_pid(NULL,VID,ACCESSORY_PID))==NULL){
if(tries < 0) {
return -1;
}
}else{
break;
}
sleep(1);
}
libusb_claim_interface(handle, 0);
// first actual data transfer from device:
response = libusb_bulk_transfer(handle, IN, buffer, 8, &transferred, 0);
Opendous Support
drops off the bus and needs to be re-enumerated. LUFA is resetting at
the same time. Could the problem be a timing issue where LUFA is not
available for hosting just as Android enters Accessory mode? Is it
possible to reset the AT90USB1287 USB interface without disconnecting
the USB Bus?
For viewing you can open the included Nexus S to Linux
(simplectrl.c) libpcap capture session with Wireshark
(http://www.wireshark.org/).
pic.micro23
Opendous Support
device to settle before re-enumerating which Android was interpreting
as a dropped connection. LUFA has been updated with a fix:
http://code.google.com/p/lufa-lib/source/detail?r=1902
I am currently working on getting usbmon into Android to enable
further debugging and testing.
> --
> You received this message because you are subscribed to the Google Groups
> "LUFA Library Support List" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/lufa-support/-/FGbkr2EkKzYJ.
> To post to this group, send email to lufa-s...@googlegroups.com.
> To unsubscribe from this group, send email to
> lufa-support...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/lufa-support?hl=en.
>
Opendous Support
Android DemoKit App.
Not much needed to be changed from the stock demo:
http://code.google.com/p/micropendous/source/browse/trunk/Micropendous/Firmware/AndroidAccessoryHost/AndroidAccessoryHost.c#68
http://code.google.com/p/micropendous/source/browse/trunk/Micropendous/Firmware/AndroidAccessoryHost/AndroidAccessoryHost.c#244
A quick video showcase:
http://www.youtube.com/watch?v=mtR_U0-gC1A
The firmware:
http://code.google.com/p/micropendous/downloads/detail?name=Micropendous-2011-11-26.zip
The DemoKit App:
https://dl-ssl.google.com/android/adk/adk_release_0512.zip
http://developer.android.com/guide/topics/usb/adk.html#running-demokit
http://micropendous.googlecode.com/svn/trunk/Micropendous/Firmware/AndroidAccessoryHost/AndroidDeviceSoftware/DemoKIT.apk