<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 01.03.20 22:09, Anton Lundin wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20200301210903.GC47181@hirohito.acc.umu.se">
<pre class="moz-quote-pre" wrap="">On 01 March, 2020 - Dirk Hohndel wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Mar 1, 2020, at 10:32 AM, Christof Arnosti <a class="moz-txt-link-rfc2396E" href="mailto:charno@charno.ch"><charno@charno.ch></a> 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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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...
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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."
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I need to update the FAQ. Initially it was indeed "some" where it failed.
Now it is basically "all".
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">While recherching I found the git repo
<a class="moz-txt-link-freetext" href="https://github.com/mik3y/usb-serial-for-android">https://github.com/mik3y/usb-serial-for-android</a> 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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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...
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
</blockquote>
<p>Hi Anton, Hi Dirk,</p>
<p>Thank you very much for the pointers!</p>
<p>So from a coding perspective I think the tasks became quite
clear:<br>
- Check the pull-request for android libusb-compatibility at
<a class="moz-txt-link-freetext" href="https://github.com/Subsurface-divelog/subsurface/pull/2309">https://github.com/Subsurface-divelog/subsurface/pull/2309</a>, 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.<br>
- 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!<br>
- Probably remove the serial_ftdi implementation if the
usb-serial-for-android one works fine.</p>
<p>Best regards<br>
Christof<br>
</p>
<p><br>
</p>
</body>
</html>