07-30-2014, 02:32 PM
Switching to the FTDI library has cured my problem. I still suspect something about the port parameters at fault, but they seemed fine to me, and a virtual port shouldn't really be as fussy as real serial hardware. Here's what the problem looked like in the analyzer:
https://dl.dropboxusercontent.com/u/2553...offset.png
Note the zero bytes at the start of the data returned, and the red line at the start of the visualisation. Once real data did start flowing, it was from the start of the buffer rather than the current data offset. That caused the offset on the first revolution that prevented me matching sector positions on subsequent revolutions.
I'm still not so keen on the FTDI driver requirement as it's a bit of a barrier for users. Windows owners of the SCP board will already have them installed for the official software, but getting Linux and Mac users to install it may be a bit of a support headache. I'll double check that recent Linux and Mac OSes install the device as a virtual serial port without any trouble, and then maybe go back to track down the cause of it not working under Windows.
https://dl.dropboxusercontent.com/u/2553...offset.png
Note the zero bytes at the start of the data returned, and the red line at the start of the visualisation. Once real data did start flowing, it was from the start of the buffer rather than the current data offset. That caused the offset on the first revolution that prevented me matching sector positions on subsequent revolutions.
I'm still not so keen on the FTDI driver requirement as it's a bit of a barrier for users. Windows owners of the SCP board will already have them installed for the official software, but getting Linux and Mac users to install it may be a bit of a support headache. I'll double check that recent Linux and Mac OSes install the device as a virtual serial port without any trouble, and then maybe go back to track down the cause of it not working under Windows.