About the GN3S application and lib functions "usb_reap_async" and "usb_submit_async"

[Xu, Feng]

Hi,

I am reading some code about GN3S usb applications.
Which is reading data from GPS front end via USB interface.

I am new on USB, and get lots of question. Hope you can help me out.
1) What is procedures of reading data, especially, what do the
functions "usb_reap_async" and "usb_submit_async" do?
2) What is the inspiration of reading, by interrupt or something.
3) Is there any ways to check the data number in the buffer. The code
uses usb_control_msg to check the buffer is overflow or not, but it
doesn't provide the data number.

Thanks a lot.

Feng

P.S. The read function and class declaration shown as follows.
And the full code is attached.

class fusb_ephandle_win32 : public fusb_ephandle
{
private:
  fusb_devhandle_win32 *d_devhandle;

  unsigned d_curr;
  unsigned d_outstanding_write;
  int d_input_leftover;
  int d_output_short;
  void ** d_context;
  char * d_buffer;

public:
  // CREATORS
  fusb_ephandle_win32 (fusb_devhandle_win32 *dh, int endpoint, bool input_p,
                         int block_size = 0, int nblocks = 0);
  virtual ~fusb_ephandle_win32 ();

  // MANIPULATORS

  virtual bool start ();   //!< begin streaming i/o
  virtual bool stop (); //!< stop streaming i/o

  /*!
   * \returns \p nbytes if write was successfully enqueued, else -1.
   * Will block if no free buffers available.
   */
  virtual int write (const void *buffer, int nbytes);

  /*!
   * \returns number of bytes read or -1 if error.
   * number of bytes read will be <= nbytes.
   * Will block if no input available.
   */
  virtual int read (void *buffer, int nbytes);

  /*
   * block until all outstanding writes have completed
   */
  virtual void wait_for_completion ();
};

int fusb_ephandle_win32::read (void *buffer, int nbytes)
{
  int retval=0;
  char *buf;

  if (!d_started) // doesn't matter here, but keeps semantics constant
    return -1;

  if (!d_input_p)
    return -1;

  int bytes_to_read = nbytes;

  int a=0;
  if (d_input_leftover != 0)
  {//-- have some data left over

    buf = &d_buffer[d_curr*d_block_size + d_block_size - d_input_leftover];
    a = min(nbytes, d_input_leftover);
    memcpy(buffer, buf, a);
    bytes_to_read -= a;
    d_input_leftover -= a;

    printf("inif-%d %d %d\n",bytes_to_read,d_input_leftover,a);

    if (d_input_leftover == 0)
      usb_submit_async(d_context[d_curr], &d_buffer[d_curr*d_block_size],
        d_block_size);
    if (bytes_to_read == 0)
      return nbytes;
    assert(d_input_leftover == 0);
  }

  d_curr = (d_curr+1)%d_nblocks;
  buf = &d_buffer[d_curr*d_block_size];

  retval = usb_reap_async(d_context[d_curr], USB_TIMEOUT);
  if (retval < 0)
    fprintf(stderr, "%s: usb_reap_async: %s\n",
      __FUNCTION__, usb_strerror());

  memcpy((void *) &(((char*)buffer)[a]), buf, bytes_to_read);

  d_input_leftover = d_block_size - bytes_to_read;
  //printf("out-%d %d %d\n",bytes_to_read,d_input_leftover,0);
  printf("out-%d %d %d %d\n",retval,d_curr,bytes_to_read,d_block_size);

  if (d_input_leftover == 0)
    usb_submit_async(d_context[d_curr], buf, d_block_size);

  return retval < 0 ? retval : nbytes;
}


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-win32-devel mailing list
Libusb-win32-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel

[Michael Plante]

Feng wrote:
>> 1) What is procedures of reading data, especially, what do the
>> functions "usb_reap_async" and "usb_submit_async" do?

Based on the question, this is someone else's code, not yours?  If I
understand correctly, "submit" tells the OS to schedule the transfer, and
"reap" cleans up (which involves getting the requested data back on a read).
Evidently, usb_reap_async() can block for USB_TIMEOUT (a number you didn't
include) in your case.  Take this with a grain of salt, as I've only used
synchronous interfaces, and am figuring what I can from your code and the
libusb source.  If you want to see a simpler example, you might read the
source to _usb_transfer_sync().  It uses these functions.


