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

[Christof Arnosti]

Hi Stephen,

I hope that it will work with most computers using usb-to-serial
interfaces. The underlying usb-serial-for-android implementation
supports quite some chipsets.

I'd love for you to test the implementation!

You can grab a CI-Built apk from
https://github.com/Subsurface-divelog/subsurface/suites/505662208/artifacts/2634973
for testing. The source can be found at
https://github.com/charno/subsurface/tree/android-serial-clean, the pull
request at https://github.com/Subsurface-divelog/subsurface/pull/2647.

Best regards
Christof

On 07.03.20 17:22, Stephen Goodall wrote:
> Will this affect all USB computers with Android? Very exciting!! I had
> a look but made no progress (C++ is not something I've worked with so
> it would have been a miracle if I had made progress :D )
>
> I've got a Cressi Leonardo and a Suunto Zoop, and an Android 9 phone
> if you want me to test those out with any changes. Let me know the
> branch and I can build it and test it out
>
> Cheers!
>
> On Sun, 8 Mar 2020, 3:14 am Dirk Hohndel via subsurface,
> <subsurface at subsurface-divelog.org
> <mailto:subsurface at subsurface-divelog.org>> wrote:
>
>
>
>>     On Mar 7, 2020, at 5:27 AM, Christof Arnosti <charno at charno.ch
>>     <mailto:charno at charno.ch>> wrote:
>>
>>     Hi Dirk,
>>
>>     I did the integration of the Icon HD VID/PID pair, so if the
>>     testing is successful I think there is nothing left for me to do
>>     before a merge.
>>
>
>     I will play with this in a couple of hours and most likely merge
>     your changes.
>
>>     Someone just tested with an Mares Nemo Wide (Serial < 50000), and
>>     it did also work.
>>
>
>     Excellent.
>
>>     Just for clarification about the possible UI changes (now that
>>     I'm more awake again), I would envision a workflow like this:
>>     - When opening the divecomputer-screen, or pressing the refresh
>>     button ("Neu Scannen" in german), get all UsbDevices by issuing
>>     UsbManager.getDeviceList(). Use these to populate the connection
>>     ("Verbindung") list. (Only show the entries with specified
>>     driver-class when this is activated in the settings). I think
>>     there has to be done some work in the bt-discovery part so that
>>     these two mechanisms can work together.
>>
>
>     I'm not sure what you mean by only showing the entries with a
>     specified driver class. I thought the driver class is something
>     that you would select in that Connection drop down as an
>     alternative to the found devices.
>     My guess is that on the vast, vast majority of Android devices you
>     will only ever get one USB device. Maybe if someone uses a hub for
>     some reason (maybe to power the phone while reading dives?) one
>     might see more, but in general that would surprise me.
>     So we should optimize the user experience for the common case.
>     Which means to try and identify the one USB serial device that is
>     connected.
>>
>>     - When a device from the connection list is selected, maybe try
>>     to guess Vendor / Model by data provided in the UsbDevice-Object.
>>     There is already some code in QMLManager::showDownloadPage. I'm
>>     not sure how much there can be done since it seems that a lot of
>>     devices use the same PID/VIDs.
>>
>
>     Correct - I played with that back when working on the Intent code
>     and while there are a couple you can explicitly identify, for most
>     that is not possible
>
>>     - When the download-button is pressed, the UsbDevice-Object of
>>     the selected connection (and if selected the name of the
>>     driver-class) should be passed to serial_android_usb_open. From
>>     there on I can do the work.
>>
>
>     So again, you are suggesting to have a second (or actually,
>     fourth?) drop down with a driver class?
>
>>     There would probably also have to be done some changes when
>>     receiving the USB_DEVICE_ATTACHED intent so that the correct
>>     entry of the list is preselected.
>>
>
>     I believe so.
>
>     /D
>     _______________________________________________
>     subsurface mailing list
>     subsurface at subsurface-divelog.org
>     <mailto:subsurface at subsurface-divelog.org>
>     http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200307/f8925a39/attachment.html>