How will the newly announced Android Open Accessory Development Kit (ADK) infulence this project?

[DDRBoxman]

Seeing as Google just announced what is their version of the IOIO and
integrated it into the SDK will we see the IOIO support this?

[Ytai]

Finally! I was waiting for this important discussion to come up.

A few of my thoughts:

• The ADK offers a proper protocol for sending data in and out of the device without needing the ADB hack. Certainly IOIO should support this protocol and try to establish this kind of connection before falling back to ADB. I'm guessing (though haven't checked) that this sort of connection will be more efficient in terms of throughput and latency.
• The ADK doesn't seem to provide file system access as ADB does, so for secure automatic firmware upgrades we'd still want ADB probably. The way this works is that the bootloader fetches a firmware file from the Android's filesystem from a location that is only writable by a trusted application. This way, we can assure that the firmware to install has been approved by the user. But perhaps. given that the ADK protocol is less exposed in its nature, this is not such a big concern.
• The ADK protocol is very low-level. In IOIO, most of the code is dedicated to the higher layers, which enable you to use all the cool features of the board from your Java app. Perhaps someone will implement a similar functionality for the ADK boards, but it will probably not be 100% compatible as the ATMega2560's capabilities are different than the PIC's. At present, your only way of working with ADK is to write code on both the Arduino side and the Android side and establish your own communication protocol. With IOIO, it has been done for you, and you only need the Android side.
• In terms of hardware, capabilities are similar. IOIO has more SPI and TWI (3 vs. 1). ATmega has more PWM (14 vs 9).
• ADK will only work on Android 2.3.4 and higher. IOIO works on 1.5 and higher, so can be used on your old Android devices.
• IOIO is smaller in size.
• Curiously, both are white.
• I don't know how much the ADK boards will cost, but Arduino Megas are ~$50 and host shield ~$40.
• Couldn't find much detail on the ADK board power supply, which can be a point of differentiation.
• ADK doesn't seem to be targeted at the hobbyist community as much as IOIO, so I'm not sure how much efforts will be invested in novice user support and friendliness, but that's something that might come from the community itself.

So, to summarize, I think the most attractive aspect is the standardized protocol and not necessarily the board itself. I'll definitely check how IOIO can support this mode as an underlying channel (as well as Bluetooth dongles that have been a big request and can instantly turn your IOIO connection to wireless for a $5 Bluetooth dongle).

I'm curious what other people are thinking on the subject - feel free to reply with your opinions.

[dain - Daniel Demmel]

This is an exciting development, if IOIO would support both ADK and ADB that could give it even more edge over the reference ADK board!

I think it`s so much more elegant that the IOIO code is on the Android side, I`d think a lot less communication boilerplate code will be needed this way, which I presume can be especially painful on the Arduino side if things get complicated.

I have a few questions about the board though in light of this, will it be also possible to use the it in USB accessory mode or that`d need a different USB chip?

Also somewhat along these lines, would it be possible to use the USB port of the board to charge a battery powering it? The idea isn`t primarily to use the phone to charge it, but more so to possibly have the same port for charging from a laptop / mains adaptor and later connecting to the phone, to be able to get around having to bundle an adaptor to a device built on IOIO.

I swear I read the Wiki, but couldn`t find info about these :)

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To post to this group, send email to ioio-...@googlegroups.com.
To unsubscribe from this group, send email to ioio-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ioio-users?hl=en.

[Ytai Ben-Tsvi]

On Wed, May 11, 2011 at 1:00 AM, dain - Daniel Demmel <dain...@gmail.com> wrote:

This is an exciting development, if IOIO would support both ADK and ADB that could give it even more edge over the reference ADK board!

I think it`s so much more elegant that the IOIO code is on the Android side, I`d think a lot less communication boilerplate code will be needed this way, which I presume can be especially painful on the Arduino side if things get complicated.

I have a few questions about the board though in light of this, will it be also possible to use the it in USB accessory mode or that`d need a different USB chip?

