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

Mon Mar 2 07:39:09 PST 2020

On 01.03.20 22:09, Anton Lundin wrote:
> 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

Hi Anton, Hi Dirk,

Thank you very much for the pointers!

So from a coding perspective I think the tasks became quite clear:
- Check the pull-request for android libusb-compatibility at
https://github.com/Subsurface-divelog/subsurface/pull/2309, and finish
implementing the functionality to get the USB fd by JNI. This will fix
the existing serial_ftdi implementation, and libusb-based dive computers.
- Import usb-serial-for-android (probably in the build.gradl
configuration to keep things easy), and write a glue-layer using JNI.
Thanks for the info about QAndroidJniObject!
- Probably remove the serial_ftdi implementation if the
usb-serial-for-android one works fine.

Best regards
Christof

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200302/22c08008/attachment.html>