On Mar 15, 2012 4:32 AM, "Peter Stuge" <pe...@stuge.se> wrote:
>
> Tomek CEDRO wrote:
> > I am a bit afraid that my great ideas on automatic error handling and
> > enqueueing longer operation sequences are anyway going to be broken
> > because of the USB latency bottleneck :-(
> >
> > Were maximum FT2232H transfers calculated by anyone for JTAG already?
> >
> > Peter, would that be possible to have small transfer latency less than
> > 1us for FT2232 devices using libftdi/libusb?
>
> Yes, but only if the correct number of transfers are queued in
> advanced using the libusb-1.0 async API. Then the multiple bulk
> transfers can be scheduled by the USB host controller within the same
> 125µs microframe.
>
> But obviously it's not possible to evaluate any data from transfer
> one before submitting transfer two in this case.
>
> If the number of transfers can not be predicted then the minimum
> theoretical latency per transfer is 125µs ie. one microframe, but in
> practise it will be tens of ms because of context switching between
> kernel and userspace.
Ugh, this will not help as we need to evaluate results very often as you
noted. Also this would vary across different platforms...
Ill see how things could be speeded up using TAR autoincrement and sticky
errors handling so we write large data in bursts of few kilobytes at once
(1k or 64k max for mpsse per command)...
Best regards :-)
Tomek
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
