Data acquisition from USB port.

Naeem schrieb:

At this point, it's not possible to help you, only to do the job for you. Please read something about USB and how does it works.

HTH Michael

Ian Bell schrieb:

Your answer is well-meant, by as you can see in the question, it looks like the OP newer used google bevore, nor reading something about USB. He gathered the prolem is on his Compaq P3, but in fact it's more an ISO layer 8 problem ;-)

Michael

What OS are you using, Windows or Linux? In Linux it is dead easy because everything is a file. So you just open that USB device and read from it.

Ian

I am using Microsoft Windows 98. Due to security reasons in NT, it is not possible to access a port directly.

Please quote articles properly when following up posts, preferably using a different interface to googlegroups.

As another poster has said go do some basic research on how USB work and go to the URLs posted.

It is obvious you either know nothing about how USB works in software and operating system software interfaces.

BTW I am not aware of ANYBODY who has added USB support to Windows NT so accessing a port directly does not enter the equation.

-- Paul Carpenter | snipped-for-privacy@pcserviceselectronics.co.uk PC Services GNU H8 & mailing list info For those web sites you hate

The USB is a master-slave bus where the master does most of the protocol work. In your setup, the PC has to be the USB master, so it has to take care of the USB bus control. It does not happen with a couple of simple port reads and writes.

Please learn to use Google and get some basic information about USB before attempting to continue otherwise.

On 18 Sep 2005 00:47:28 -0700, "Naeem" wrote in comp.arch.embedded:

The x86 i/o port functions will not help you in the slightest, USB has nothing to do with that kind of i/o ports.

As others have suggested, you need to understand a lot more about USB. You cannot possibly just try to communicate directly with the hardware, you need to go through the operating system's USB drivers.

Windows 98, at lease second edition, has USB drivers. Windows NT does not, and never will.

When you understand more about USB, you might try asking in a Windows programming group like news:comp.os.ms-windows.programmer.win32.

There's a cheater way and an easy way and a hard way and an outrageously hard way:

Cheater way: find a program that does what you want

Easy way: find the Video for Windows (VFW) or WDM driver for the webcam (chances are it's already installed) and read up on the function calls to get data from it. Or cheat and look at an open source project that does this, like virtualdub.

Hard way: use libusb to let a user mode program talk on the usb and then learn to talk to the webcam

Outrageously hard way: get the windows driver development kit and write your own usb driver that interacts with windows more intimately

But there are drivers you can get which will pass this capability through to a user mode program - a security risk of course, but in an experimental environment it could be a warranted one.

In this case though, you don't want a raw I/O enabler but rather a USB protocol enabler... or more usefully, the existing driver for the camera.

With something like giveio.sys, you can access a port directly under Windows 2000 or XP. Under cygwin you can use ioperm, which is also available under Linux.

Regards Anton Erasmus

Granting low-level port-I/O privledges to talk to the USB controller chip is pretty trivial (at least under Linux, I don't know about WinXXXX).

OTOH, writing a user-space driver for the USB chip and implimenting the host-side USB protocols is a a fair bit of work. I'd guess something on the order of several man years if you want to do something general purpose.

If you're only going to support 1 particular sort of slave (e.g. serial-port), then it might not be so bad, but it's still going to be a lot of work. USB host side stuff is pretty complex from what I can tell (I've never actually done it).

That estimate is probably a bit OTT, but not by much.

As someone who has actually done a simple USB host stack implementation, I can confirm that the USB host requirements are indeed complex, at least when using USB for general purpose applications.

In my case I just wanted to use the USB ports as a cheap method of linking known external devices to a x86 embedded system running an RTOS (in this case RTEMS) that didn't support USB, so I only needed to treat the USB bus as any other bus, with the hub code assigning USB addresses on the basis of a hardcoded configuration table.

All device specific processing (ie: device setup and upper level protocols) is done by the application and not by kernel drivers.

To implement this for a UHCI controller took about several weeks of spare time (this was for a hobby project), but a general purpose stack + a full array of kernel drivers could easily take most of a man year IMHO.

And before anyone asks, no, the code is not available... :-)

Simon.