>> 2) What is the inspiration of reading, by interrupt or something.

Not sure I understand what you mean by "inspiration".  Maybe you could
rephrase that?


>> 3) Is there any ways to check the data number in the buffer. The code
>> uses usb_control_msg to check the buffer is overflow or not, but it
>> doesn't provide the data number.

Which buffer?  You could write a member function that returns
d_input_leftover, but I don't know about OS or driver buffers.  It looks
like (maybe?) calling with nbytes<=d_input_leftover will not cause it to
block, but might still schedule another transfer.  Eventually, you're going
to have to let it call reap, though (at some rate related to the GPS
device's update rate), so you'll either need to plan for that, or else
thread.  If you do thread, don't access the same device from more than one
thread; copy to a buffer and make sure that buffer is accessed
synchronously.  This stuff is nice, since you can submit the read and then
block on buffer access in the reader thread, if need be.



Michael


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-win32-devel mailing list
Libusb-win32-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel

[Xu, Feng]

Hi Michael,

Thanks a lot for your reply.

On Wed, Oct 28, 2009 at 8:43 AM, Michael Plante
<michael.plante@...> wrote:
> Feng wrote:
>>> 1) What is procedures of reading data, especially, what do the
>>> functions "usb_reap_async" and "usb_submit_async" do?
>
> Based on the question, this is someone else's code, not yours?  If I
Yeah. It is from open source code. Provided with a book and also available via
http://sourceforge.net/projects/osgps/

> understand correctly, "submit" tells the OS to schedule the transfer, and
> "reap" cleans up (which involves getting the requested data back on a read).
> Evidently, usb_reap_async() can block for USB_TIMEOUT (a number you didn't
> include) in your case.  Take this with a grain of salt, as I've only used
> synchronous interfaces, and am figuring what I can from your code and the
> libusb source.  If you want to see a simpler example, you might read the
> source to _usb_transfer_sync().  It uses these functions.
The TIMEOUT is 1 sec.
So, my understanding of the transfer procedure based on your information are:
First, using 'submit' to schedule the transfer.
And then, using the 'reap' to clear the data in USB device to prevent
the device to warn an overflow.

I will read the _usb_transfer_sync() for more information :)
>
>
>>> 2) What is the inspiration of reading, by interrupt or something.
>
> Not sure I understand what you mean by "inspiration".  Maybe you could
> rephrase that?
Maybe 'trigger' will be more proper here.

Actually, what I want to ask is that how the CPU knows the data in the
USB device is ready.
By querying something flag in the device.
Or the device gives an interrupt to the CPU when the data are ready.

>
>
>>> 3) Is there any ways to check the data number in the buffer. The code
>>> uses usb_control_msg to check the buffer is overflow or not, but it
>>> doesn't provide the data number.
>
> Which buffer?  You could write a member function that returns
> d_input_leftover, but I don't know about OS or driver buffers.  It looks
> like (maybe?) calling with nbytes<=d_input_leftover will not cause it to
> block, but might still schedule another transfer.  Eventually, you're going
> to have to let it call reap, though (at some rate related to the GPS
> device's update rate), so you'll either need to plan for that, or else
> thread.  If you do thread, don't access the same device from more than one
> thread; copy to a buffer and make sure that buffer is accessed
> synchronously.  This stuff is nice, since you can submit the read and then
> block on buffer access in the reader thread, if need be.

Yeah. Multi threads will be better, but I still have only one thread now.
So I need to query the data number in the buffer frequently to make
sure there is no overflow.

I don't know the name of that buffer. It is in the device class, shown
as variable 'buf' in the following code line
memcpy((void *) &(((char*)buffer)[a]), buf, bytes_to_read);
And variable 'buffer' is for the signal processing programs.

Now I would like to know how many data are in the buffer 'buf'.

The size of 'buf' is 1024*16384, where 16384 is d_block_size in the
code, and 1024 is d_nblocks (the number of blocks). Based on my
testing, because bytes_to_read is equal to d_block_size, so the
left_over is always equal to zero. What I am interested is the number
of blocks (0~1023) remaining in the 'buf'.
Every time I call the function "int fusb_ephandle_win32::read (void
*buffer, int nbytes)"
I will read the data in d_curr, but I don't know which block have been
filled by the incoming data ( a quantity higher than d_curr2).
If I can get the d_curr2, I can got the number of data blocks I
haven't read in the 'buf' easily, but I don't know to get the d_curr2.

