@ M. K. Borri- I'd love to see an Android app that just allows simple serial terminal commands to be sent and received on the phone through the USB port.
Dr_A,
Every Android device has a USB port. This is a USB device port. When you conect it to a USB host, like your PC, the Android device can show up as a storage device. Just like a USB stick. Or it can show up as a serial port. This intended for use as a debug port when developing Android apps.
But, hey, if you have a USB host stack on your Propeller you can use it for any kind of communication between Prop and Android.
This is what Andrey is doing. Just needs a bit of an app at the Android end.
This has a lot of potential. I can't wait to have a play with it.
Search for re.serialout on the android market for serial terminal stuff it uses the headphone jack and provides a link to the schematic. Today or tomorrow I'll generate a version that works with this adb bridge. Is that acceptable?
@heater, not so simple as that. Sure there is a USB socket but hardly anything works. I tried a mouse, keyboard, USB to serial device and a USB memory stick. Of those, the keyboard and memory stick worked, and the serial device and mouse did not work.
I guess they have only coded the things people are asking for.
But if a propeller can be configured as a USB *host*, well maybe that opens up some possibilities.
The audio sounds great, but it still is only one way comms. An android can "see" (inbuilt camera) and it can "hear" (microphone), so maybe one of those could be a possibility for data into the android?
USB host on the propeller is a very interesting solution. Is this some Java code on the android side? If so, the Basic4Android people might be able to port it to Basic too.
I had a little play with this last night. From your PC you can get a command shell on your Android. Yes a command prompt from your phone.
From there you can run some commands on your phone. The built in commands are written C from the BusyBox libray.
You can add your own like something to dump the accelerometer readings or even xmodem if you like:-)
So if the Prop can get that same command line by being a USB host then it OWNs the Android.
Yay that it works for someone else!!! You can also get a direct serial-like connection by using the .java file in the last update. Terminal app for that still in the works because I had to go fix the robots after they got swamped in.
You will probably end up needing this anyway to hack on M.K.Borri's example codes for Android.
2) With that installation is included a command line program, the Android Debug Bridge (ADB). It is used by the IDE to download and debug you Android apps on real Android hardware or emulated devices.
3) Connect your Android device to your PC with a USB cable.
4) You can see if your device is recognized with the "adb devices" command which should list any attached Android devices and emulators like so:
$ adb devices
List of devices attached
90000fd745c4 device
5) You can get to the command prompt of your Android device with "adb shell" which should respond with a "$" prompt from Android. Now you can use a lot of familiar Unix commands on your Android:
6) Many of the unix like commands are actually cut down versions, built for small size, and provided by the BusyBox program. You can see what commands it has available like so:
$ busybox
BusyBox v1.16.2 (2010-06-14 22:52:00 CEST) multi-call binary.
Copyright (C) 1998-2009 Erik Andersen, Rob Landley, Denys Vlasenko
and others. Licensed under GPLv2.
See source distribution for full notice.
Usage: busybox [function] [arguments]...
or: function [arguments]...
BusyBox is a multi-call binary that combines many common Unix
utilities into a single executable. Most people will create a
link to busybox for each function they wish to use and BusyBox
will act like whatever it was invoked as.
Currently defined functions:
[, [[, acpid, addgroup, adduser, adjtimex, ar, arp, arping, ash, awk,
basename, bbconfig, beep, blkid, brctl, bunzip2, bzcat, bzip2, cal,
cat, catv, chat, chattr, chgrp, chmod, chown, chpasswd, chpst, chroot,
chrt, chvt, cksum, clear, cmp, comm, cp, cpio, crond, crontab, cryptpw,
cttyhack, cut, date, dc, dd, deallocvt, delgroup, deluser, depmod,
devmem, ......................
7) There are other commands in /sbin directory.
So as we see, if the Prop has USB host software and can get get to this ADB and provides a FullDuplexSerial like interface for Prop applications your Prop applications can run commands on the Android. Then custom commands can be made that return sensor data or GPS or display on the Android screen or connect to the net or whatever you like.
Heater- Thanks!
As far as the Java code- I would guess that goes in with your other code you are developing in the Android SDK for your app. Hopefully M. K. Borri will provide us soon with a functioning app along with its code for an example. I am as anxious as you are....
The idea for the java is to use that in your android app -- i tried to make it look like a prop object, with a .start() .stop() .rx() .tx() etc. methods.
And here it is! The apk is to be installed on android and is very basic in its behavior -- write to the Prop in the upper textbox, read from the Prop in the lower (using your favorite terminal app prop-side) and the button in the middle is to send and receive, no asynchronous message passing to avoid spamming logcat & making debugging easier. Source included (I am in the business of selling kits: the source and schematics are always free)
Question- Do I have to utilize the usb*.spin objects on my prop or can I just communicate to the prop via USB to an FTDI chip already attached? I'm confused....
Unlike an old fashioned serial link USB has a HOST end and a DEVICE endyou can't just swap them around. The HOST end drives the USB protocol, the DEVICE end just responds.
Normally we have USB HOST on a PC connected to a USB DEVICE like an FTDI serial adapter connected to a Propeller running FullDuplexSerial, say.
In which case the PC OS makes a serial port device available for you programs, /dev/ttyUSB0 on Linux for example or COM8 on Windows.
BUT here we have the reverse situation. The Prop is being the USB HOST and the Android is being a USB device.
The Android, as a USB DEVICE can present it self as a USB storage device, like a memory stick, and/or as a serial port device.
So, we need the USB HOST driver on the Prop.
At least that is my minimal understanding of proceedings so far.
What I want to know is, when I plug my Android into my PC it shows up as a USB storage device and as a modem. How can I talk to it with a terminal emulator like GtkTerm and not have to use the ADB program to get a shell?
You might be able to do it using Bluetooth. I have a setup here in the lab using Easy Bluetooth on my prop and have an app in my phone (Bluetooth Terminal Emulator Pro) whereby I can communicate back and forth with the Prop. Right now it's got a Dallas temp chip showing my temperature readings. I know you could do this with a Bluetooth dongle on your PC and using your flavor of terminal program to communicate through it.
As far as a hardwired USB to communicate I don't know if that will work.....
BTW... your explanation of the USB Host / Slave situation makes more sense to me now. Thanks for that.
Don, it has been working for a few days for me I'm trying to do away with bluetooth because of cost and because of RF noise.
Since this uses the ADB, you have to turn debugging on for the android device! (Settings > Application > Development). That gives you either a shell or a telnet socket using my apk (port 1234 by default).
Heater, thanks for explaining it better than I could have.
I think ADB is basically a loopback telnet server - it's not paired with a device, but gets a console at /dev/pts/(number). If you get a shell that way, the user is shell (instead of app_(number) like you would running a terminal emulator app).
1. Do you have to use a 6Mhz crystal or can you use a 6.25Mhz crystal and run the prop at 100Mhz instead of 96Mhz? I only see that Parallax has a 6.25Mhz cystal for sale besides the 5Mhz ones. I am guessing that it will throw the timing off but I have to ask.
2. Rather than use the usb-fs-host.spin object, why can't a person just use an FTDI USB Host adapter like the V2DIP1-32 and let the module itself do all the USB Host setup & handshaking, etc. Then just use the uart outputs to communicate with the prop via fullduplexserial.spin ? From what I am reading about this adapter is that it has programmable options as well via their IDE.
Sorry if these questions seem silly but what appears to be a simpler path to me may be all wrong.
1) I have no 6.25Mhz crystals at home, so no idea -- try it and let us know please!
2) You certainly can: I didn't because I'm trying to use as little external hardware as possible for cost and size reasons (I still have half a prop left after that, and for simple i/o that is plenty). A NASA guy asked me to make him an expansion board for an Android phone, so I gave him a G1 with a modified kernel to do serial i/o on spare pins on the ExtUSB connectors. Then he got a faster phone and I had to tell him that it didn't have a serial port on it. So now I'm doing a version that works regardless of phone model or rooted/unlocked status.
Here is a newer version that lets you run multiple shells or telnet connections on the phone at the same time (default 2, change the constant). Ths is NOT on the obex yet because I haven't changed the .apk to suit.
6.25 MHz will not work, the USB host object is hard coded for 96 MHz clock. USB runs with 12 MHz bitrate and so you get exactly 2 assembly instructions for every bit. With 6.25 MHz this timing is lost.
i updated http://obex.parallax.com/objects/724/ again, now it can do multiple shells/connections. The demo takes advantage of this in order to get a higher reliability i/o channel. Android side, I include an apk and its source.
Thanks M. K. ! Is it possible to show us a demo on Youtube of what it is you mean to do "multiple shells/connections" ? Please excuse my ignorance here but I don't understand this concept or how it works or how it would be used in an application.
Comments
Every Android device has a USB port. This is a USB device port. When you conect it to a USB host, like your PC, the Android device can show up as a storage device. Just like a USB stick. Or it can show up as a serial port. This intended for use as a debug port when developing Android apps.
But, hey, if you have a USB host stack on your Propeller you can use it for any kind of communication between Prop and Android.
This is what Andrey is doing. Just needs a bit of an app at the Android end.
This has a lot of potential. I can't wait to have a play with it.
@heater, not so simple as that. Sure there is a USB socket but hardly anything works. I tried a mouse, keyboard, USB to serial device and a USB memory stick. Of those, the keyboard and memory stick worked, and the serial device and mouse did not work.
I guess they have only coded the things people are asking for.
But if a propeller can be configured as a USB *host*, well maybe that opens up some possibilities.
The audio sounds great, but it still is only one way comms. An android can "see" (inbuilt camera) and it can "hear" (microphone), so maybe one of those could be a possibility for data into the android?
USB host on the propeller is a very interesting solution. Is this some Java code on the android side? If so, the Basic4Android people might be able to port it to Basic too.
No not so simple.
Yes, I did say USB host on the Prop.
We hava Micha Dowty to thank for the Prop USB host code.
This is going to be great.
I had a little play with this last night. From your PC you can get a command shell on your Android. Yes a command prompt from your phone.
From there you can run some commands on your phone. The built in commands are written C from the BusyBox libray.
You can add your own like something to dump the accelerometer readings or even xmodem if you like:-)
So if the Prop can get that same command line by being a USB host then it OWNs the Android.
Thanks.
Yes, sorry, I omitted a couple of major details.
Here is all I did so far:
1) Download and install the Android Software Development Kit (SDK) from here: http://developer.android.com/sdk/index.html
You will probably end up needing this anyway to hack on M.K.Borri's example codes for Android.
2) With that installation is included a command line program, the Android Debug Bridge (ADB). It is used by the IDE to download and debug you Android apps on real Android hardware or emulated devices.
You can read about the adb command here: http://developer.android.com/guide/developing/tools/adb.html
3) Connect your Android device to your PC with a USB cable.
4) You can see if your device is recognized with the "adb devices" command which should list any attached Android devices and emulators like so:
5) You can get to the command prompt of your Android device with "adb shell" which should respond with a "$" prompt from Android. Now you can use a lot of familiar Unix commands on your Android:
6) Many of the unix like commands are actually cut down versions, built for small size, and provided by the BusyBox program. You can see what commands it has available like so:
$ busybox BusyBox v1.16.2 (2010-06-14 22:52:00 CEST) multi-call binary. Copyright (C) 1998-2009 Erik Andersen, Rob Landley, Denys Vlasenko and others. Licensed under GPLv2. See source distribution for full notice. Usage: busybox [function] [arguments]... or: function [arguments]... BusyBox is a multi-call binary that combines many common Unix utilities into a single executable. Most people will create a link to busybox for each function they wish to use and BusyBox will act like whatever it was invoked as. Currently defined functions: [, [[, acpid, addgroup, adduser, adjtimex, ar, arp, arping, ash, awk, basename, bbconfig, beep, blkid, brctl, bunzip2, bzcat, bzip2, cal, cat, catv, chat, chattr, chgrp, chmod, chown, chpasswd, chpst, chroot, chrt, chvt, cksum, clear, cmp, comm, cp, cpio, crond, crontab, cryptpw, cttyhack, cut, date, dc, dd, deallocvt, delgroup, deluser, depmod, devmem, ......................7) There are other commands in /sbin directory.
So as we see, if the Prop has USB host software and can get get to this ADB and provides a FullDuplexSerial like interface for Prop applications your Prop applications can run commands on the Android. Then custom commands can be made that return sensor data or GPS or display on the Android screen or connect to the net or whatever you like.
Looks like I have to build myself a new Prop board dedicated to this with a 6MHz XTAL and USB resistors.
M.K. Borri, what do we do with the Java on the Android end?
As far as the Java code- I would guess that goes in with your other code you are developing in the Android SDK for your app. Hopefully M. K. Borri will provide us soon with a functioning app along with its code for an example. I am as anxious as you are....
If anyone can make the rx look a little better than what I did....
As for the apk, should I put it on the market or should I upload it here? what's easiest?
http://obex.parallax.com/objects/724/
The idea for the java is to use that in your android app -- i tried to make it look like a prop object, with a .start() .stop() .rx() .tx() etc. methods.
Well, I'm being presumptuous and assuming you want to open source the app.
http://obex.parallax.com/objects/724/
Unlike an old fashioned serial link USB has a HOST end and a DEVICE endyou can't just swap them around. The HOST end drives the USB protocol, the DEVICE end just responds.
Normally we have USB HOST on a PC connected to a USB DEVICE like an FTDI serial adapter connected to a Propeller running FullDuplexSerial, say.
In which case the PC OS makes a serial port device available for you programs, /dev/ttyUSB0 on Linux for example or COM8 on Windows.
BUT here we have the reverse situation. The Prop is being the USB HOST and the Android is being a USB device.
The Android, as a USB DEVICE can present it self as a USB storage device, like a memory stick, and/or as a serial port device.
So, we need the USB HOST driver on the Prop.
At least that is my minimal understanding of proceedings so far.
What I want to know is, when I plug my Android into my PC it shows up as a USB storage device and as a modem. How can I talk to it with a terminal emulator like GtkTerm and not have to use the ADB program to get a shell?
As far as a hardwired USB to communicate I don't know if that will work.....
BTW... your explanation of the USB Host / Slave situation makes more sense to me now. Thanks for that.
Since this uses the ADB, you have to turn debugging on for the android device! (Settings > Application > Development). That gives you either a shell or a telnet socket using my apk (port 1234 by default).
Heater, thanks for explaining it better than I could have.
What I meant was how can I talk to my phone, as if over a serial port, when connected to my PC and debugging is enabled on the phone?
Turns out that it shows up as /dev/ttyACM0 which is a USB modem device. Opening a terminal emulator I can talk to it with AT commands at least.
It's not clear how ADB gets to a shell on the phone. Does it adb start a ppp session with my phone or what?
Managed to build PropDemo.apk and get it installed and running on the phone.
Now I need a 6MHz Prop board...
1. Do you have to use a 6Mhz crystal or can you use a 6.25Mhz crystal and run the prop at 100Mhz instead of 96Mhz? I only see that Parallax has a 6.25Mhz cystal for sale besides the 5Mhz ones. I am guessing that it will throw the timing off but I have to ask.
2. Rather than use the usb-fs-host.spin object, why can't a person just use an FTDI USB Host adapter like the V2DIP1-32 and let the module itself do all the USB Host setup & handshaking, etc. Then just use the uart outputs to communicate with the prop via fullduplexserial.spin ? From what I am reading about this adapter is that it has programmable options as well via their IDE.
Sorry if these questions seem silly but what appears to be a simpler path to me may be all wrong.
Thanks.
Don
2) You certainly can: I didn't because I'm trying to use as little external hardware as possible for cost and size reasons (I still have half a prop left after that, and for simple i/o that is plenty). A NASA guy asked me to make him an expansion board for an Android phone, so I gave him a G1 with a modified kernel to do serial i/o on spare pins on the ExtUSB connectors. Then he got a faster phone and I had to tell him that it didn't have a serial port on it. So now I'm doing a version that works regardless of phone model or rooted/unlocked status.
Here is a newer version that lets you run multiple shells or telnet connections on the phone at the same time (default 2, change the constant). Ths is NOT on the obex yet because I haven't changed the .apk to suit.
Thanks for this update. I look forward to your update to the app too.
Andy
i updated http://obex.parallax.com/objects/724/ again, now it can do multiple shells/connections. The demo takes advantage of this in order to get a higher reliability i/o channel. Android side, I include an apk and its source.