Hi, As you can see I am having some troubles and I don't know in which direction to go. If we want to implement the data transfer using the Qt Bluetooth API, then we should find a way to integrate it with the implementation of the serial port communication from *libDC* project.
If this is not possible and we still want to use the Qt Bluetooth API, then we need to do some specific implementation for each dive computer vendor. This implies a lot of useless work since it is already implemented in *libDC* project. I already tested the *serial_write* and *serial_read* methods from *libDC*, using the *QtBluetoothSocket* descriptor and they work. These are the basic methods used to communicate with the device in *libDC*. The only problem is that I need to call somehow the initialization method to initialize the *vtable* of the device which stores functions pointers to some device specific implementation for read/write methods. As I said, the initialization is done in the *open* method and I don't know how to fake its call. I cannot manually initialize the *vtable* because the methods are declared static. If I find a way to initialize the *vtable* and to replace the serial port descriptor with my socket descriptor, then I expect things to work. Do you have any suggestions how to do that? Do you believe that this is a bad idea? Should I give up with the Qt Bluetooth API and move further? Thanks, Claudiu On Sun, Jun 14, 2015 at 12:43 AM, Claudiu Olteanu < olteanu.vasilica.clau...@gmail.com> wrote: > Hi there, > > This week I did some research about the *libdivecomputer* > parser and its serial port implementation. > > I find out that each device has a virtual table which > contains information about the device's family (*type*), > a fingerprint and references to some operations > (read/write/dump/close) needed for the serial > communication. This table is initialized when the device > is opened. > > In order to create a parser you need to provide the > following information: > - the device type (find out in the *vtable* or in our > *descriptorLookup* map) > - some device information (the *model*, the *serial* and > the *firmware*) read from the device > - some information about device's clock (*systime* and > *devtime*) read from the device > > Therefore all needed information can be obtained and we > can create and use the *libdivecomputer* parser. > > The problem is that the devices expose only the Serial > Port Profile and we can communicate with them only using > the virtual COM port. Each device family has its own > specific implementation and it requires a lot of work. > > Since the serial communication is already implemented in > libdivecomputer I tried to find a way to use it along with > the Qt Bluetooth API functionalities. I thought that if > somehow I will replace the file descriptor of device's > serial port from libdc with the socket descriptor obtained > using the Qt Bluetooth API it should work. I am not sure > if this is a good or a bad one. I didn't find a solution > to do that anyway. We need to open the device in order to > initialize its *vtable* and it will fail when it will try > to open the serial port, since there is no port to open. > > I also tried to create a named pipe, to use it to simulate > the virtual COM port and to pass its name to devname field > from *device_data_t* structure (used when the port is opened). > I didn't even believe that it would work but I said that I > should give it a try. Apparently the *dc_device_open* method > fails when it tries to call the *ioctl* or the *tcgetattr* > method. I simulated the calls and both fail with an > "*Inappropriate ioctl*" error. This is probably due the fact > that it uses the TIOCEXCL command which is specific for > terminals. > > Then I though that maybe a *pseudo-tty* can solve my problem, > but I didn't have time to research. Do you believe that > a pty could be a solution? > > Besides that I did some research about *QtSerialPort* and > *QtSerialDevice* in order to see if I can emulate the virtual > port and use it in my scenario. Unfortunately I didn't > find anything useful. > > Now I am a little stuck and I don't know if I should give > up with the Qt Bluetooth API and move further. Should I > start to look over Jef's work and to finish his > implementation? > > Another possible solution could be to implement the *bind* > command from *rfcomm* tool. I looked over the implementation > and I can do that with a simple *ioctl* call. I will use the > Qt Bluetooth API for scanning, pairing and collecting > information about remote devices. When the client wants > to connect to the device, then I will create a RFCOMM > device and use it in the *downloadfromdivecomputer* > implementation. The inconvenient is that in order to > create a RFCOMM device we need root privileges. > > Please let me know if you have other ideas or if I > should concentrate my work in other direction. > > Best wishes, > Claudiu >
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface