12 replies to this topic

[Traveling Tech Guy]

Google just (I/O day 1, 5/10/11) announced the "Android Open Accessory Development Kit" (ADK for short), that will allow

external USB hardware (an Android USB accessory) to interact with an Android-powered device in a special "accessory" mode.

They are providing a software and hardware (I swear the link to the Japanese company is taken directly from Google's page ) that will use an Arduino board + shield to communicate with Android 2.3.4 and higher devices.

The myriad of possibilities of using my N+ with my phone, if possible, is staggering. This could bring a new level of network, location and sensor integration.

I have not followed on all the board's hardware requirements (voltage, connections etc.). My questions are:

• Will I be able to use the Netduino+ I have to communicate with my Android devices?
• Will the NETMF environment be agnostic enough to allow integration with the ADK?
• Will I need to buy that special Arduino shield, and will that be compatible with the Netduino?

Hoping for good news

Guy

[Fred]

I've only had a brief skim of the ADK stuff and it seems the key could be having the Netduino operating as USB host. Not possible at the moment I think, but could be soon. I'm sure Chris can give more info. Some very cool stuff coming out of I/O.

[Chris Walker]

Hi Guy, You can already use your Android, Windows Phone, iPhone, or Palm phone to control a Netduino Plus-based accessory via WiFi. Which is in many ways a much nicer solution than a USB cable. That said, we're investigating ways to support USB Host. It's an interesting thing, as it's much more complicated than USB Client (since you need support code for each device type--plus hubs, enumeration ability, etc.). And of course you'd need a shield...but possible. Especially if the shield abstracts away much of the USB Host support already. Chris

[Traveling Tech Guy]

Hi Guy,

You can already use your Android, Windows Phone, iPhone, or Palm phone to control a Netduino Plus-based accessory via WiFi. Which is in many ways a much nicer solution than a USB cable.

That said, we're investigating ways to support USB Host. It's an interesting thing, as it's much more complicated than USB Client (since you need support code for each device type--plus hubs, enumeration ability, etc.). And of course you'd need a shield...but possible. Especially if the shield abstracts away much of the USB Host support already.

Chris

Thanks Chris,
I know that I can use Android (or any other web-capable platform) to control my Netduino over wifi.
I was more interested in utilizing the phone's 3G capability to cut my wifi dependence. The ability to control the phone itself (i.e. camera, GPS etc.) would also be a great feature.

I appreciate you guys keeping on top of this and researching the USB host requirement. It may all turn out to be just the need to add a specialized shield. Although now we'll have 2 code bases to maintain: C# and Java...

[Michel Trahan]

You can already use your Windows Phone to control a Netduino Plus-based accessory via WiFi.

Can you point at code 'cause I would like to know how to do just that Please ? I know, off topic since mainly phone Wifi coding ... but a link would be very much appreciated

[davidbates]

As chris said since the shield abstract the USB host portion all you have to do is convert the libraries for data connectivity to c#.

[Chris Walker]

Hi Michel,

Can you point at code 'cause I would like to know how to do just that Please ? I know, off topic since mainly phone Wifi coding ... but a link would be very much appreciated

I was thinking "Netduino Plus connected via Ethernet to WiFi router" when I wrote that

But you can use the WiFly shield with your Netduino. The community has built support for it.

Here's an example of a project that Quiche31 made using the WiFly shield:
http://forums.netdui...y/page__p__7870

Chris

[Michel Trahan]

Thanks, I'll look into it

[greg]

Considering that there was a contest run by GHI for the Fez to build an android accessory with NETMF vs Arduino, and it was solved in 5 hours, I would say yes, there is no reason you couldn't do it. link to that discussion: http://www.tinyclr.com/forum/20/3212/ Bottom line is yes, you should be able to do it as long as you can get the USB connection - admittedly the FEZ has the advantage there since it's on the board already as a host but no reason you couldn't get it up and running. I haven't looked around but there's got to be a USB host shield somewhere.

[Chris Walker]

Both cicruits@home and SparkFun have USB Host shields. I looked at the circuits@home one and it's a SPI slave--so it's quite likely that the Arduino "USB Host" code could be ported over to NETMF. This also means you could probably do something along these lines with Netduino Mini. In fact, there's a USB Host board targeted towards that form factor as well if I remember right. Chris

[Traveling Tech Guy]

Both cicruits@home and SparkFun have USB Host shields. I looked at the circuits@home one and it's a SPI slave--so it's quite likely that the Arduino "USB Host" code could be ported over to NETMF.

This also means you could probably do something along these lines with Netduino Mini. In fact, there's a USB Host board targeted towards that form factor as well if I remember right.

Chris

Thanks Chris.
So if a USB host shield (like this one from SparkFun) solves the hardware aspect, "all" we have to do now is port the software side to NETMF? Or am I still missing something?

Guy

[Chris Walker]

So if a USB host shield (like this one from SparkFun) solves the hardware aspect, "all" we have to do now is port the software side to NETMF? Or am I still missing something?

That's pretty much it. Although USB Host is of course one of the bigger projects to tackle. The one caveat is that you might end up going with some native code interop in speed sensitive areas (but I haven't looked far enough into the SPI interface requirements of the component).

Chris

[Traveling Tech Guy]

That's pretty much it. Although USB Host is of course one of the bigger projects to tackle. The one caveat is that you might end up going with some native code interop in speed sensitive areas (but I haven't looked far enough into the SPI interface requirements of the component).

Chris

I believe that's a bit above my current level. I believe I'll take a "wait and see" approach on this