<div dir="ltr"><div>Hello</div><div><br></div><div>I have been working on bringing libdivecomputer on android.</div><div>I have started with support for ftdi-chipset based divecomputers. For talking with ftdi based devices on android, I have implemented serial_ftdi.c. . I have tried to implement all the the necessary functions. Though some of them are left out due to their unavailability in libftdi.</div>
<div><br></div><div>These left out functions are </div><div><ol><li>serial_set_break  - This is used only in reefnet_sensus_pro hanshaking. I do not know if it uses ftdi chipset. If it does, it would become important to implement this function. In the present implementation, it remains unusable.<br>
</li><li>serial_send_break - I could not find any usage of this function in libdivecomputer.<br></li><li>serial_get_transmitted - Even though the received bytes in the buffer can be accessed, I couldn't find any way to get the transmitted bytes. This function is used internally for logging. Returns -1 as it is not implemented.<br>
</li></ol></div><div><br></div><div>Changes made for building libdivecomputer for android are</div><div><ol><li>Check for presence of libftdi1<br></li><li>serial_ftdi.c is compiled and used instead of serial_posix.c<br></li>
<li>libftdi1 is included in Libs.private in libdivecomputer.pc</li></ol></div><div>All these changes can be viewed <a href="https://github.com/venkateshshukla/libdivecomputer">here</a>. I have been testing it with universal script and subsurface-android. Results have been encouraging.</div>
<div><br></div><div>Now, toward providing a workable API for android, I have following points in mind. These were mentioned by Jef in an earlier mail.</div><div><ol><li>Support for only ftdi devices are implemented for now. But support for other chipsets need to be included later on. Hence, serial_ftdi.c alone is not enough. We need a serial_android.c which will redirect calls to respective chipset specific scripts.<br>
</li><li>I have come to the conclusion that for android, it will be best if we pass the file descriptor of the USB device after acquiring the necessary permissions. This fd can be used to create a libusb_device and subsequently all USB related features can be accessed. For making a libusb_device from file descriptor obtained from android, I had tweaked libusb. This tweaked version is present here ( <a href="https://github.com/venkateshshukla/libusb">https://github.com/venkateshshukla/libusb</a> ). This libusb_device could be used to obtain VID and PID and then control can then be branched accordingly to ftdi, pl2303, cp210x and other chipset specific scripts on android.<br>
</li><li>We will require a generalized mechanism for passing parameters. This is especially needed now as we have several branches - Normal TTY usage ( posix/win32 , path to the device), android (file descriptor) and Bluetooth address.</li>
</ol></div><div>Please provide your thoughts on the above points. Also any other thing that I should keep in mind for android API?</div><div><br></div>-- <br>Venkatesh Shukla<br>
</div>