Subsurface Mobile: Adding mares USB (cp210x) support; how to proceed

[Anton Lundin]

On 01 March, 2020 - Dirk Hohndel wrote:

> 
> > On Mar 1, 2020, at 10:32 AM, Christof Arnosti <charno at charno.ch> 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