> Have a look at ft2232.c/ft2232_send_and_recv(). First, there's the
> ft2232_write, then the ft2232_read. For the memory writes (burst of 8K)
> needed for flashing, it looks like about 3 write bytes give 1 receive byte.
> The problem is that all USB calls are synchronous so you can't just start a
Georg Acher wrote:
> On Tue, Feb 10, 2009 at 09:10:54AM -0600, Dick Hollenbeck wrote:
>
>
>> So I see no problem in shrinking the buffer down to where it will work
>> for you. However, what this is really accomplishing is a change in flow
>> within the driver. Namely there must be a read t
On Tue, Feb 10, 2009 at 09:10:54AM -0600, Dick Hollenbeck wrote:
> So I see no problem in shrinking the buffer down to where it will work
> for you. However, what this is really accomplishing is a change in flow
> within the driver. Namely there must be a read triggered out of the
> ft2232 t
Georg Acher wrote:
> Hi,
> I've found the problem with the ft2232. I think it is a more general one...
>
> My first attempt to reduce the write bufer size had no effect, because I
> only split up the individual write requests, I didn't use the
> FT2232_BUFFER_SIZE value. But when reducing this valu
On Sat, Feb 07, 2009 at 10:52:24AM -0600, Dick Hollenbeck wrote:
> >The cause is that the MPSSE-commands also read data and that fills up the
> >FT2232's TX buffer.
>
> I'm having a hard time understanding the above sentence. How does a
> "read" fill up a TX buffer, where TX means transmit?
Tr
Georg Acher wrote:
> Hi,
> I've found the problem with the ft2232. I think it is a more general one...
>
> My first attempt to reduce the write bufer size had no effect, because I
> only split up the individual write requests, I didn't use the
> FT2232_BUFFER_SIZE value. But when reducing this valu
Hi,
I've found the problem with the ft2232. I think it is a more general one...
My first attempt to reduce the write bufer size had no effect, because I
only split up the individual write requests, I didn't use the
FT2232_BUFFER_SIZE value. But when reducing this value to 768, the flash
process wo
There are at least 3 ways to move forward:
1) http://www.nabble.com/snooping-the-usb-packets-td14684534.html
2) libusb has its own debug capability. I believe you only have to set
an environment variable named USB_DEBUG to turn it on. Then run your
app after that. See
https://www.codeblo
You are referring to a completely different driver than we are talking
about. There have been numerous reports of slow speeds with the JLink
adapter. I do not own one so I cannot debug it. If you believe it is
in usb_bulk_read, then it is either the dongle that is holding up the
operatio
Hi all,
I have tried libusb-1.0.0 and libusb-compat-0.1.0, with JLink
connection to my ARM-9 board. Loading a u-boot ELF image of size 100k
bytes by "load_image" command cost 200 seconds which is much slower than
the Wiggler I used. This result also applies to libusb-0.1.12. The
process seem
FYI-
I've had problems with the libusb-0.1.12 that ships with most recent
Linux distros; I would try running with the new libusb
(libusb.sourceforge.net) 1.0, and the libusb-compat-0.1.12 that comes
with it. Hopefully distros start switching to this new libusb.
-Jeff
Rick Altherr wrote:
On Feb 3, 2009, at 1:29 PM, Georg Acher wrote:
On Tue, Feb 03, 2009 at 01:00:24PM -0800, Rick Altherr wrote:
It's possible that the USB signaling is valid for short bursts but
not
for sustained transfers. Sadly, I don't have one of these dongles to
try nor do I have a scope fast enough to
On Tue, Feb 03, 2009 at 01:00:24PM -0800, Rick Altherr wrote:
> It's possible that the USB signaling is valid for short bursts but not
> for sustained transfers. Sadly, I don't have one of these dongles to
> try nor do I have a scope fast enough to look at USB signals. If you
> can get yo
On Feb 3, 2009, at 12:43 PM, Georg Acher wrote:
On Tue, Feb 03, 2009 at 11:53:14AM -0800, Rick Altherr wrote:
Interesting. Do you have a different ft2232-based dongle to try?
Only one of the same type. It has the same issue.
I assume you built libftdi by hand then. Can you try libftdi 0
On Tue, Feb 03, 2009 at 11:53:14AM -0800, Rick Altherr wrote:
> Interesting. Do you have a different ft2232-based dongle to try?
Only one of the same type. It has the same issue.
> I assume you built libftdi by hand then. Can you try libftdi 0.14?
No difference.
> It _could_ be a design
On Feb 3, 2009, at 11:39 AM, Georg Acher wrote:
On Tue, Feb 03, 2009 at 10:54:37AM -0800, Rick Altherr wrote:
There was a large commit to the SVN trunk last night that touched the
ft2232 driver. Have you tried using the 0.1.0 release instead?
I've tried it with an older version from around
On Tue, Feb 03, 2009 at 10:54:37AM -0800, Rick Altherr wrote:
> There was a large commit to the SVN trunk last night that touched the
> ft2232 driver. Have you tried using the 0.1.0 release instead?
I've tried it with an older version from around November and had the same
problems.
> No on
On Feb 3, 2009, at 9:06 AM, Georg Acher wrote:
Hi,
I've bought the "OpenOCD USB" JTAG programmer:
http://www.embedded-projects.net/index.php?page_id=256
It has the usual FT2232, so I thought it should be supported, but
there are
some strange problems...
I've compiled the latest openocd fro
Hi,
I've bought the "OpenOCD USB" JTAG programmer:
http://www.embedded-projects.net/index.php?page_id=256
It has the usual FT2232, so I thought it should be supported, but there are
some strange problems...
I've compiled the latest openocd from SVN and used libftdi-0.15 for
FTDI-support.
In prin
19 matches
Mail list logo
