Re: FTDI isochronous USB transfer

> Of course this assume that the 1st byte is sync'ed with the start of a
> packet.  That's a reason for using using two threads with a circular
> buffer,  1) to read  the USB data and stuff it into the buffer as fast
> as it is available; 2) to parse the buffer, making sure you locate and
> sync with the proper "start of packet" sequence, and deliver the
> properly formated packet to the user application.

Isn't what you can "read the USB data and stuff it into the buffer as
fast
as it is available" exactly whay the FT_Read function does????? I
already have it!

Let's see if I understood well: I read any amount of data I have in
the buffer, within a high priority thread. How do I signal to the
other (the "parsing") thread that I got data in the "communications"
thread???

I say "any amount of data" because if I send data from the DSP to the
DSP before triggering the "communications" thread in the PC side, I'll
read more than what I expected, and maybe will have some incomplete
packets... So, if first start the PC application, and then start to
send data to the PC, the event will be in a non-signalled state, until
it receives data from the DSP, and all the packets will be complete.
And once I receive the data, I should store it as soon as possible, in
a (circular) buffer. One question is: why circular? Now that I know
that I'll receive complete packets (am I sure of this?), wouldn't it
be easier to store the received information (a full packet, niether
more, nor less) into a bigger buffer of packets? The question that
arises here is (again): how to signal another thread that I have a
packet in memory!!

It all depends on the fact that the WaitForSingleObject(hEvent,
INFINITE) function ever returns... but what if it never returns, as it
seems to be my case???

Thanks you for your comments,

JaaC