No different chip will be needed. That's only firmware work, and I think I'll give it a shot soon, as I'm really curious to figure out the new hotness's performance and get my hands dirty with these cool APIs. Just to make sure we're on the same page: "accessory mode" is when the accessory is host. If you meant the other way around, this will require using a USB device stack software rather than host, but all the higher layers of the software will remain in tact. That is, assuming that the USB cable can be used with the host on the B-side and the device on the A-side (I think it should be OK). Also, if you want to externally power the IOIO in this mode, you'll need a way to disconnect 5V from VBUS.

Also somewhat along these lines, would it be possible to use the USB port of the board to charge a battery powering it? The idea isn`t primarily to use the phone to charge it, but more so to possibly have the same port for charging from a laptop / mains adaptor and later connecting to the phone, to be able to get around having to bundle an adaptor to a device built on IOIO.

This relates to my previous answer - currently VBUS is routed to the 5V line (through a current-limiting trimmer). Assuming that you're not using the VREG, you can set the trimmer to 0 and use VBUS as 5V source.

I swear I read the Wiki, but couldn`t find info about these :)

I'm very happy to find that someone actually reads what I've worked hard on writing :)

I'll make sure to update the "Power Supply" page if/when USB device functionality is enabled.

[dain - Daniel Demmel]

On 11 May 2011, at 00:22, Ytai Ben-Tsvi wrote:

On Wed, May 11, 2011 at 1:00 AM, dain - Daniel Demmel <dain...@gmail.com> wrote:

This is an exciting development, if IOIO would support both ADK and ADB that could give it even more edge over the reference ADK board!

I think it`s so much more elegant that the IOIO code is on the Android side, I`d think a lot less communication boilerplate code will be needed this way, which I presume can be especially painful on the Arduino side if things get complicated.

I have a few questions about the board though in light of this, will it be also possible to use the it in USB accessory mode or that`d need a different USB chip?

No different chip will be needed. That's only firmware work, and I think I'll give it a shot soon, as I'm really curious to figure out the new hotness's performance and get my hands dirty with these cool APIs. Just to make sure we're on the same page: "accessory mode" is when the accessory is host. If you meant the other way around, this will require using a USB device stack software rather than host, but all the higher layers of the software will remain in tact. That is, assuming that the USB cable can be used with the host on the B-side and the device on the A-side (I think it should be OK). Also, if you want to externally power the IOIO in this mode, you'll need a way to disconnect 5V from VBUS.

What I meant is using the IOIO board as accessory from the phone`s point of view, so not as host, but device.

So essentially what you say is that it`s possible to do this with only software changes? So then maybe even the board could try to act as a device first and negotiate as a device, if that fails fall back to host mode (for older phones)?

I also think that USB cables are non-directional, doing a quick research it seems that the reason for A-B plugs is to prevent A-A loopbacks.

Also somewhat along these lines, would it be possible to use the USB port of the board to charge a battery powering it? The idea isn`t primarily to use the phone to charge it, but more so to possibly have the same port for charging from a laptop / mains adaptor and later connecting to the phone, to be able to get around having to bundle an adaptor to a device built on IOIO.

This relates to my previous answer - currently VBUS is routed to the 5V line (through a current-limiting trimmer). Assuming that you're not using the VREG, you can set the trimmer to 0 and use VBUS as 5V source.

So then this swap is only possible by physically adjusting the trimmer? Would it be possible to create a wiring so that this can be done automatically?

[John de Largentaye]

On May 10, 11:54 am, Ytai <yta...@gmail.com> wrote:
>    - I don't know how much the ADK boards will cost, but Arduino Megas are

>    ~$50 and host shield ~$40.

Ah, the rt-shop website is back online, and at [1] the ADK+ADS (sensor
board) combo is available, no way to get just the ADK. It prices
31500¥. That's about $390.

...yeah, hype lost. I'll just have to check back in a few months when
they'll sell them separately and hopefully brought the prices to
hobbyist levels.

