On 2014-03-11 00:16, Hamish Moffatt wrote:
On 11/03/14 00:52, Jef Driesen wrote:
The slowness is expected. The attached patch introduces a 100ms delay before each command. With 4096 packets (of only 16 bytes), that means a total delay of at least 409.6 seconds. That alone is already a very good reason not to apply this patch, especially because most users don't need it. But it does give a good indication that the real problem is likely something timing related. The question is of course what and where.
Something else that is worth trying is increasing the 100ms delay in the oceanic_atom2_device_open() function. I don't really understand why, but some interfaces seem to need some extra time between setting up the serial port and sending the first data packet. I suspect that the OS or driver is async and returns before the settings are actually applied, causing us to send data before the device is ready. But I'm not really sure about that. Anyway, adding some extra delay there isn't that much of a problem because it's just a one time delay.
Increasing the delay in the oceanic_atom2_device_open() function didn't help (tried 1 second even). A delay of 1ms inside oceanic_atom2_send() was enough for a perfect transfer, but 0.5ms (via usleep() for hack's sake) was not enough.
Even a sleep of just 1ms per packet is pretty bad. If I remember correctly, the resolution of the Windows Sleep() function is in the order of 10-15ms only. So that would still be a delay of approximately 40.96 seconds.
I wonder if this is another case where the tcdrain() function isn't waiting properly until all bytes have been send out. We had a similar problem with Suunto devices before. There we implemented a workaround with serial_set_halfduplex() function. Could you try that as well? Just call it somewhere in the oceanic_atom2_device_open() function, but before the call to the oceanic_atom2_device_open() function.
How many wires does the Oceanic interface have? Just two or more?
I have been looking at the kernel history for the ftdi usb-serial driver, and there have been some changes related to waiting until the TX buffer is empty, so there could be something there as well. Which kernel version do you have (uname -a)?
PS: Don't forget to attach the logfiles. I want to have a look at the timings.
Jef