Thanks.

>
>
>
> Michael
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Libusb-win32-devel mailing list
> Libusb-win32-devel@...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-win32-devel mailing list
Libusb-win32-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel

[Michael Plante]

Hi,

I'm afraid I can't get to all of this right now, but to answer your question
about how the CPU knows:  no, there is no interrupt.  USB is entirely
polled.  If you (the CPU) don't schedule time on the bus, the device just
has to FIFO/buffer (or discard!) its data until you ask for it.  So you do
need to keep submitting requests if you don't want to lose anything.  I
personally wouldn't worry so much about losing old GPS data, since the old
data is less useful than the current stuff, but you may have different
needs.  If you think you'll frequently move between >=4 and <4 satellites,
it might be worth holding onto old data.  It just depends.

Michael





-----Original Message-----
From: Xu, Feng [mailto:fengxu0510@...]
Sent: Wednesday, October 28, 2009 12:55 PM
To: michael.plante@...; libusb-win32-devel@...
Subject: Re: [Libusb-win32-devel] About the GN3S application and lib
functions"usb_reap_async" and "usb_submit_async"


Hi Michael,

Thanks a lot for your reply.

On Wed, Oct 28, 2009 at 8:43 AM, Michael Plante
<michael.plante@...> wrote:
> Feng wrote:
>>> 1) What is procedures of reading data, especially, what do the
>>> functions "usb_reap_async" and "usb_submit_async" do?
>
> Based on the question, this is someone else's code, not yours?  If I
Yeah. It is from open source code. Provided with a book and also available
via
http://sourceforge.net/projects/osgps/

> understand correctly, "submit" tells the OS to schedule the transfer, and
> "reap" cleans up (which involves getting the requested data back on a
read).
> Evidently, usb_reap_async() can block for USB_TIMEOUT (a number you didn't
> include) in your case.  Take this with a grain of salt, as I've only used
> synchronous interfaces, and am figuring what I can from your code and the
> libusb source.  If you want to see a simpler example, you might read the
> source to _usb_transfer_sync().  It uses these functions.
The TIMEOUT is 1 sec.
So, my understanding of the transfer procedure based on your information
are:
First, using 'submit' to schedule the transfer.
And then, using the 'reap' to clear the data in USB device to prevent
the device to warn an overflow.

I will read the _usb_transfer_sync() for more information :)
>
>
>>> 2) What is the inspiration of reading, by interrupt or something.
>
> Not sure I understand what you mean by "inspiration".  Maybe you could
> rephrase that?
Maybe 'trigger' will be more proper here.

Actually, what I want to ask is that how the CPU knows the data in the
USB device is ready.
By querying something flag in the device.
Or the device gives an interrupt to the CPU when the data are ready.

>
>
>>> 3) Is there any ways to check the data number in the buffer. The code
>>> uses usb_control_msg to check the buffer is overflow or not, but it
>>> doesn't provide the data number.
>
> Which buffer?  You could write a member function that returns
> d_input_leftover, but I don't know about OS or driver buffers.  It looks
> like (maybe?) calling with nbytes<=d_input_leftover will not cause it to
> block, but might still schedule another transfer.  Eventually, you're

going
> to have to let it call reap, though (at some rate related to the GPS
> device's update rate), so you'll either need to plan for that, or else
> thread.  If you do thread, don't access the same device from more than one
> thread; copy to a buffer and make sure that buffer is accessed
> synchronously.  This stuff is nice, since you can submit the read and then
> block on buffer access in the reader thread, if need be.
Yeah. Multi threads will be better, but I still have only one thread now.
So I need to query the data number in the buffer frequently to make
sure there is no overflow.

I don't know the name of that buffer. It is in the device class, shown
as variable 'buf' in the following code line
memcpy((void *) &(((char*)buffer)[a]), buf, bytes_to_read);
And variable 'buffer' is for the signal processing programs.

Now I would like to know how many data are in the buffer 'buf'.

The size of 'buf' is 1024*16384, where 16384 is d_block_size in the
code, and 1024 is d_nblocks (the number of blocks). Based on my
testing, because bytes_to_read is equal to d_block_size, so the
left_over is always equal to zero. What I am interested is the number
of blocks (0~1023) remaining in the 'buf'.
Every time I call the function "int fusb_ephandle_win32::read (void
*buffer, int nbytes)"
I will read the data in d_curr, but I don't know which block have been
filled by the incoming data ( a quantity higher than d_curr2).
If I can get the d_curr2, I can got the number of data blocks I
haven't read in the 'buf' easily, but I don't know to get the d_curr2.

