Android and libusb

Anton Lundin glance at acc.umu.se
Mon Sep 30 11:55:46 PDT 2019


On 30 September, 2019 - Dirk Hohndel wrote:

> 
> > On Sep 30, 2019, at 12:05 AM, Anton Lundin <glance at acc.umu.se> wrote:
> >> 
> >> I honestly think that this is the right approach. I started staring at the code and
> >> as expected the more I look the more I worry that I will get started and never
> >> get finished. My challenge is that I don't understand the libusb data structures.
> >> So which part of the libusb_context do I need to populate from the information 
> >> we get back from the JNI calls? That structure has quite a few members that I 
> >> have no idea what to do with. And reading the Linux code that initializes this 
> >> structure in the regular case really doesn't make me any smarter as just trying 
> >> to follow the code is making me break out in a rash...
> > 
> > 
> > Yea, its a quite complex call chain, but I thin it can be simplified to
> > filling out struct libusb_device and calling usbi_connect_device on
> > those.
> > 
> > UsbManager.getDeviceList() gives us enough to fill in the libusb_device
> > structs.
> 
> Hmm - I hadn't planned to go that route. We already have the intent handling
> that talks to us when a device is connected. And that gives us the one USB
> device that we need to talk to - so why even get that list?
> 

Its probably easier to just generate the whole list, rather than keep
some intent data around. The use might not even care about the intent,
and dismisses it, and then later starts subsurface manually, and expect
to be able to download.

> Look at the code here:
> https://github.com/Subsurface-divelog/subsurface/blob/eecca6aab0a1970c7474df7ac8408d810a5d0bbd/android-mobile/src/org/subsurfacedivelog/mobile/SubsurfaceMobileActivity.java#L90 <https://github.com/Subsurface-divelog/subsurface/blob/eecca6aab0a1970c7474df7ac8408d810a5d0bbd/android-mobile/src/org/subsurfacedivelog/mobile/SubsurfaceMobileActivity.java#L90>
> 
> So I have a UsbDevice structure already
> https://developer.android.com/reference/android/hardware/usb/UsbDevice <https://developer.android.com/reference/android/hardware/usb/UsbDevice>
> 
> But then how do I go from that to fill the libusb_device?

If you look at the UsbDevice class and the struct libusb_device, they're
quite similar, so just lift over the values.

I haven't dug down into it, but I'm guessing its actually libusb on the
other side of that UsbDevice class.
  
> >> I have a branch for this but I don't recommend that anybody hope that I'll make
> >> a lot of progress. I'm just dealing with way too many other issues that people
> >> are equally desperately hoping for me to work on (like the UI issues and crashes
> >> on Android that I think the latest beta finally addresses - which means I need to
> >> make another release...)
> > 
> > Do you have a link to that branch?
> > 
> > https://github.com/glance-/libusb/commit/50e2690f27a04011c4eae215d8b100851278e544
> > Is basically the libusb patch needed, the rest of the code needed would
> > end up in the callback subsurface would provide.
> > 
> > I had a half written variant of such code somewhere but I can't find it
> > right now.
> 
> 
> I have something slightly more hacky in my version, but yeah, same idea.
> It's that other half of the code that I'm struggling with.
> 
> I started this response email, wanting to send you a dump of what we already
> log about the new device that's connected after we get the intent, but unfortunately 
> I can't seem to revive my my last FTDI dive computer. It had been super flaky the 
> last couple of times I played with it, but I now can't turn it on anymore.
> 
> If you connect your FTDI dive computer, we are logging a string representation
> of the UsbDevice structure 
> 
> https://github.com/Subsurface-divelog/subsurface/blob/eecca6aab0a1970c7474df7ac8408d810a5d0bbd/core/android.cpp#L179 <https://github.com/Subsurface-divelog/subsurface/blob/eecca6aab0a1970c7474df7ac8408d810a5d0bbd/core/android.cpp#L179>
> 
> Do you have code that can convert that into a libusb_device structure? 
> Because if you have that code, I think I can piece the rest together. Well,
> maybe. If I had a working FTDI dive computer to test with...

I haven't gotten around to writing that yet, just planning and looking
at the java/c-code to figure out where to match them up.

> What's the cheapest FTDI dive computer one can buy these days? Or does 
> someone have one lying around that they don't need anymore? Like an old
> style Suunto with a download cable?

Just by a usb ftdi TTL adapter. It doesn't matter if there's a real DC
in the other end. Just put a peace of wire between rx and tx and phony
up a libdivecomputer backend which writes RÄKSMÖRGÅS and sees that it
got the same thing echoed back. You're able to pick up a ftdi usb board
for next to nothing at all the usual electronic supply places or any
online store.

(Well, you probably won't need to even write a libdivecomputer backend,
just abuse one and wee that the first thing it reads is actually what it
sent, and that can just be seen in the log file...)


//Anton


-- 
Anton Lundin	+46702-161604


More information about the subsurface mailing list