USB Host Mode

[RFO-BASIC]

Users have requested the ability of attach to and read and write bytes to USB devices. This would be a major development effort. An effort that would require having one or more USB devices to test with.

The Android Developers guide for this feature are at: http://developer.android.com/guide/topics/connectivity/usb/host.html

[jMarcS]

I've done this in my Real Job. I want to combine it with Bluetooth - it's different because BT presents as streams and USB doesn't - but have not had time. But I could port what I have to BASIC! in a reasonable time. I have access to two tablets with both the necessary API level and USB host hardware (OTG, really). So I guess I'm a reasonable candidate. I certainly won't mind if somebody else wants to grab it.

Besides the control stack debate with Paulon0n, I have three things in the works:

1. I've fixed Der_Wurfel's socket read byte command (issue 1!), but I haven't put together a test for it.
2. After my last commit (synchronize GR.Rendering) I did a checkEOL/isNext pass on the gr commands. Trivial, but there are a lot of gr commands, so it's over 100 separate changes to test. (Code change = minutes, test = hours)
3. We're getting null pointer crashes related to Bluetooth. I think we may be trying to create the ConnectedThread twice, which may or may not be relevant. Very early stages of analysis on this one.

And as I mentioned elsewhere I'm suddenly a little short on time.

Boss, if you're feeling Bossish, what's your pleasure? Left to myself, I'd figure out the BT null pointer first, then do the USB. The other stuff will just have to live in my git stash for a few weeks.

[jMarcS]

I reread what I wrote and realized that by "devices to test with" you may have meant target devices to read/write from BASIC! I have keyboards and printers. That should be enough, but I don't have anything fun like an Arduino robot.

[RFO-BASIC]

Crashes (null pointer in BT) come first.

Is the process for reading keyboards and writing to printers the same problem and reading/writing from/to an Arduino?

Can you do USB read/write between two Android devices (like BT does)?

"I want to combine it with Bluetooth" -What does this mean?

I also have time limitations for the rest of the month. I am fixing small things and working on changing the base directory via Preferences.

[jMarcS]

Crashes first makes sense. Okay.

Is the process for reading keyboards and writing to printers the same problem and reading/writing from/to an Arduino?

There's only one way to communicate with USB devices, so yes, they're the same problem. Unless you have an Arduino that is a host and can treat an Android as a device -- then host USB becomes an Arduino programming problem. (I don't know what hardware Arduino has.)

Incidentally, I remember it coming up on the forum somewhere that you can plug a USB keyboard into some tablets. That's right: the ones that have the necessary API level (Android 3.1, API 12) and the necessary hardware (a USB OTG port, but they cheated and used a USB microB connector wired to act as a microAB, so you can't tell by looking at it). With those conditions met, the Android acts as a USB host to the keyboard's USB device.

Can you do USB read/write between two Android devices (like BT does)?

Yes, as long as either they or you can decide who plays host. With Bluetooth, both devices play both roles, with one channel each way.

Google provides an example of USB between two devices: it sets up one to monitor the LogCat of the other. Pretty cute, actually. It's at samples\android-xx\USB\AdbTest, wherever you have your android SDK installed. (xx is the SDK level, it's in everything 12 and above.) But it's way more complicated than we need, because of the ADB stuff.

"I want to combine it with Bluetooth"

I would like to abstract both so they present the same interface. That way I would only have to write one version of the printer code instead of two. A Stream is already an abstraction, but if USB was readily adaptable to streams, Google would probably have already done it.

[RFO-BASIC]

I have two USB keyboards that I use with tablets. My Nexus 7 can read/write USB flash drives with a downloaded application. I noticed that my Droid 4 has a whole bunch of entries named USB in /root/mnt/

Deciding which device will host should be no more difficult than the current decision making for who connects and who listens.

We have been in contact with one user who would be able to test your code on a non-keyboard, non-printer device. I do believe that the major application for USB in BASIC! would be people who want to converse with such devices. Converse with their very own protocol.

I think you will have an interesting challenge trying to abstract

[jMarcS]

There's only one way to communicate with USB devices

I realized after I went to bed last night that this is a gross oversimplification. Once again, my printer work has very limited requirements and I didn't look enough at the bigger picture. I use a very tight device type filter, but BASIC! will need an interface that allows users to select from available devices of different types. Also, I have gotten away with using only bulk transfers, but there are three other kinds.

This will have to be done in phases. We can start with basic support just by porting my existing work, then add features based on interest. Maybe for a first cut we can pretend it's a serial stream... :{)}

My Nexus 7 can read/write USB flash drives

Hadn't thought of flash drives - an obvious one to go for early.

... people who want to converse with such devices. Converse with their very own protocol.

Now that could be an interesting challenge!

[RFO-BASIC]

Using your own protocol is what many people do with Bluetooth devices.