Thanks.
>
>
>
> Michael
>
>
> --------------------------------------------------------------------------
----

> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Libusb-win32-devel mailing list
> Libusb-win32-devel@...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-win32-devel mailing list
Libusb-win32-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel

[Xu, Feng]

Hi Michael,

Thanks.

"the device just has to FIFO/buffer (or discard!) its data until you
ask for it."
Is that possible to get the FIFO address where the device is current writing.?

My application of the USB device is to get the sampled GPS IF data,
not the measurements, so I cannot loss any data in the device, other,
the software receiver will loss track.

I think it is important to understand the firmware and driver stuffs
as well, only the application codes are not enough. I should locate
more time on this.

Actually now, I have a temporary solution that, I will have a timer
interrupt in my code, and then the interrupt function will read the
data frequently to avoid overflow.

Thanks a lot,

Feng

On Wed, Oct 28, 2009 at 1:15 PM, Michael Plante
<michael.plante@...> wrote:

> Hi,
>
> I'm afraid I can't get to all of this right now, but to answer your question
> about how the CPU knows:  no, there is no interrupt.  USB is entirely
> polled.  If you (the CPU) don't schedule time on the bus, the device just
> has to FIFO/buffer (or discard!) its data until you ask for it.  So you do
> need to keep submitting requests if you don't want to lose anything.  I
> personally wouldn't worry so much about losing old GPS data, since the old
> data is less useful than the current stuff, but you may have different
> needs.  If you think you'll frequently move between >=4 and <4 satellites,
> it might be worth holding onto old data.  It just depends.
>
> Michael
>
>
>
>
>
> -----Original Message-----
> From: Xu, Feng [mailto:fengxu0510@...]
> Sent: Wednesday, October 28, 2009 12:55 PM
> To: michael.plante@...; libusb-win32-devel@...
> Subject: Re: [Libusb-win32-devel] About the GN3S application and lib
> functions"usb_reap_async" and "usb_submit_async"
>
>
> Hi Michael,
>
> Thanks a lot for your reply.
>
> On Wed, Oct 28, 2009 at 8:43 AM, Michael Plante
> <michael.plante@...> wrote:
>> Feng wrote:
>>>> 1) What is procedures of reading data, especially, what do the
>>>> functions "usb_reap_async" and "usb_submit_async" do?
>>
>> Based on the question, this is someone else's code, not yours?  If I
> Yeah. It is from open source code. Provided with a book and also available
> via
> http://sourceforge.net/projects/osgps/
>
>> understand correctly, "submit" tells the OS to schedule the transfer, and
>> "reap" cleans up (which involves getting the requested data back on a
> read).
>> Evidently, usb_reap_async() can block for USB_TIMEOUT (a number you didn't
>> include) in your case.  Take this with a grain of salt, as I've only used
>> synchronous interfaces, and am figuring what I can from your code and the
>> libusb source.  If you want to see a simpler example, you might read the
>> source to _usb_transfer_sync().  It uses these functions.
> The TIMEOUT is 1 sec.
> So, my understanding of the transfer procedure based on your information
> are:
> First, using 'submit' to schedule the transfer.
> And then, using the 'reap' to clear the data in USB device to prevent
> the device to warn an overflow.
>
> I will read the _usb_transfer_sync() for more information :)
>>
>>
>>>> 2) What is the inspiration of reading, by interrupt or something.
>>
>> Not sure I understand what you mean by "inspiration".  Maybe you could
>> rephrase that?
> Maybe 'trigger' will be more proper here.
>
> Actually, what I want to ask is that how the CPU knows the data in the
> USB device is ready.
> By querying something flag in the device.
> Or the device gives an interrupt to the CPU when the data are ready.
>>
>>
>>>> 3) Is there any ways to check the data number in the buffer. The code
>>>> uses usb_control_msg to check the buffer is overflow or not, but it
>>>> doesn't provide the data number.
>>
>> Which buffer?  You could write a member function that returns
>> d_input_leftover, but I don't know about OS or driver buffers.  It looks
>> like (maybe?) calling with nbytes<=d_input_leftover will not cause it to
>> block, but might still schedule another transfer.  Eventually, you're
> going
>> to have to let it call reap, though (at some rate related to the GPS
>> device's update rate), so you'll either need to plan for that, or else
>> thread.  If you do thread, don't access the same device from more than one
>> thread; copy to a buffer and make sure that buffer is accessed
>> synchronously.  This stuff is nice, since you can submit the read and then
>> block on buffer access in the reader thread, if need be.
> Yeah. Multi threads will be better, but I still have only one thread now.
> So I need to query the data number in the buffer frequently to make
> sure there is no overflow.
>
> I don't know the name of that buffer. It is in the device class, shown
> as variable 'buf' in the following code line
> memcpy((void *) &(((char*)buffer)[a]), buf, bytes_to_read);
> And variable 'buffer' is for the signal processing programs.
>
> Now I would like to know how many data are in the buffer 'buf'.
>
> The size of 'buf' is 1024*16384, where 16384 is d_block_size in the
> code, and 1024 is d_nblocks (the number of blocks). Based on my
> testing, because bytes_to_read is equal to d_block_size, so the
> left_over is always equal to zero. What I am interested is the number
> of blocks (0~1023) remaining in the 'buf'.
> Every time I call the function "int fusb_ephandle_win32::read (void
> *buffer, int nbytes)"
> I will read the data in d_curr, but I don't know which block have been
> filled by the incoming data ( a quantity higher than d_curr2).
> If I can get the d_curr2, I can got the number of data blocks I
> haven't read in the 'buf' easily, but I don't know to get the d_curr2.
>
> Thanks.
>>
>>
>>
>> Michael
>>
>>
>> --------------------------------------------------------------------------
> ----
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Libusb-win32-devel mailing list
>> Libusb-win32-devel@...
>> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Libusb-win32-devel mailing list
> Libusb-win32-devel@...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-win32-devel mailing list
Libusb-win32-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel

