A friendly user from the tabletrepublic forum pointed out that I was using the wrong version of the google accessory API: the com.android.future.usb.accessory API is only used on pre-gingerbread versions of the OS. Anyone else should use android.hardware.usb instead.
With that fixed, the app can be loaded onto the tablet. The device correctly switches to accessory mode, and usbManager even logs that as an event in logcat. But as in my host mode attempts, mUsbManager.getAccessoryList() always returns an empty list. The intent I registered is never called either.
Still not there.
Watching logcat while the tablet is running is quite scary, btw: so many exceptions thrown and signals not caught...
Sunday, 4 March 2012
Saturday, 3 March 2012
Time for plan C?
Plan B was to run the tablet in client mode, using the Android Accessory API. As it turns out, that API is also not supported by Ainol. There is a /dev/usb_accessory, which might imply that kernel support is present. But library support isn't, when I upload some test code, I get I get requires unavailable shared library com.android.future.usb.accessory.
It also turns out that using one of the USB host shields with the Jeenode wouldn't be ideal. The reason is that the shields communicate with the host using SPI. There is a hardware SPI bus on the Jeenode, but it's already used by the radio module, and sharing is tricky. It's possible to implement SPI on some of the general purpose pins in software, but I'd rather not go that route.
So, time to rethink. What's plan C? Replace the tablet? My chances would be slightly better with an ARM based device, but it's difficult to know what APIs are implemented without testing. As it is, the Ainol Paladin is pretty awful for this purpose.
It also turns out that using one of the USB host shields with the Jeenode wouldn't be ideal. The reason is that the shields communicate with the host using SPI. There is a hardware SPI bus on the Jeenode, but it's already used by the radio module, and sharing is tricky. It's possible to implement SPI on some of the general purpose pins in software, but I'd rather not go that route.
So, time to rethink. What's plan C? Replace the tablet? My chances would be slightly better with an ARM based device, but it's difficult to know what APIs are implemented without testing. As it is, the Ainol Paladin is pretty awful for this purpose.
Thursday, 1 March 2012
USB blues
As it turns out, power is not the only problem I have with the tablet.
First, a bit about the tablet. It's an Ainol Novo Paladin - currently the cheapest tablet running ICS, with a capacitive screen, and not using a VIA CPU. It's nice enough, and after upgrading it to 4.0.3 with an unofficial build, and getting rid of all the pre-installed Chinese apps, you're left with a responsive tablet with many of the basic apps working. This includes youtube, but not for example a working BBC iplayer.
It's Achilles Heel is the processor - unlike nearly all android systems out there, it's not an ARM based processor, but a MIPS processor. While pure java apps work OK (and something I wrote for a phone in 2.2 worked immediately on the tablet, save a few scaling issues), any app that uses native compiled code won't work. And that excludes a lot of the apps on the Android market. That wouldn't be a problem, I thought, as I was going to write my own code, in java.
First I had to get a working adaptor cable. The tablet has a mini-B type OTG socket. 'Normal' USB connectors always have one type of connector for the host ('A' type, e.g. the flat one in full-sized plugs) and one for the client ('B' type, the square plug) - to make sure that it's not possible to create host-host or client-client connection. For USB OTG, the same socket on the device can be used as host or client, so the shape of the socket needs to accept plugs intended for either clients or hosts. To tell the device to switch (think of connecting two phones, one will need to become host), there must be something different in one of the two plugs. The difference is the 'X' or 'ID' pin (pin 4) - for clients, it is left floating; on the host side this pin is connected to ground. And, as I already found out, to tell the device that it is host, but allowed to charge of VBUS, that pin is connected to ground through a 124k resistor (but don't take my word on this, read the spec, and make sure your device actually implements this).
So you can't just make your own OTG cable by cutting off a connector from an old USB cable and soldering it onto another one, as the ID pin will be left unconnected. Instead, I bought a solderable Mini-USB plug (the only one I could find in the UK). But what you can't see in the photo is that the ID pin is trimmed off - instead of a solder pad, it only has a stub less than 1mm square! The nice people at hobbytronics confirmed that yes, all the plugs are like that.
But it is possible to solder a wire to it, with a bit of care (and two attempts in my case). The tablet reacts as expected - with the other end of the wire unconnected, it remains in client mode; with the wire touching ground, the tablet goes into host mode and powers the device (e.g. a keyboard works). Connected devices also show in /proc/bus/USB/devices.
That's where it stops. Unfortunately, it appears that Ainol did not bother to support Android's USB host API. When I call UsbManager.getDeviceList(), the result is always empty. I am not the only one with this problem, apparently some tablets do, some don't, implement USB host.
What alternatives are there? FTDI, the makers of the serial/USB chip on my jeenodes, actually provide a nice Android library. Looks ideal, but it uses a native library, and that's only available for ARM. Compiling an FTDI driver into the kernel won't work for a similar reason - there is no source release for ICS that works for MIPS.
It now looks as if I need to change my hardware. Either sell the tablet and find one that does support the host mode API (and runs ARM), or turn the jeenode into a USB host instead. The USB host mini shield seems the cheapest way to do that; the Arduino Mega ADK is a lot more expensive and would need an RFM12b module added. With the tablet running as client, I should be able to use the Android Accessory Protocol mode - running as client would also solve the power problem. That's assuming the AAP API is implemented, but I can (and will) test that.
First, a bit about the tablet. It's an Ainol Novo Paladin - currently the cheapest tablet running ICS, with a capacitive screen, and not using a VIA CPU. It's nice enough, and after upgrading it to 4.0.3 with an unofficial build, and getting rid of all the pre-installed Chinese apps, you're left with a responsive tablet with many of the basic apps working. This includes youtube, but not for example a working BBC iplayer.
It's Achilles Heel is the processor - unlike nearly all android systems out there, it's not an ARM based processor, but a MIPS processor. While pure java apps work OK (and something I wrote for a phone in 2.2 worked immediately on the tablet, save a few scaling issues), any app that uses native compiled code won't work. And that excludes a lot of the apps on the Android market. That wouldn't be a problem, I thought, as I was going to write my own code, in java.
First I had to get a working adaptor cable. The tablet has a mini-B type OTG socket. 'Normal' USB connectors always have one type of connector for the host ('A' type, e.g. the flat one in full-sized plugs) and one for the client ('B' type, the square plug) - to make sure that it's not possible to create host-host or client-client connection. For USB OTG, the same socket on the device can be used as host or client, so the shape of the socket needs to accept plugs intended for either clients or hosts. To tell the device to switch (think of connecting two phones, one will need to become host), there must be something different in one of the two plugs. The difference is the 'X' or 'ID' pin (pin 4) - for clients, it is left floating; on the host side this pin is connected to ground. And, as I already found out, to tell the device that it is host, but allowed to charge of VBUS, that pin is connected to ground through a 124k resistor (but don't take my word on this, read the spec, and make sure your device actually implements this).
So you can't just make your own OTG cable by cutting off a connector from an old USB cable and soldering it onto another one, as the ID pin will be left unconnected. Instead, I bought a solderable Mini-USB plug (the only one I could find in the UK). But what you can't see in the photo is that the ID pin is trimmed off - instead of a solder pad, it only has a stub less than 1mm square! The nice people at hobbytronics confirmed that yes, all the plugs are like that.
But it is possible to solder a wire to it, with a bit of care (and two attempts in my case). The tablet reacts as expected - with the other end of the wire unconnected, it remains in client mode; with the wire touching ground, the tablet goes into host mode and powers the device (e.g. a keyboard works). Connected devices also show in /proc/bus/USB/devices.
That's where it stops. Unfortunately, it appears that Ainol did not bother to support Android's USB host API. When I call UsbManager.getDeviceList(), the result is always empty. I am not the only one with this problem, apparently some tablets do, some don't, implement USB host.
What alternatives are there? FTDI, the makers of the serial/USB chip on my jeenodes, actually provide a nice Android library. Looks ideal, but it uses a native library, and that's only available for ARM. Compiling an FTDI driver into the kernel won't work for a similar reason - there is no source release for ICS that works for MIPS.
It now looks as if I need to change my hardware. Either sell the tablet and find one that does support the host mode API (and runs ARM), or turn the jeenode into a USB host instead. The USB host mini shield seems the cheapest way to do that; the Arduino Mega ADK is a lot more expensive and would need an RFM12b module added. With the tablet running as client, I should be able to use the Android Accessory Protocol mode - running as client would also solve the power problem. That's assuming the AAP API is implemented, but I can (and will) test that.
Saturday, 25 February 2012
Now we're talking
I soldered up the second jeenode today (the USB node came ready assembled), good fun, haven't done that for a while. I then compiled the RF demo from jeelabs (make sure to get the jeelib library from https://github.com/jcw/jeelib#readme, and not the RF12 and Port libraries), loaded both nodes up, et voilá, I can send packages from one to the other.
They don't work too well when close together, but I took one downstairs and the communication was very good. I will need to carefully design my protocol though, to ensure that while packets are lost, no data is lost.
They don't work too well when close together, but I took one downstairs and the communication was very good. I will need to carefully design my protocol though, to ensure that while packets are lost, no data is lost.
Friday, 24 February 2012
The first 'gotcha'
The tablet arrived, and so have the parts from jeenode!
The tablet is nice, especially after I did some updates on it - more about that some other time.
I got the arduino development tools to work, too. If you're using a jeenode USB, the instructions given on JeeNode Tips are a bit out-of-date: if you get arduino programmer is not responding errors, you need to change the device type to Uno (I think the bootloader has been updated). Then you can just take one of the example sketches, go to 'upload' - and see it working (with small changes - the 'blink' sketch assumes an LED on pin 13 - it's on pin 9 on the jeenode).
In eclipse, I went with this Arduino plugin - a fork from the official WinAVR plugin. It appears to work, though Eclipse is throwing java.lang.UnsatisfiedLinkError: no spawner in java.library.path in the path configuration - so I had to configure all the paths by hand. By default, the executables are all in /usr/bin, the header files in /usr/lib/avr/include, the IDE path is /usr/share/arduino, and I have no idea where the Atmel part description files are (or what they are, for that matter). I wonder if the problem is cause by setting the java library path in eclipse.ini for subclipse (see yesterdays post), but removing that entry doesn't seem to help.
That wasn't the 'gotcha', unfortunately. The gotcha is that the tablet only has one USB OTG mini-b socket, and no external power connection. In the OTG standard, the host device (the tablet in my setup) provides the power. When the battery is empty, I have to unplug it and charge - but that won't do if the tablet is the user interface for the whole system.
Fortunately, it looks as if there is a provision for exactly this in the USB OTG standard (thank you Wikipedia for linking to it). The USB Accessory Charger Adapter is a three-way connection between host, client, and charger. Has anyone ever come across a device actually implementing this? (don't confuse this with the USB splitter cable that's plugged into two ports on the host, to double the current). From reading the spec, since I am only interested in a single use case, it looks like a resistor in the plug at the tablet might be enough to tell it that, while it's the host, it is allowed to draw charge.
Of course, that depends on if the tablet actually implements OTG, including that part of the spec. It's not clear, as some other tablets come with a dongle that adds a second port and ethernet adapter - that would suggest it's connecting to a hub, which OTG can't do (I think?). Maybe there is another way of switching from client to host role without following the OTG standard.
I don't actually have a cable yet that goes from USB mini male to USB A female, so I can't try what happens if you plug in a hub.
The tablet is nice, especially after I did some updates on it - more about that some other time.
I got the arduino development tools to work, too. If you're using a jeenode USB, the instructions given on JeeNode Tips are a bit out-of-date: if you get arduino programmer is not responding errors, you need to change the device type to Uno (I think the bootloader has been updated). Then you can just take one of the example sketches, go to 'upload' - and see it working (with small changes - the 'blink' sketch assumes an LED on pin 13 - it's on pin 9 on the jeenode).
In eclipse, I went with this Arduino plugin - a fork from the official WinAVR plugin. It appears to work, though Eclipse is throwing java.lang.UnsatisfiedLinkError: no spawner in java.library.path in the path configuration - so I had to configure all the paths by hand. By default, the executables are all in /usr/bin, the header files in /usr/lib/avr/include, the IDE path is /usr/share/arduino, and I have no idea where the Atmel part description files are (or what they are, for that matter). I wonder if the problem is cause by setting the java library path in eclipse.ini for subclipse (see yesterdays post), but removing that entry doesn't seem to help.
That wasn't the 'gotcha', unfortunately. The gotcha is that the tablet only has one USB OTG mini-b socket, and no external power connection. In the OTG standard, the host device (the tablet in my setup) provides the power. When the battery is empty, I have to unplug it and charge - but that won't do if the tablet is the user interface for the whole system.
Fortunately, it looks as if there is a provision for exactly this in the USB OTG standard (thank you Wikipedia for linking to it). The USB Accessory Charger Adapter is a three-way connection between host, client, and charger. Has anyone ever come across a device actually implementing this? (don't confuse this with the USB splitter cable that's plugged into two ports on the host, to double the current). From reading the spec, since I am only interested in a single use case, it looks like a resistor in the plug at the tablet might be enough to tell it that, while it's the host, it is allowed to draw charge.
Of course, that depends on if the tablet actually implements OTG, including that part of the spec. It's not clear, as some other tablets come with a dongle that adds a second port and ethernet adapter - that would suggest it's connecting to a hub, which OTG can't do (I think?). Maybe there is another way of switching from client to host role without following the OTG standard.
I don't actually have a cable yet that goes from USB mini male to USB A female, so I can't try what happens if you plug in a hub.
Thursday, 23 February 2012
Eclipse with Android and Subversion
In preparation for the coding, I spent some time updating eclipse for Android and Subversion.
To get the Android eclipse development environment to work, I ended up re-installing eclipse from scratch - it told me it had conflicting requirements between ADT and java-EE, and refused to budge. I had to install the 'proper' sun jvm too, no luck with the openjdk version. After that, installing adt as described in google's page worked fine. I still had an old SDK installation, it was happy to update that to the current state (btw: there are no 'close' buttons on the eclipse android configuration pages: use 'escape' to close).
Subversion was a bit more tricky. Debian installs svnserve with the basic svn package, but no startup scripts. This page describes how to set up the '/etc/init.d/svnserve' script that starts up svn - just change the path to the location of the repository. The repository needs to be created with 'svnadmin create path/to/rep' (it creates a few files and directories at that location), and I needed to set up permissions. See Tony's helpful page for how to.
I didn't import an existing directory (as Tony does), instead I installed RapidSVN - an SVN Gui - and used that to create a new directory within the repository (modify -> make directory). This directory will be the root for all parts of this project - android and arduino based. The URN for the svnserve server, if installed on your local machine with default settings, should be svn://localhost:3690 (svnserve doesn't support http based browsing).
The subclipse plugin caused another eclipse problem. On a windows machine recently it was straighforward. On linux you have to install JavaHL individually - and while it's available as libsvn-java, neither debian nor ubuntu currently have version 1.7 of this library which is required for the 1.8 subclipse plugin. However, as this post notes, debian and other packages for javaHL 1.7 can be found at this repository. I just added
I am a bit jealous of the tortoiseSVN windows client, which is very nice, mainly for browsing and organizing the repository. I am now trying RabbitVCS, maybe that's similar (Debian is 2 versions behind though, as it is not using Nautilus 3 yet).
Update while debian's libsvn-java puts the javaHL libraries into /usr/lib/i386-linux-gnu/jni, the version from wandisco is stored at /usr/lib/jni. The correct path needs to be added to the eclipse.ini file (' -Djava.library.path=/usr/lib/jni')
To get the Android eclipse development environment to work, I ended up re-installing eclipse from scratch - it told me it had conflicting requirements between ADT and java-EE, and refused to budge. I had to install the 'proper' sun jvm too, no luck with the openjdk version. After that, installing adt as described in google's page worked fine. I still had an old SDK installation, it was happy to update that to the current state (btw: there are no 'close' buttons on the eclipse android configuration pages: use 'escape' to close).
Subversion was a bit more tricky. Debian installs svnserve with the basic svn package, but no startup scripts. This page describes how to set up the '/etc/init.d/svnserve' script that starts up svn - just change the path to the location of the repository. The repository needs to be created with 'svnadmin create path/to/rep' (it creates a few files and directories at that location), and I needed to set up permissions. See Tony's helpful page for how to.
I didn't import an existing directory (as Tony does), instead I installed RapidSVN - an SVN Gui - and used that to create a new directory within the repository (modify -> make directory). This directory will be the root for all parts of this project - android and arduino based. The URN for the svnserve server, if installed on your local machine with default settings, should be svn://localhost:3690 (svnserve doesn't support http based browsing).
The subclipse plugin caused another eclipse problem. On a windows machine recently it was straighforward. On linux you have to install JavaHL individually - and while it's available as libsvn-java, neither debian nor ubuntu currently have version 1.7 of this library which is required for the 1.8 subclipse plugin. However, as this post notes, debian and other packages for javaHL 1.7 can be found at this repository. I just added
deb http://opensource.wandisco.com/debian squeeze svn17into my /etc/apt/sources.list, added the signature to my key ring, and updated libsvn-java.
I am a bit jealous of the tortoiseSVN windows client, which is very nice, mainly for browsing and organizing the repository. I am now trying RabbitVCS, maybe that's similar (Debian is 2 versions behind though, as it is not using Nautilus 3 yet).
Update while debian's libsvn-java puts the javaHL libraries into /usr/lib/i386-linux-gnu/jni, the version from wandisco is stored at /usr/lib/jni. The correct path needs to be added to the eclipse.ini file (' -Djava.library.path=/usr/lib/jni')
Wednesday, 22 February 2012
The other kitchen node: arduino takes the tablet
The kitchen node I described in the previous post has a USB port. Why?
Because the kitchen will also house the user interface. As I mentioned before, I initially looked at the Raspberry Pi. But I wanted a nice touch screen to go with it, and they aren't cheap. And then I realized that by the time I add wifi, sound (for alarms, if nothing else), and power, I might as well get one of those cheap Chinese Android tablets. I'll save all the hassle of connecting the display and touch screen, and have a powerful environment to program the UI.
So, somewhere mounted on the kitchen cupboards, we will have a nice 7in tablet, talking to the Jeenode using USB. The one I've ordered (Ainol Paladin) is not the cheapest available, but it's the cheapest running Android 4.0 (so I can play with the newest Android version), has a capacitive screen, and it's not one of the (reportedly) underpowered VIA 8650 based systems. Apparently, the VIA chip is on its way out, to be replaced by something faster. I would have liked an Allwinner 10 based device, but they are more expensive.
There remains the question how to connect the tablet to the jeenode. One option I found is a low-level debug mode based connection as used in the IoIo. That's supposed to work on most devices, but the ioio is a bit more expensive, and since it's not actually an arduino-type node (more of a dumb direct io extension of the android device), driving an rfm12b wireless node off it is not straightforward.
The other option is based on Android's new Open Accessory Development Kit. Not all devices support this mode, and because the USB host in this case is the arduino, it needs a more powerful (and expensive) mega based node.
But don't tablets support USB host mode? After all, most of them come with external dongles with ethernet and additional USB ports? That wouldn't make sense if they only could work as USB clients.
Indeed they do, and as this great post describes, it is possible to connect Arduinos as simple serial clients. Perfect.
At least, that's the theory. The tablet will come tomorrow (and there's always a worry about quality with cheap Chinese devices), and the jeenode parts have shipped from Holland as well. We'll find out.
Because the kitchen will also house the user interface. As I mentioned before, I initially looked at the Raspberry Pi. But I wanted a nice touch screen to go with it, and they aren't cheap. And then I realized that by the time I add wifi, sound (for alarms, if nothing else), and power, I might as well get one of those cheap Chinese Android tablets. I'll save all the hassle of connecting the display and touch screen, and have a powerful environment to program the UI.
So, somewhere mounted on the kitchen cupboards, we will have a nice 7in tablet, talking to the Jeenode using USB. The one I've ordered (Ainol Paladin) is not the cheapest available, but it's the cheapest running Android 4.0 (so I can play with the newest Android version), has a capacitive screen, and it's not one of the (reportedly) underpowered VIA 8650 based systems. Apparently, the VIA chip is on its way out, to be replaced by something faster. I would have liked an Allwinner 10 based device, but they are more expensive.
There remains the question how to connect the tablet to the jeenode. One option I found is a low-level debug mode based connection as used in the IoIo. That's supposed to work on most devices, but the ioio is a bit more expensive, and since it's not actually an arduino-type node (more of a dumb direct io extension of the android device), driving an rfm12b wireless node off it is not straightforward.
The other option is based on Android's new Open Accessory Development Kit. Not all devices support this mode, and because the USB host in this case is the arduino, it needs a more powerful (and expensive) mega based node.
But don't tablets support USB host mode? After all, most of them come with external dongles with ethernet and additional USB ports? That wouldn't make sense if they only could work as USB clients.
Indeed they do, and as this great post describes, it is possible to connect Arduinos as simple serial clients. Perfect.
At least, that's the theory. The tablet will come tomorrow (and there's always a worry about quality with cheap Chinese devices), and the jeenode parts have shipped from Holland as well. We'll find out.
Subscribe to:
Posts (Atom)