http://www.rt-shop.sakura.ne.jp/rt-shop/index.php?main_page=product_info&products_id=2731&language=en

[Ytai]

Oh. That's a bit surprising. But I think pretty soon there will be competing implementations that would probably go down to $100 or so. Is the circuit layout publicly available?

[Annon]

Have you come across this project from Microchip:

The Microchip PIC24F Accessory Development Start Kit for Android
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2919&param=en546070

They sat they have a "Software Library for Android Accessory" for PIC24F, might be worth having a look as and when they upload the code?

For sale from 06/06/11 for ~$80, so not cheap:
http://www.microchipdirect.com/ProductSearch.aspx?Keywords=DM240415

[inopia inopia]

Here's a rant I wrote on why ADK sucks balls:
http://romfont.com/2011/05/11/a-closer-look-at-googles-open-accessory-development-kit/

Basically they totally botched their 'custom' USB protocol. Doesn't
Google have any quality control anymore these days?

[inopia inopia]

Here's my $0.02: http://romfont.com/2011/05/11/a-closer-look-at-googles-open-accessory-development-kit/

On May 10, 8:54 pm, Ytai <yta...@gmail.com> wrote:
> Finally! I was waiting for this important discussion to come up.
> A few of my thoughts:
>

>    - The ADK offers a proper protocol for sending data in and out of the

>    device without needing the ADB hack. Certainly IOIO should support this
>    protocol and try to establish this kind of connection before falling back to
>    ADB. I'm guessing (though haven't checked) that this sort of connection will
>    be more efficient in terms of throughput and latency.

>    - The ADK doesn't seem to provide file system access as ADB does, so for

>    secure automatic firmware upgrades we'd still want ADB probably. The way
>    this works is that the bootloader fetches a firmware file from the Android's
>    filesystem from a location that is only writable by a trusted application.
>    This way, we can assure that the firmware to install has been approved by
>    the user. But perhaps. given that the ADK protocol is less exposed in its
>    nature, this is not such a big concern.

>    - The ADK protocol is very low-level. In IOIO, most of the code is

>    dedicated to the higher layers, which enable you to use all the cool
>    features of the board from your Java app. Perhaps someone will implement a
>    similar functionality for the ADK boards, but it will probably not be 100%
>    compatible as the ATMega2560's capabilities are different than the PIC's. At
>    present, your only way of working with ADK is to write code on both the
>    Arduino side and the Android side and establish your own communication
>    protocol. With IOIO, it has been done for you, and you only need the Android
>    side.

>    - In terms of hardware, capabilities are similar. IOIO has more SPI and

>    TWI (3 vs. 1). ATmega has more PWM (14 vs 9).

>    - ADK will only work on Android 2.3.4 and higher. IOIO works on 1.5 and

>    higher, so can be used on your old Android devices.

>    - IOIO is smaller in size.
>    - Curiously, both are white.
>    - I don't know how much the ADK boards will cost, but Arduino Megas are

>    ~$50 and host shield ~$40.

>    - Couldn't find much detail on the ADK board power supply, which can be a
>    point of differentiation.
>    - ADK doesn't seem to be targeted at the hobbyist community as much as

[Ytai]

Very in-depth and interesting!

I had another thought about the problematic nature of the control endpoint method. Say you're requesting the Android to go into accessory mode. Say it doesn't support it. How would you know? Just wait for a few seconds for it to disconnect and reconnect and then give up? Strange indeed... Would love to hear suggestions for workarounds, as in the case of IOIO, we do have a fallback in case ADK is not supported, and we don't want to wait a few seconds before going to this fallback.

However, I do think it is worthwhile to implement IOIO on top of ADK, because it may (still needs testing) offer better throughput and latency figures.

One major drawback of ADB is that you send a message and need to wait for an ack (OKAY) before you can send the next message. This means, that if you just sent a message and want to immediately send the new one, you'll have to suffer the round-trip latency for the OKAY to come. In some cases this can take 10-20ms! I had an idea to open multiple streams and do sort of backbuffering, but it is rather complicated and perhaps ADK will solve it in a cleaner way.

