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

[Xu, F. <fen...@gm...>]

Hi Michael,

Thanks a lot.

On Wed, Oct 28, 2009 at 1:55 PM, Michael Plante
<mic...@gm...> 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
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>