[Michael Plante]

Feng wrote:

>> >> "the device just has to FIFO/buffer (or discard!) its data until you
>> >> ask for it."
>>
>> Is that possible to get the FIFO address where the device is current
writing.?

No, it's not in your RAM.  The buffering I'm referring to has to happen in
the GPS device itself, and probably does.  What I'm saying is if you keep
reading it, the device will tell the OS it doesn't have any more, or it will
send you what it has.  (There is additional buffering in the OS, but I
wasn't talking about that.  It's convoluted, I know...)



>> My application of the USB device is to get the sampled GPS IF data,
>> not the measurements, so I cannot loss any data in the device, other,
>> the software receiver will loss track.

Okay, understood.  You're right then.  That is something better done in
hardware, but if that's all you have, you have the right idea.


>> Actually now, I have a temporary solution that, I will have a timer
>> interrupt in my code, and then the interrupt function will read the
>> data frequently to avoid overflow.

I'm not aware of interrupts in user-mode code.  Are you talking about
WM_TIMER messages?  Just be warned that they may not show up as often as you
expect, only when more-or-less idle, and when they do show up, there isn't a
backlog or anything, even if you missed them:  just one message per time
interval at most (except if you're doing weird stuff with PeekMessage).  So
you should consider adding temporary printf's of how long it's been since
the last one, so you can check it.  And you shouldn't necessarily expect to
read the same amount each time, even if you think you've carefully set the
time interval.

Michael


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-win32-devel mailing list
Libusb-win32-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel

[Michael Murphy-5]

"Michael Plante" <michael.plante@...> wrote:

>
> Feng wrote:
> >> 1) What is procedures of reading data, especially, what do the
> >> functions "usb_reap_async" and "usb_submit_async" do?
>
> Based on the question, this is someone else's code, not yours?  If I
> understand correctly, "submit" tells the OS to schedule the transfer, and
> "reap" cleans up (which involves getting the requested data back on a read).
> Evidently, usb_reap_async() can block for USB_TIMEOUT (a number you didn't
> include) in your case.  Take this with a grain of salt, as I've only used
> synchronous interfaces, and am figuring what I can from your code and the
> libusb source.  If you want to see a simpler example, you might read the
> source to _usb_transfer_sync().  It uses these functions.

Hi!

