×
SparkFun will be closed on Tuesday, November 5th to support our team in being able to go out and vote! Orders placed after 2 pm MT Monday, November 4th will ship on Wednesday, November 6th. Thanks for your patience and understanding.
In the past few months, there has been some significant action in the Google Android open hardware movement. We are very thankful and excited to take part in all of the fun. This post will talk about the current state of the SparkFun IOIO, but more specifically how it compares and contrasts to the new Arduino based hardware Google recently released called ADK (Android Open Accessory Development Kit) and its supporting Open Accessory protocol.
The IOIO (pronounced "yo-yo") is a board specially designed to work with your Android device.
Google's ADK board released at the Google I/O 2011 developer conference.
ADB Protocol vs. Open Accessory Protocol
A few months ago, we released the IOIO board. At the time we released the IOIO, the communication link between the IOIO and Android exclusively used a protocol called the ADB (Android Debug Bridge). A couple of months later, Google released a new protocol called Open Accessory. Google's open source hardware kit (ADK) utilizes the new Open Accessory protocol. Currently, the IOIO has beta firmware supporting the Open Accessory protocol, in addition to the original ADB protocol.
What is the difference between ADB and Open Accessory? Ytai Ben-tsvi, designer of the IOIO hardware and software, has written a very good summary comparing and contrasting the ADB and Open Accessory protocols, both of which have positive and negative attributes. I encourage you all to peruse Ytai's blog post for more detailed software information.
What does all of this mean for you (the consumer)? Well, this means Google, the IOIO, and Android peripheral hardware is starting to standardize, so that a rock solid community can be developed where people can share their projects and apps. This is all great news, now all you have to decide is which hardware platform suits you best.
IOIO Hardware vs. ADK/Arduino Hardware
For most users, the hardware involved with both the IOIO and other ADK based boards accomplishes the same thing in the end. You write an app for your Android and it will control a peripheral device (motor, sensor, etc.).
The IOIO uses a high level Java API that allows you to write an app for your Android and never have to mess with embedded programming (i.e., all of the communication to and from the Android is handled behind the scenes on the PIC microcontroller). For example, to output PWM on a pin on the IOIO all you need to do within your app is create and instance of the object 'PwmOutput', then define the pin number and frequency, very simple.
The newly released Google hardware (ADK), allows you to potentially do the exact same thing. Although, it is necessary to create your own API by programming the on-board ATmega microcontroller in Arduino, in addition to writing your Java app. While this approach does give more flexibility for users wanting to create their own communication protocol (which can be difficult), the extra step of programming the microcontroller in C++ and your app in Java is somewhat cumbersome for development and testing. Once the community is set, I anticipate that higher level APIs will be written for ADK boards so that the microcontroller can be transparent, much like the IOIO.
A huge benefit to using ADK/Arduino based boards is that the hardware is based on existing Arduino boards. This means all of the shields and participating products relating to Arduino should, in theory, all work with ADK. However, the resulting ADK hardware requires the ATmega microcontroller, a USB host chip with connector, USB slave chip with connector, and a footprint to match an Arduino. These requirements add to size and cost. In addition, you may have to use two different IDEs, as well as, writing in two different programming languages: Arduino (C++) and Java.
A huge benefit to using the IOIO is that it is small, simple, and inexpensive. The IOIO only contains a single USB enabled microcontroller and a USB host connector. From its inception, there was a high level API written, and therefore the microcontroller is transparent. All you have to worry about is programming your Android app. However, the board does lack the flexibility of using existing hardware (no shields as of yet) and creating your own API by programming in Arduino. Although, if you still want to create your own API and write custom firmware for the PIC on the IOIO, there is a tool that allows you to to bundle your firmware inside the Android application. This way you can have the firmware installed automatically once connected, and will no longer need a PIC programmer.
There are some other hardware platforms out there that I have not mentioned like the Microchip Accessory Development Kit, the Arduino/USB Host shield combo, and a few others, but these are more similar to the ADK than to the IOIO in that there is not an easy to use high level API written just yet.
In Summary...
As you can tell, the IOIO and ADK are still in their infancy with much progress to be made both in hardware and software. We are only getting our feet wet at this point in time, and hope to support additional hardware in the future. If anyone has had any experience with either platform please let us know how your hacking went. We would love to get your feedback!
For more information on the IOIO, please join the discussion group.
Android operating system is one of the best operating system especially in the world of smartphones and tablets. Now a days almost every smartphone user prefer smartphone with android OS because it has computer functionality, multitasking etc. This technology is not only increases day by day but also improving its own versions like 4.4 kitkat. You can also check <a href="http://aandriodmobile.com/">Android News</a>.
You forgot to mention that ADK only works on Android 2.3.4/3.1. Even if you're running a 2.3.4 like Cyanogen, you'll need a recent kernel on (2.6.32 iirc).
If you want to use Arduino+Android and you have an earlier phone (i.e. 90% of devices currently available, including those $100 Shanzai clones) you can use MicroBridge (code.google.com/p/microbridge).
This is all nice but what I'm looking for is a device I can control with my Android from outside my home. I want to be able to turn off my heating when I forget it, maybe turn on or off some lights. See the temperature status in my home. This at least requires some TCP/IP connection, wired or wireless. It would be nice when I'm in my home to use Bluetooth or also wireless...
If the device is also programmable like the Android platform this would be perfect.
In the paragraph following "In Summary...", sentence 2 reads "getting out feet wet". I think its supposed to be "our". :)
Can we get a kit that we can start to play with NFC? even if its just a breakout for the NFC chip the nexus S uses, would love to start, just don't have enough cash to make the minimum order (2k+) for the chips from anywhere i can find them
Arduino uses the DPL (Drunk Pin Layout) so Pins are on staggered centers.
And the whole USB=/Serial fiasco.
The IOIO booard is cool; but again, what is the thinking behind grouping pins by function - instead of utility - imagine if computers made the USB data pins on one side, and the USB power pins on the other.
Er, with USB, it's one plug; with pins they're all separate. A better analogy would be a computer with USB and Serial ports on one side and Monitor and parallel ports on the other - one side for inputs, one side of outputs. I don't think it really matters too much either way.
I do like how it has multiple GND and power pins instead of just one or two.
After recovering from the $50 sticker shock, the next question was is accessing IO pins worth the extra complexity of going through Java classes, the extra delays for runtime compilation, & the extra code to get from Java to native data processing routines?
I finally went for this board rather than the ADK (for obvious reasons of availability, price, size and especially Android version compatibility) and I'm really HAPPY with my choice !
Here's my experience with it: it really does what it says on the tin and it's straight forward to use.
https://trandi.wordpress.com/2011/06/18/hello-ioio-android/
dan
can anyone buy the ADK?
ADK looks a lot like an Arduino Mega.
So we might start using these at work. I have been looking at using the Open Accessory with the IOIO, but I don't have a PIC programmer.
Didn't the description used to say "No programmer will ever be needed, even for firmware upgrades"?
It no longer mentions firmware upgrades there. Will it ever be possible to upgrade the firmware to support Open Accessory without a PIC programmer?
Alternatively, does anyone in Silicon Valley have a pic programmer that would want to help me?
Allow me to clarify a bit: the IOIO ships with a bootloader and 'stock' firmware installed. The latter can be upgraded / modified with no need for a programmer: the bootloader just pulls a new image from the phone. For that purpose, you'll need to install a dedicated app on your Android phone. This app does not exist yet on the Android market, but soon will (for free of course).
If you want to upgrade the bootloader, then a programmer is needed. As a1ronzo mentioned, the IOIO itself could function as a programmer for another IOIO, and programming would be done with this same app that's coming soon.
This is pretty much the same way as it works in Arduino, where you rarely need to upgrade the bootloader, but can do so with another Arduino when needed.
You should join the discussion group if you haven't already. I hear there might be a way to flash one IOIO with another, so you don't need a PIC programmer.
Oh good call, I'll do that, thanks!
Very cool. I designed a whole line of desktop instruments for ADB once. They were all miniaturized and set up a whole lab bench with displays arranged on your computer screen! Oh wait. You mean the Android Debug thing. Mine was Apple Desktop Bus (the other ADB standard) and then Apple changed to USB and National Instruments started selling the same stuff with a lot more capital behind it. Oh well. Thanks for the memories!
This is all well and good, but I want something like this that connects to the phone wirelessly. Say Bluetooth.
"requires the infamous ATmega microcontroller" - huh? What makes the ATMega line "infamous"? Is there some issue I haven't heard about? I think they are rather nice and use them in most of my designs.
I can't speak for a1ronzo, and it looks like the text no longer mentions "infamous", but I suspect the infamy of the ATMega 328 is not related to the microcontroller itself (which is great) or to Atmel, but to the ATMega 328 shortage that SparkFun and the rest of the world has gone through.
They're nice devices (although getting a bit long in the tooth) but in the last couple of years Atmel have dropped price increases on my company that now add up to about 500%. We were using about 300k AVR processors per year, now we don't even consider them for new designs.
I was wondering the same thing.
Microchip has kits for Apple and Android:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2919¶m=en546067
link broken "No service defined for SSGETPAGE."
I used IOIO and it's pretty easy to use, but i much prefere using the Amarino Toolkit which surprisingly wasn't even mentioned here! Amarino is much more intuitive than the ADK. I think it's going to be a lot about price point too. You can get a bluetooth shield for $20 paired with a Arduino for $30(which you probably already have). This is by far the cheapest option if you want to stick with Arduino. This price could even be slimmed down a bit more. Plus, wired connections are so outdated! Bluetooth is the future. I'm surprised that sparkfun doesn't offer a cheap bluetooth shield. Or even an integrated bluetooth Arduino board that isn't over priced by $100. What gives?
I've been using Amarino. It's awesome - ignoring the fact that its communication protocol needs an overhaul. The biggest problem (for me) with Amarino is the GPLv3 license. Also, the Amarino roadmap has no published plans to provide an embeddable API. In fact I think GPLv3 is going to make Amarino a non-starter for many paid apps.
Thanks for your feedback! The Amarino is a different beast all together (also check out cellbots). I primarily was focused on USB enabled Android boards using the ADB and/or Open Accessory protocols, not the bluetooth stack. There are some advantages to using USB over bluetooth, like lower latency and higher bandwidth. That being said, most of these platforms should support bluetooth at some point in the future.
Know what would be cool? Is if someone made so that you could control a UAV or something with your phone.
I think DIYdrones would be the people to talk to
Excellent new product! Please keep in mind though that while Java is the "preferred" development language on the Android platform C++ is fully supported via the native library dev kit (NDK). With that it is possible to maintain a fully coherent codebase with only a simple java bootstrap to launch your app.
Hi,
Why Google denies to use USB OTG, which would be the simplest way and compatible with PC to interface a variety of devices.
Why and once again why?
I would like to use an FTDI chip and a virtual COM port on Android acting as host. (Instead of PIC acting as USB host and Android acting as USB device.)
I have doubts if any of that so called standards will survive.
But still have one of the boards to play with.
Regards
Jan
Well, though that is correct, Google makes it clear that doing it that way is generally not really a good way to write an app. They suggest using the NDK for linking to processor intensive libraries or whatnot, but writing as much of the app as possible in Java. This makes it much more likely that your app will be stable, as Java can handle the garbage collection etc. If I remember correctly, the NDK is also very device dependent, where the Java stuff obviously is not.
I just feel like that should be mentioned any time someone suggests that the NDK can be used to easily port over existing C++ apps. While true, things aren't that simple.