[Annon]

Just got this from Microchip:

"Our Android reference code will work on any PIC platform that has USB
host capabilities. The current list of boards that are supported are
the following:
• Accessory Development Starter Kit for Android (PIC24F Version)
(DM240415)
• Explorer 16 (DM240001) with USB PICtail+ Board (AC164131) with any
of the following Processor Modules:
o PIC24FJ256GB110 PIM (MA240014)
o PIC24FJ64GB004 PIM (MA240019)
o PIC24FJ256GB210 PIM (MA240021)
o PIC32MX460F512L PIM (MA320002)
o PIC32MX795F512L PIM (MA320003)
• PIC24F Starter Kit 1 (DM240011)
• PIC32 USB Starter Kit I or II (DM320003-2)
• PIC32 Ethernet Starter Kit (DM320004)

We are finalizing the documentation and installer for the library. We
expect to be able to post all of the Android source code and
documentation near the end of this week or early next week. Please
check back at www.microchip.com/android later this week. The
schematic and layout files for the ADK for PIC24F will be released as
part of that distribution."

Looks good.

[Ytai]

I requested the library from Microchip. Apparently it is not ready yet.

So I sat to code it myself. Luckily, it is very simple, and after 3 hours I got something working! I still need to tidy it up, and add proper support on the Android-side, but good chances are that I'll submit a new version within a few days, which works on top of ADK when it is supported, and seamlessly falls back to ADB when it's not.

Hopefully that will help sort out most of the confusion people had on the differences. I'm interested in checking whether this will have a noticeable impact on latency / bandwidth.

Once this is done, I'll make sure new boards from SparkFun ship with the new firmware and existing owners will be able to upgrade their boards if they have a PIC programmer, such as PICKit3 (or a clone, such as this one, that I have good experience with).

Stay tuned!

[FastEddy]

I didn't worry about being an early adopter because "- no embedded programming or external programmer will ever be needed, even for firmware upgrades!". But now you say I need a PIC programmer?

[Annon]

It's the bootloader that will need to be upgraded to implement ADK not the firmware, hense the need for a programmer.

[Ytai]

Indeed. Sorry for the misunderstanding. Some of the lowest level functionality (e.g. USB layer) is implemented in the bootloader. The bootloader is intentionally not upgradeable without a programmer, and this is to ensure it can never be messed up.

You'd still be able to get firmware upgrades normally when they come, but for such low-level features that touch USB you'd need a programmer (or otherwise just don't take them). I'll make sure the new app firmwares will keep working on the stock bootloader.

[FastEddy]

But the PIC bootloader is firmware, though I do understand that it is lower-level - it sure ain't hardware...

[Ytai]

I take it back. I think I found a way to make that change (and future changes involving connectivity) available via the normal bootloader mechanism. And I really do want to make an effort to provide this change for existing users.

The truth is that the bootloader has been designed with the assumption that upgrades will only involve added functionality on the higher layers (e.g. adding capacitive sensing, pulse-width measurement, high-rate A/D etc.) and that connectivity to the Android will never change. I now realize this was a mistake.

But luckily, I think it would be possible to duplicate the connectivity code to the application layer and have the application establish its own connection, be it ADB, ADK or Bluetooth. It will come at the cost of having some duplicate logic in the IOIO flash, but it seems well worth the flexibility. I'm not yet 100% sure I will go down this route, need to think about it some more and make sure it is possible.

I welcome any feedback.

[FastEddy]

I'll go ahead and support HK business and postal service one more time and get me that PICkit3 you recommend anyway.
Just thought I was going to get away without buying more stuff this time (I should know better by now).

In the long run, you just need to consider the customer that have already been shipped to; it may cause as much duplication keeping these early boards compatible with future application-layer versions and it may add sections of code that give rise to questions all the time...

We'll all be best off if you come up with an elegant solution for this really cool board... even if it's a bit inconvenient for now, flexibility will get my vote.