I've been lurking for some months and felt that a hello was long overdue.
And also, I would like to say a big thank you to the developers of this
important library :-)

As for the asynchronous library functions mentioned above... I posted a
little blog entry that some might find interesting...  I found some
clear-to-understand code developed by Kevin Kofler as part of the TI Calc
project.....

http://ee07m060.wordpress.com/2009/07/28/asynchronous-usb-transfers-using-libusb-win32/

Cheers,
Michael Murphy

--------------------------------

Asynchronous USB transfers using libusb-win32

The official documentation for the libusb-win32 library makes no mention
of the asynchronous API that the library provides.  Evidence of these
functions is to be found in the prototypes defined in the header file
usb.h that forms part of the source code for the win32 port of this
important library.

Those async functions are defined as follows:

        int usb_submit_async(void *context, char *bytes, int size);

        int usb_reap_async(void *context, int timeout);

        int usb_reap_async_nocancel(void *context, int timeout);

        int usb_cancel_async(void *context);

        int usb_free_async(void **context);

What still remains absent in the async API is any documentation on how to use it!

The clearest example of working async code that I have found was written
by Kevin Kofler. Kevin developed it as part of the USB codebase for the
Texas Instrument calculator project.  Here is a small excerpt of Kevins
code.  It should get you going with async USB transfers in Windows using
libusb-win32:

[..]
/* variables for slv_check and slv_bulk_read2 */

static int         io_pending = 0;
uint8_t            rBuf[64];
uint8_t*           rBufPtr;

[..]

static int slv_check(CableHandle *h, int *status) {

        int ret;

        if (!io_pending) {
                ret = usb_bulk_setup_async(uHdl, &context, TIGL_BULK_IN);
                if (ret < 0)
                        return ERR_READ_ERROR;

                ret = usb_submit_async(context, (char*)rBuf, max_ps);

                if (ret < 0) {
                        usb_free_async(&context);
                        return ERR_READ_ERROR;
                }
                io_pending = TRUE;
        }

        ret = usb_reap_async_nocancel(context, 0);

        if (ret < 0 && ret != -ETIMEDOUT) { // Error, unlink URB and return failure.
                usb_cancel_async(context);
                usb_free_async(&context);
                io_pending = FALSE;
                if (ret > 0) {
                        nBytesRead = ret;
                        rBufPtr = rBuf;
                        *status = STATUS_RX; // data available
                }
        }
        return 0;
}



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-win32-devel mailing list
Libusb-win32-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel

[Xu, Feng]

Hi Michael,

Thanks a lot.

On Wed, Oct 28, 2009 at 1:55 PM, Michael Plante
<michael.plante@...> wrote:

> Feng wrote:
>
>>> >> "the device just has to FIFO/buffer (or discard!) its data until you
>>> >> ask for it."
>>>
>>> Is that possible to get the FIFO address where the device is current
> writing.?
>
> No, it's not in your RAM.  The buffering I'm referring to has to happen in
> the GPS device itself, and probably does.  What I'm saying is if you keep
> reading it, the device will tell the OS it doesn't have any more, or it will
> send you what it has.  (There is additional buffering in the OS, but I
> wasn't talking about that.  It's convoluted, I know...)

It is sad that I cannot do that. It is always better if you exactly
know how many data remaining to process.
The real time operation is still a big issue in the software receiver,
it is not good that data just chasing after you.

>
>>> My application of the USB device is to get the sampled GPS IF data,
>>> not the measurements, so I cannot loss any data in the device, other,
>>> the software receiver will loss track.
>
> Okay, understood.  You're right then.  That is something better done in
> hardware, but if that's all you have, you have the right idea.
Yeah. But the software receiver is becoming more popular because no
other hardware in required now. :)

