Help with Reading USB Pipe

[Psychopete]

Hello,

I am developing an application that reads ADC values from a AVR microprocessor via USB. I am developing on a machine with Windows 2000 and Visual C++ 6.0. Right now it is a DLL file that I am porting into Visual Basic so that building the interface would be less time comsuming. But if I need to do it all in VC++, then so be it; I am just lacking in this area as this is not where my experience lies.

I have the USB functionality working, what I would like to pick your brains at is the way I am reading it. I have looked into libusb-win32 and it looks like I've already developed what it does, and with non-blocking I/O support (which apparently libusb doesn't support?).

I am currently doing an overlapped read on the pipe within a loop that calls it constantly from VB. I programmed my microprocessor to send a basic recognizable chunk of data every second and monitored when exactly I was able to read something. Well, I am missing data - a lot of it. I thought it would be fast enough to get the data on the pipe, but it's not.

I think I am losing a lot of time in calling the external DLL file from VB. What I am thinking of is making the DLL in VC++ "multi-threaded". The plan is to store what I find in a buffer that will be emptied once the VB program calls it.

Here is the question -
If I go multi-threaded, would it make sense to keep the non-blocking/overlapped reads, or just do a blocking read and wait until USB data is available on a separate thread?

I am very lacking in threading knowledge in VC++, but have dealt with threads before in C (Linux). Any reccomendations to what I have going on here, or any good suggestions on thread documentation that would get me in the right direction?

Thanks in advance,
Pete

[Computergeek01]

You may run into a problem where Win2K doesn't do true multithreading like WinXP and up do. That is to say it will "support" the feature but will not actually process more then one thread at a time. I swear I remember that being a new feature to XP, but then again I'm thinking back almost half my life time so I could be wrong on some detail or another. Support for MT may also have been added to 2K via Service Pack, in which case I'm sorry I wasted your time.

Have you tried calling the DLL 'inline' with the calling function? This may help a bit, or it could just thrash your HDD for a while, but it may be worth a shot.

[Psychopete]

Ah, I didn't even know or think about that. I've actually been thinking about "upgrading" the computer to XP soon. I will be developing a lot of the thread code on an XP machine, so I guess we will see what happens when I compile and run the code under 2k. Thank you for the suggestion.

I am not sure what you mean by calling it inline, here is an example of how I am doing it now:

Similar to: declare sub test1 lib "x.dll" alias "test" (x as byte)
(I don't have the source handy right now)

But I have a few functions, connectUSBDevice, readUSBDevice, and closeUSBDevice.

connectUSBDevice makes the connection,
readUSBDevice does an non-blocking I/O read on the pipe I opened,
closeUSBDevice closes it.

No luck threading properly in VB, so right now I am looking at creating worker thread in my DLL file to do the reads. Do you think it would be best to continue to use non-blocking reads and constantly peek for data on the pipe, or to wait in the thread until USB data is available? I think I am going to shoot for the latter and see what kind of results I can get.

[Computergeek01]

Saying which method to use is going to be dependent on how your device feeds data into the system. As long as you back up your data you've got nothing to lose except time right?