On 2014-02-26 09:45, Anton Lundin wrote:
One idea i bin playing with is how to make the Android port capable of
downloading data from divecomputers.
A port of libdivecomputer to Android is also something I'm interested
in. Bringing your smartphone or tablet near the dive site is far more
convenient than a laptop :-)
Android doesn't contain a serial api, and it doesn't include the usual
usb-serial drivers that comes along in the Linux source tree.
It provides enough attachment points as far as i can understand that we
would be capable to run a usb-serial driver in userspace.
The current Android builds contains libdivecomputer and libusb. To make
this possible we would need to extend libdivecomputer to talk to usb
devices in other ways on android. There are a bunch of libraries to
talk
to the most common usb-serial chips available.[1,2,3]
1. https://code.google.com/p/android-serialport-api/
2. https://github.com/mik3y/usb-serial-for-android
3. http://www.intra2net.com/en/developer/libftdi/
The serial api may not be exposed to the java world, but it is certainly
usable from native code. As far as I know, you only needed a few minor
tweaks to compile libdivecomputer for Android [1]. Once we have that, an
Android application can simply use libdivecomputer, and there is no
longer a need to have access to the serial api directly. For a java
applications a JNI wrapper will of course be necessary.
[1]
https://github.com/glance-/libdivecomputer/commit/0f7ef245a9d0c8be533e5045b475e51acacec520
The main problem are indeed the kernel drivers. It's a pity enabling the
usb-serial kernel modules on an Android phone is non trivial (compared
to installing an application). Because that would be the least amount of
work: the kernel divers already exist and just needs to be enabled.
Re-writing the usb-serial drivers in userspace, will require a different
driver for every type of chip, and there are at least 4 of them (ftdi,
prolific, silabs, cdc-acm).
Assume we manage to implement the necessary userspace driver, how do we
integrate this nicely into libdivecomputer? This a question for which I
have no good answer at the moment. Right now, an application simply
passes the device node (e.g. /dev/ttyXXX), and libdivecomputer takes
care of opening the serial port. This works well because there is just
one driver for each platform. But once we have multiple serial drivers,
we'll also need some mechanism to select the right driver.
I don't know now the Gsoc ideas list work, but his might be a
interesting
task to put on that list. A good scope would probably be to create a
downloader-only port of subsurface for the time being.
I think this is a very interesting and challenging idea indeed.
Jef
_______________________________________________
subsurface mailing list
[email protected]
http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
