Announcement

**Kev Peel** · 30 Dec 2007, 08:43 AM

Depending on the device, you usually need to install the device's driver which should provide a COM port through which you can send/receive data using PB's COMM functions. I have communicated with many USB devices this way. I have also wrote code that calls USB.DLL to do the communication, so it' perfectly possible depending on the device and it's driver support.

You will be stuck if you do not have a driver, as it is not possible to write device drivers using PB, as they are in a different format (VXD, SYS) to the win32 PE executables that PB generates.

**Bill Eppler** · 30 Dec 2007, 10:01 AM

As Kevin states, many USB devices install themselves as 'Virtual Comm. Ports'.
You communicate with them as if they were true serial ports using PB's COMM function.

USB Flash drives are seen by the OS as virtual disk drives, so PB's OPEN, WRITE, PUT, etc. can be used.

Just about anything else, you need access to the specific driver, usually through a DLL. If this isn't provided by the manufacturer, you may be SOL.

BTW if the device in question uses FTDI USB chips, complete info is available from their web site (www.ftdichip.com).

**Gary Peek** · 30 Dec 2007, 10:55 AM

Virtual Comm Cort, yes I am familiar

Kev:I have communicated with many USB devices this way. I have also wrote code that calls USB.DLL ...."

Gary:
Thank you, that is helpful. What is "USB.DLL"? Does it have a list of API functions? Do you have a few lines of code to show what you did?

Kev and Bill, thank you, I know about the USB to virtual serial port chips, etc., those make it easy.

**Peter Lameijn** · 30 Dec 2007, 01:58 PM

