Hi together, So I continued on my quest to support USB-to-Serial adapters in subsurface-mobile for android.
I focused on implementing the usb-serial-for-android driver. It works with my computer (TM), but there are still some problems in the code and I can't test with other computers. The Code can be found at https://github.com/charno/subsurface/commits/android-serial-clean. Problems: - usb read timeout is not working due to an android Bug (https://stackoverflow.com/questions/9108548/android-usb-host-bulktransfer-is-losing-data). Currently I start all read-requests without timeout. For Android API level 26 (Oreo 8.0), the used awaitRequest()-Method has an added timeout-parameter which could be used. - Not all dc_custom functionality is implemented. Notably so get_available (which seems to be used only optionally) and set_break (used by cochran_commander.c and reefnet_sensuspro.c). TODO: - Add known PID/VID pairs at https://github.com/charno/subsurface/blob/android-serial-clean/android-mobile/src/org/subsurfacedivelog/mobile/AndroidSerial.java#L94. For this the default probe table has to be modified, which seems quite straight-forward. Do you somewhere have a list of PID / VID / Used Chipset-thruples? - libusb-problem, affecting libusb divecomputers and serial_ftdi connections. I had a short look into it but did not go further down this path. - remove serial_ftdi? -> there are at least the cochran_commander.c and reefnet_sensuspro.c computers which won't work with usb-serial-for-android implementation, since they need serial break support. I would be happy if you could have a look at the code and maybe test the implementation with some more computers. I did use a Mares Puck Pro. Best regards Christof On 02.03.20 16:39, Christof Arnosti wrote: > 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 <[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 > > 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 > >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
