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.
Hamish