Programming questions

[Jef Driesen]

On 2014-07-06 19:25, John Van Ostrand wrote:
> I've started writing libdivecomputer code for the Cochran and I have a 
> few
> questions that I expect are easy answers.
> 
> 1. I'm wondering how much I should read in the _init function. It seems 
> I
> should read enough to verify I'm talking to the right device and get 
> the
> serial number. Is that right?

There is no init function, so I assume you mean the open function? There 
you should do whatever is necessary to setup the connection with the 
device. For some devices, that means opening the serial port and that's 
it, but others may need some extra steps. It all depends on the 
communication protocol.

> 2. There are other reads I can do that will get things like # of dives, 
> gas
> mixtures, conservatism, etc. I need number of dives to read the log 
> book.
> Should I do this in _read? And does it make sense to do this read 
> before
> setting progress information?

None of this belongs in the read function. The read (and write) function 
is an optional function for devices that support random access to the 
internal memory (e.g. read X bytes at memory address Y). If a device 
doesn't support this feature, then it shouldn't be implemented. The same 
is true for the dump function. The only mandatory function is the 
foreach function. That's the one that is used by applications to 
download dives. Depending on the communication protocol this function 
may be implemented on top of the dump or read function, but that's just 
an implementation detail.

Thus the foreach function is where you implement the logic to download 
the individual dives, and you may read whatever piece of information is 
necessary there.

> 3. I have extra information that I can offer the user, pre- and 
> post-dive
> things like battery voltage, tissue load, time to fly, previous SIT,
> repetitive dive count and dive profiles samples like tissue load every 
> 24
> seconds, NDL remaining (I think), deco required (I think), ascent rate. 
> I
> can also get post dive off-gassing tissue load and temperature samples. 
> The
> DC continues to log samples until off-gassed
> I can't see any structure for all of this, or a way to carry around 
> that
> kind of data.

Libdivecomputer doesn't offer an api to retrieve this kind of 
information because it's too device specific. That's on of the reasons 
why libdivecomputer does provides access to the binary dive data. If an 
application wants to get some info which isn't available through the 
libdivecomputer parser api, it can still get it from the raw binary 
data. Of course that's not as convenient as using the api, but it is 
possible.

> 4. The DC requires some prodding to accept commands, after being 
> prompted
> it emits a byte every second. Initially it's a 0xAA but after reading 
> dive
> samples it's a 0x00. The only way I've been able to prompt it is to 
> send a
> byte to it. The vendor software doesn't do this. Could it be a USB 
> signal
> of some sort. I see "Sync Reset Pipe and Clear Stall" in the USB 
> capture
> and "Vendor Device" and "Control transfer". Any ideas on what I might 
> try?

It's hard to tell without seeing the communication you captured. Some 
protocols do indeed use the dtr/rts lines, breaks, etc. Although most 
modern devices usually don't. (I guess usb-serial chips make this harder 
compared to real rs232 hardware.)

Jef