If I need software to connect to hardware through USB, and the data throughput is only small, I always try to use the HID class. This because it can use Windows built-in driver, so it's easy to install, and there is no problem with connecting and disconnecting at the USB bus.
(I've seen some dedicated drivers that were poorly written and even would give you a BSOD when unplugging without stopping the device first...)

**Cliff Nichols** · 30 Dec 2007, 05:56 PM

Gary forms a good point as I am working along the same lines as to the basics of USB....and yes USB complete from Jan Axelson I have to agree is the closest to the "Rosetta Stone" as I have gotten.

Peter is right with

If I need software to connect to hardware through USB, and the data throughput is only small, I always try to use the HID class. This because it can use Windows built-in driver, so it's easy to install, and there is no problem with connecting and disconnecting at the USB bus.

Most (not all) devices have at least a HID class interface, (although I am still beginning, so this is only my best guess to date), but USB complete also shows other "Device Specific" classes, so I am not 100% yet.

Roughly translated form Kev and Bill

As Kevin states, many USB devices install themselves as 'Virtual Comm. Ports'.
You communicate with them as if they were true serial ports using PB's COMM function.

USB Flash drives are seen by the OS as virtual disk drives, so PB's OPEN, WRITE, PUT, etc. can be used.

Just about anything else, you need access to the specific driver, usually through a DLL. If this isn't provided by the manufacturer, you may be SOL.

SOL is close, but not quite in all cases.

USB seems to be a bit of a "Secret Society" that everyone knows what it does, and use it, but hardly anyone is willing to fess up "HOW" to use it. The good part is most have some sort of HID interface, so there is always some sort of work-around, or have a Virtual COM so you can treat it as a serial port. The bad part is device specific ones that you are limited to the programmer that wrote the driver (dll) to interface the device if it is specific. (In most of my limited experience, the hardware is GREAT, and the software sucks so bad that it barely works)

For example my USB Rocket Launcher I got a year ago for Xmas, the hardware worked great, but the software sucked so bad that it would crash constantly, and only aim in 4 directions, then a lil reverse engineering (watching the port) I took a few good guesses that I added up to 8 simultaneous directions (N,S,E,W, and the points between) to make it functional.

Anyways back to point, Gary I think you mis-spoke when you said

Well, someone wrote the DLL for the Prism called "betabriteusb.dll", and PB
has been noted to be very good for writing DLL's

NOT true...PB does EXCELLENT dll's, the only thing it does not do is low level machine level dlls (like accessing serial ports directly, rather than build on the Windows Kernel level)

Gary I understand your comment of

I have heard a few people state (including some PB folks) that have said
something to the effect of "applications shoud not have to concern
themselves with talking to USB ports" or something of that general idea.
But applications talk to serial ports, and PB has good support for that. Since
USB ports have been replacing serial ports on PC's, it sure makes sense that
an application programmer should be able to program a USB port more easily
that they now can.

and my thought of "Only because of HID, or if you really delve into the complexity of USB. (I am working on it, but hitting the same sort of roadblocks myself) and since it was my idea that the next version of my software should include USB rather than just Virtual COM's or a USB to RS232 Adapter just because USB has been so widely accepted, now wondering what the heck I was smoking when I said USB was the way to go?

**Gary Peek** · 31 Dec 2007, 09:02 AM

DLL, INF, HID, too many TLA's

Cliff, I see you have thought a lot about this too, so thanks for your insights.

"PB does EXCELLENT dll's, the only thing it does not do is low level machine
level dlls"

Yep, good way of putting it. I understand.

"The good part is most have some sort of HID interface..."

Do you know how I would go about finding out if the Prism has this,
or what PB code I could use to even try it?

Another thing I thought of later was that perhaps the low level DLL that
is supplied (for example, betabriteusb.dll) uses the information in the
.INF file to look only for a USB Bulk device with the Vendor ID of the
Prism. I can't say that I know how this all works.

And by the way, for anyone else following this thread, yes, if I were designing
a USB only device, it would be with the FTDI FT232R, which is a Virtual Com
Port chip. I prototyped one and it works as advertised, so I'm ready to go.

**Bill Eppler** · 31 Dec 2007, 09:45 AM

FWIW - I've designed several pieces of USB hardware using the FTDI 232 & 245 parts.

I generally use the D2XX driver option for greater flexibility. You can obtain you very own range of PIDs from the manufacturer for a more custom device appearance (to the OS). A PB port of the D2XX functions can be found at somewhere here as well.

**Cliff Nichols** · 31 Dec 2007, 10:01 AM

Gary,
Sounds like you are doing exactly the same thing I am doing. A USB to RS232 chip (but in my case Silicon Labs).
If you are doing what I think you are doing, then (Yes, about to reference USB complete and LVR again), what you want is P.302 of the USB complete book.

I am working on (Yet ANOTHER) port from code here, and USB complete for a generic code, but taking a lot longer than I 1st thought (learning curve).

If its of any help you may want to look at 2 codes I posted recently in the Source-Code forum. List USB info (VID, PID,Revision, etc) and Available Serial Ports

Hopefully my latest Port will be of even more help. but at the moment involves a table lookup of thousands of possible USB devices, so I need to find a way to trim down the data. (Or just post a snippet, and link the whole project to one of my webpages for the full source code?)

Hopefully done sometime this week, but like I said, its a heck of a learning curve

**Gary Peek** · 31 Dec 2007, 11:13 AM

If you are referring to the Silicon Labs CP2101, well, I've been down that
road already and don't like it. It's a decent chip but the MLP-28 chip
package is unbearable.

I have also found that the FTDI VCP chips are more likely to work, while
some of the other chips have buffer and timing issues with some software.
I think this is because these chips are based on programmable logic (that is
more like straight hardware) rather than a microcontroller with a USB stack.

I saw your other posts and code and will look forward to anything else I see.

The excerpts of code in USB Complete may be wonderful for understanding
the details of USB but they just don't do much for me in getting something
written. A good example would be worth a lot.

If you want to call me to talk about any of this, (800) 435-1975, 9-5 central.

**Cliff Nichols** · 31 Dec 2007, 11:51 AM

If you are referring to the Silicon Labs CP2101, well, I've been down that
road already and don't like it. It's a decent chip but the MLP-28 chip
package is unbearable.

Actually the CP2103, but same difference

The documentation I was able to get is sorely in need of being re-written for users that were not involved in the development of the chip

(Little things like "The answer is 42"

, "Ummmmmkayyyyy but WHY??? is the answer 42?, what does 42 mean?" kind of things)

Then I started noticing "Patterns" in the documentation depending on the API function I wanted to call, and realized most answers were some binary reply that could be multiple answers at once that I still need to break down to readable code.

I have also found that the FTDI VCP chips are more likely to work, while
some of the other chips have buffer and timing issues with some software.

Actually from my tests it is usually some bad implementation in the "Virtual Com" side with an advanced setting usually not used, but some devices use and can block your functions if not aware of the setting.

Over lunch I was re-reading some of the USB complete and noticed in the Acknowledgements was Dave Navarro from Powerbasic. So if he is around, may be able to help?

Currently I am working on porting examples from USB complete from VB to PB (or more specifically the "Finding a Device" functions) that I hope to piece together for a functional example of accessing a USB device. (Hopefully generic, and not vendor-specific)

**Cliff Nichols** · 3 Jan 2008, 04:30 PM

Gary,
I got a mostly running example going. I still have some more "Database" cleanup, and more overcommenting to do, but this will give you a basic idea of what I am working on.

List Devices, Vid, Pid, Revision, etc

It is a work in progress, so I welcome any ideas, suggestions, errors I made etc, so that eventually I can make a INC to offer.

The "Database" of sorts is far from complete (as I learned today), but getting closer, so I welcome any VID,PID, and other info possible that anyone can offer on a device they have and this sample does not show "User Friendly" names for.

If you find it useful, or can offer some input, or have questions, let me know

And Yes, I am still working on the "Generic" access USB idea, but this gets me one step closer to the concept without having to be "Device Specific". (Although it is quickly becoming apparent to me, that once I can access the device, I still have to know how to talk to it, but that is a matter for the device's user-manual)

**Gary Peek** · 7 Jan 2008, 12:11 PM

RTFM'ing, yes!

Cliff, you've done a lot there. I ran it and took a look around.
I'll be studying it more later. Yes, we all have a lot of RTFM'ing
to do.

Announcement

Let's talk about USB programming again

Let's talk about USB programming again

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment