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

[Christof Arnosti]

On 07.03.20 17:12, Dirk Hohndel 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.
I'm looking forward to leave my laptop at home for my next diving
holiday! :-)
>
>> 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?
No, I would keep the existing "connection" dropdown.

My Idea for populating the list would be this:

- Have a setting in the application settings like "Allow usb-serial
driver selection". (since in most cases the driver can be automatically
detected - as you said, most DCs have known PID/VID pairs).
- In the device-dropdown display all found USB devices (as you said,
most likely it's just one).
-> If the Driver-Selection setting is not enabled, just show something
like "Silicon Labs CP2102" per USB device.
-> If the Driver-Selection setting is enabled, show multiple entries per
driver, something like "Silicon Labs CP2102 (autodetect driver)",
"Silicon Labs CP2102 (FTDI)", "Silicon Labs CP2102 (CP21xx)" etc., for
all the driver classes.

Does this make more sense?

>
>> 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
Best regards
Christof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200307/5757ad23/attachment-0001.html>