Re: [Libusb-win32-devel] About the GN3S application and lib functions"usb_reap_async" and "usb_submit_async"

[Michael P. <mic...@gm...>]

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:fen...@gm...]
Sent: Wednesday, October 28, 2009 12:55 PM
To: mic...@gm...; lib...@li...
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
<mic...@gm...> 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
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>