Re: [Libnifalcon-devel] Libnifalcon-devel post from radarsat1@gmail.com requires approval

[Kyle M. (qDot) <ky...@no...>]

Ok, just made a huge step on the drivers, unfortunately borne out of me 
ignoring my own notes.

The FTDI chip has a latency timer that defaults to 16ms. This timer is 
how the buffer is shipped to the host; either the timer clicks over and 
shoves whatever is in the buffer, or else when the buffer reaches 64 
bytes (62 user + 2 status), it throws the whole thing over (since that's 
max packet size anyways, since we're at 2.0 full speed, not high). This 
needs to be reset to 1 /after/ the firmware is sent over so that we can 
lockstep the input/output loop. Unfortunately, with libusb being 
synchronous, we can only send one input or output per USB frame, and 
with frame time being 1ms, we're stuck at a 500hz i/o loop. However, 
that's still WAY faster than we're going right now, and I've got a 
uberbleedingedge version of the driver using libusb-1.0 and a hacked up 
version of libftdi that can submit asynchronously, if you really need 
that extra speed /now/.

Anyways, I'm not sure when I'll get this to the repository or out in a 
new set of drivers, but if you want to add it to the libftdi drivers 
now, just throw in

ftdi_set_latency_timer(dev->falcon, 1);

at the end of the firmware loading function, and watch things fly.

This was in my initial bus trace notes from last August the /whole 
time/. I just accidentally skipped the step when writing up the code 
based replay. Oops.

I'll be writing up a nice big post on this for my blog. I'm pretty sure 
the ftd2xx drivers do dynamic latency scaling, which is why there's an 
upward curve on ftd2xx communications bandwidth over about the first 5 
seconds of operation.

Stephen Sinclair wrote:
> On Tue, Apr 22, 2008 at 1:19 PM, Kyle Machulis (qDot)
> <ky...@no...> wrote:
>   
>> Ok, well, I haven't quite figured out what's up with the mailing list yet,
>> so I reply to this directly. :)
>>     
>
> Cool, thanks.
> Since I posted that I got your kinematics example working and posted a
> different message to the mailing list saying so..
>
>
>
>   
>>  BTW, I should warn you, libftdi is /slow/. I finally profiled it last night
>> with my new direct kinematics code, on windows I get 980 processed i/o
>> queries per second with ftd2xx, ~190 on osx/linux using libftdi. I'm pretty
>> sure this is because libusb is hardcoded to use synchronous communication,
>> and that's what libftdi is built on top of. There's a new asynchronous
>> version of libusb in the works now, I may start poking at porting to that
>> soon, just to see if it gives any serious speed increase.
>>     
>
> Cool, hopefully it'll help.  Maybe some simple tests will at least
> show whether there is potential to speed it up.  Either way I'm on
> board to help out any way I can.
>
>
> Steve
>
>