>
>>> Actually now, I have a temporary solution that, I will have a timer
>>> interrupt in my code, and then the interrupt function will read the
>>> data frequently to avoid overflow.
>
> I'm not aware of interrupts in user-mode code.  Are you talking about
> WM_TIMER messages?  Just be warned that they may not show up as often as you
> expect, only when more-or-less idle, and when they do show up, there isn't a
> backlog or anything, even if you missed them:  just one message per time
> interval at most (except if you're doing weird stuff with PeekMessage).  So
> you should consider adding temporary printf's of how long it's been since
> the last one, so you can check it.  And you shouldn't necessarily expect to
> read the same amount each time, even if you think you've carefully set the
> time interval.

Thanks a lot. Seems it is not good idea.
I am thinking about your previous suggestions about multiple-threads method.
It will be a good one that I have a separate thread to read the data,
then have another one to process the data.

Feng

> Michael
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Libusb-win32-devel mailing list
> Libusb-win32-devel@...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-win32-devel mailing list
Libusb-win32-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel

[Xu, Feng]

Hi Michael,

Thanks for the example.
But I am still curious that what will happen in the USB device after
the async functions 'submit' 'reap'....
And what will be returned.

Regards,

Feng

On Thu, Oct 29, 2009 at 5:01 AM, Michael Murphy <qmul@...> wrote:

>
> "Michael Plante" <michael.plante@...> wrote:
>>
>> Feng wrote:
>> >> 1) What is procedures of reading data, especially, what do the
>> >> functions "usb_reap_async" and "usb_submit_async" do?
>>
>> Based on the question, this is someone else's code, not yours?  If I
>> understand correctly, "submit" tells the OS to schedule the transfer, and
>> "reap" cleans up (which involves getting the requested data back on a read).
>> Evidently, usb_reap_async() can block for USB_TIMEOUT (a number you didn't
>> include) in your case.  Take this with a grain of salt, as I've only used
>> synchronous interfaces, and am figuring what I can from your code and the
>> libusb source.  If you want to see a simpler example, you might read the
>> source to _usb_transfer_sync().  It uses these functions.
>
> Hi!
>
> I've been lurking for some months and felt that a hello was long overdue.
> And also, I would like to say a big thank you to the developers of this
> important library :-)
>
> As for the asynchronous library functions mentioned above... I posted a
> little blog entry that some might find interesting...  I found some
> clear-to-understand code developed by Kevin Kofler as part of the TI Calc
> project.....
>
> http://ee07m060.wordpress.com/2009/07/28/asynchronous-usb-transfers-using-libusb-win32/
>
> Cheers,
> Michael Murphy
>
> --------------------------------
>
> Asynchronous USB transfers using libusb-win32
>
> The official documentation for the libusb-win32 library makes no mention
> of the asynchronous API that the library provides.  Evidence of these
> functions is to be found in the prototypes defined in the header file
> usb.h that forms part of the source code for the win32 port of this
> important library.
>
> Those async functions are defined as follows:
>
>        int usb_submit_async(void *context, char *bytes, int size);
>
>        int usb_reap_async(void *context, int timeout);
>
>        int usb_reap_async_nocancel(void *context, int timeout);
>
>        int usb_cancel_async(void *context);
>
>        int usb_free_async(void **context);
>
> What still remains absent in the async API is any documentation on how to use it!
>
> The clearest example of working async code that I have found was written
> by Kevin Kofler. Kevin developed it as part of the USB codebase for the
> Texas Instrument calculator project.  Here is a small excerpt of Kevins
> code.  It should get you going with async USB transfers in Windows using
> libusb-win32:
>
> [..]
> /* variables for slv_check and slv_bulk_read2 */
>
> static int         io_pending = 0;
> uint8_t            rBuf[64];
> uint8_t*           rBufPtr;
>
> [..]
>
> static int slv_check(CableHandle *h, int *status) {
>
>        int ret;
>
>        if (!io_pending) {
>                ret = usb_bulk_setup_async(uHdl, &context, TIGL_BULK_IN);
>                if (ret < 0)
>                        return ERR_READ_ERROR;
>
>                ret = usb_submit_async(context, (char*)rBuf, max_ps);
>
>                if (ret < 0) {
>                        usb_free_async(&context);
>                        return ERR_READ_ERROR;
>                }
>                io_pending = TRUE;
>        }
>
>        ret = usb_reap_async_nocancel(context, 0);
>
>        if (ret < 0 && ret != -ETIMEDOUT) {             // Error, unlink URB and return failure.
>                usb_cancel_async(context);
>                usb_free_async(&context);
>                io_pending = FALSE;
>                if (ret > 0) {
>                        nBytesRead = ret;
>                        rBufPtr = rBuf;
>                        *status = STATUS_RX; // data available
>                }
>        }
>        return 0;
> }
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Libusb-win32-devel mailing list
> Libusb-win32-devel@...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-win32-devel mailing list
Libusb-win32-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel