On 01 March, 2020 - Dirk Hohndel wrote: > > > On Mar 1, 2020, at 10:32 AM, Christof Arnosti <[email protected]> wrote: > > > > Soo... I own a Mares Puck Pro, and I want to use Subsurface Mobile to > > transfer dives from the computer. > > > > I found that currently for android a libftdi / libusb-based driver > > (serial_ftdi.{c,h}) is available for FTDI based serial converters. > > And by 'available' we mean: > > IT DOESN'T WORK ON BASICALLY ANY ANDROID DEVICE > > This works on some old Android devices. And it can be hacked to work > on rooted Android devices. But for 90+% of our users this doesn't work > at all. As you point out below, we have made attempts to fix this and > admittedly I have spent way too much time on that already... there's even > a PR on GitHub where I try to make this work but I got stuck... > > > The Mares USB cable uses a cp210x based converter. > > > > In the FAQ at subsurface-divelog.org I found the following paragraph: > > > > "Subsurface-mobile on Android and dive computers with FTDI download cables > > > > Subsurface-mobile on Android (but not on iOS beacuse of hardware > > limitations) is designed to be able to download from some dive computers > > using FTDI based download cables and a USB OTG adapter. Unfortunately, > > there is an issue with the way in which Subsurface-mobile opens USB > > devices on Android. We do this from “native code”, not from a Java > > application. And while many Android phones allow this method of > > accessing OTG devices, an (apparently increasing) number of devices > > don’t. On these Android devices the attempt to download from > > divecomputers via the USB OTG adapter always fails. We understand in > > theory how to work around this problem, but haven’t found the right > > developer who could volunteer their time to help us fix the issue." > > I need to update the FAQ. Initially it was indeed "some" where it failed. > Now it is basically "all". > > > Well... Maybe I want to be this person, and for sure I want to be the > > person to add cp210x support. I would be glad if somebody could explain > > what the proposed workaround mentioned in the paragraph would be? > > Paging Anton - but I know that he has explained it on this mailing list a > few times in the past, so googling for posts from him with Android in the > title might get you to the right one. > > > While recherching I found the git repo > > https://github.com/mik3y/usb-serial-for-android containing a collection > > of USB serial converter drivers for android. The drivers are licensed as > > LGPL2.1 (GPL compatible) and are written in Java using the Android USB > > Host API. > > > > From the code that I have read I have two possible ways to go forward: > > > > First (my preferred way): > > Directly use the java code from usb-serial-for-android, write a small > > abstraction class in java to provide a convenient interface, and a small > > class in c to call the java abstraction class (similar to what > > serial_ftdi does with libftdi). > > > > Pros: > > - This could act as a generic way to access USB serial-based > > divecomputers, including FTDI ones. > > - Using the official Android USB Host API means that the chance for > > support on different phones is quite high. > > > > Cons: > > - More Platform-Specific, non-C code. > > > > Second: > > Translate the CP210x driver from usb-serial-for-android to C code using > > libusb. > > > > Pros: > > - C-Code > > > > Cons: > > - More work > > - Chipset-Specific > > > > What do you think about this two possibilities? I would prefer to > > directly use usb-serial-for-android, since for the desktop application > > there is already existing support for the different USB-Serial chipsets, > > so portability of the code for non-android builds is not that important > > in my eyes. With this subsurface would also only need one > > android-specific driver implementation for different chipsets. > > > > I would love to hear your toughts and maybe get some additional pointers > > I could use while developing. I would mainly work on the task in the > > next week, since I have holidays and the event I wanted to go to was > > canceled due to the corona virus. > > Since Anton knows more about this than anyone else on this list (or at > least I think so), I really hope that tagging him directly on the To: line > will > help to catch his attention. It seems much more useful to have him respond... > > Thanks for looking into this. It would be amazing to see this fixed. I had > basically given up hope...
There's bit quite a bit written during the years about this. It can all be found in the archives. usb-serial-for-android is one solution. It's a bit harder to test, because it's can't be tested outside of android but it supports a bunch of different devices and it only uses official api's. I haven't seen any libusb (or similar abstractions) based cp210x userspace drivers. Sure, the code can be written, but I think its way too much work to be worth the effort. I'd suggest you look into writing a custom-serial glue-layer which uses jni to call into usb-serial-for-android. I'd suggest looking at the QtAndroidExtras/QAndroidJniObject layer which makes jni way less horrible. I've bin hoping to get around to doing some of this, but due to personal reasons I haven't had the time and energy. I'm glad to see you take up this work and get it done. //Anton -- Anton Lundin +46702-161604 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
