>> I know that the built-in USB on the DS10 is not supported - what a
>> shame....
>
> Is that still true? I thought that the built-in for the XP1000 _was_
> supposed to work now. (I added cheap Chinese cards with the NEC chip to
> mine, so I never tried to get the built-in stuff to work.)

The built in controller in the DS10 was never supported. Shortly after
the
hardware was released the firmare team made the decision to hide it from the
O.S.

>
>> I have seen comments that USB can work with the NEC chipset on the
>> Belkin F5u220 card - a five port USB card.
>
> NEC does make more than one chip, so the actual number might matter,
> but let's assume...

They make two HIGH speed chips both work, one was for the 0.95 version
of the EHCI specification and one was for the 1.0. On Alpha where we only
support the OHCI parts it does not make any difference.

>
> Again, working from memory, I believe that there's a template
> UGDRIVER somewhere (on V8.3, SYS$EXAMPLES?) which might tell you
> something. (Google can find some interesting UGDRIVER-related things,
> too.)

UGDRIVER is not a template driver, it is a way for a user to get control
of a USB device and communicate with it. We have a number of examples
in sys$examples as well as some I have made available over the years.

There is no supported way to write a USB driver outside of confines of
the
OpenVMS group. We do not ship any of the include files you need to build
a USB driver.


Forrest

forrret.kenney@hp.com_nospam wrote:
>>> I know that the built-in USB on the DS10 is not supported - what a
>>> shame....
>> Is that still true? I thought that the built-in for the XP1000 _was_
>> supposed to work now. (I added cheap Chinese cards with the NEC chip to
>> mine, so I never tried to get the built-in stuff to work.)
>
> The built in controller in the DS10 was never supported. Shortly after
> the
> hardware was released the firmare team made the decision to hide it from the
> O.S.
>
>>> I have seen comments that USB can work with the NEC chipset on the
>>> Belkin F5u220 card - a five port USB card.
>> NEC does make more than one chip, so the actual number might matter,
>> but let's assume...
>
> They make two HIGH speed chips both work, one was for the 0.95 version
> of the EHCI specification and one was for the 1.0. On Alpha where we only
> support the OHCI parts it does not make any difference.
>
>> Again, working from memory, I believe that there's a template
>> UGDRIVER somewhere (on V8.3, SYS$EXAMPLES?) which might tell you
>> something. (Google can find some interesting UGDRIVER-related things,
>> too.)
>
> UGDRIVER is not a template driver, it is a way for a user to get control
> of a USB device and communicate with it. We have a number of examples
> in sys$examples as well as some I have made available over the years.
>
> There is no supported way to write a USB driver outside of confines of
> the
> OpenVMS group. We do not ship any of the include files you need to build
> a USB driver.
>
>
> Forrest
>
>

Is there some reason you can't/won't ship those include files? If you
have no plans to support USB they would seem to be without commercial
value to HP. It would seem to me to be possible to offer them as
"Unsupported, we will not be responsible. . . . Have fun playing with
them. . . ."

> Is there some reason you can't/won't ship those include files? If you
> have no plans to support USB they would seem to be without commercial
> value to HP. It would seem to me to be possible to offer them as
> "Unsupported, we will not be responsible. . . . Have fun playing with
> them. . . ."

Not sure where you got the idea we have no plans on supporting USB.
I am busy writing a driver to support a new USB controller what will
be in the next generation Blades. I just finished a major addition to the
USB SDA extension along with better address handling and an all new
help. We are still actively doing USB work.

What we have no plans to do is support third party USB device drivers.
There are lots of reasons, we on occasion makes big changes in key routines
in the USB support layer. We have done some substantial reworking of key
data structures as well. The minute we release the include files even under
the
not supported banner we loose the flexibility to make these changes as
needed. Since 1998 I have had ONE request from a third party about
writing a driver. We gave them a code drop and never heard another
thing from them.

So with no demand and faced with a choice of spending time documenting
and formalizing all the include files, support routines, and loose to
freedom to
make wholesale changes at any time. I did a driver that allows anyone to
control a USB device using $QIO. To date I have received zero requests for
help with it or a bug report. The demand is just not there to do custom
USB device support for VMS.


Forrest

forrret.kenney@hp.com_nospam wrote:

> There is no supported way to write a USB driver outside of confines of
> the
> OpenVMS group. We do not ship any of the include files you need to build
> a USB driver.

Just a comment:

If no further serious development is to be made on the USB services on
Alpha VMS, perhaps VMS engineering could convince their management it
should be OK to release those files so that those who wish to develop
their own could.

Hi List,

Thanks for your answers. Some great pointers in there.

BTW I have VMS 8.3 and the device is FTDI RS232R. I want to write a
user space USB driver and the UGDRIVER looks ideal.

The one thing I am unsure of is to do with the Belkin card I have.

Can I use all five USB ports on the card?

Thanks

David

wrote in message
news:57260f99-ac5d-469c-9a2a-00ed3b3ee69e@r15g2000prh.googlegroups.com...
> Hi List,
>
> Thanks for your answers. Some great pointers in there.
>
> BTW I have VMS 8.3 and the device is FTDI RS232R. I want to write a
> user space USB driver and the UGDRIVER looks ideal.
>
> The one thing I am unsure of is to do with the Belkin card I have.
>
> Can I use all five USB ports on the card?
>
I thought I made it clear that all 5 port work. Some go to
the first OHCI controller the rest go to the other. Also don't
be surprised if you plug you FTDI RS232 device in that it get
claimed by the O.S. In V8.3 for both Alpha and IA64 we
ship drivers and configuration data for the FTDI 232 controller.
It should show up as TXC0.


Forrest

"JF Mezei" wrote in message
news:48dff60a$0$1527$c3e8da3@news.astraweb.com...
> forrret.kenney@hp.com_nospam wrote:
>
>> There is no supported way to write a USB driver outside of confines
>> of
>> the
>> OpenVMS group. We do not ship any of the include files you need to build
>> a USB driver.
>
> Just a comment:
>
> If no further serious development is to be made on the USB services on
> Alpha VMS, perhaps VMS engineering could convince their management it
> should be OK to release those files so that those who wish to develop
> their own could.

The USB driver code is common and other than a small number of
conditionals
for alpha console support for the GS1280 and ES47 what gets compiled for
IA64 gets compiled for Alpha. As much as possible it will remain that way
for
as long as I have any say in the USB code stream.


Forrest

Hi List,

Thanks for the comments.

Looks like my Belkin card is faulty as I am getting bugcheck 215 every
time I boot my system. Bugchecks SDA.EXE.

If I find another card - what do I need to do to stop the OS hijacking
my device?

Do you match on Vendor and Product ID or another method to determine
the driver to load?

I have my own non standard Product ID on my device.

Thanks again for the useful answers.

David.

>
> If I find another card - what do I need to do to stop the OS hijacking
> my device?
>
> Do you match on Vendor and Product ID or another method to determine
> the driver to load?
>
If you look in sys$examples there is a USB section. There is a document
on using UGDRIVER. If you look in there you will find a really complete and
detailed write up on how devices get matched.


Forrest

"forrret.kenney@hp.com_nospam" writes:

> If you look in sys$examples there is a USB section. There is a document
>on using UGDRIVER. If you look in there you will find a really complete and
>detailed write up on how devices get matched.

Forrest, you mentioned in another post that you didn't get any feedback or
bug reports re your usb driver. Well I have something.

Your UG_EXAMPLE in SYS$EXAMPLES is a little program for Rat Shack terminal
adapters. Not having that I tried it with a Digiboard 16 port terminal
mux, changing the vender ID as needed. For the SENSMODE $QIO specifying
UG$_GET_PIPE_COUNT I get an absurd value returned. In addition the
UG$_GET_PIPE_HANDLES calls ACCVIOs even if I patch the pipe count to a
reasonable value. Are the USB QIOs specific to the specific terminal
adapter or for any USB widget?

"Michael Moroney" wrote in message
news:gc3blj$mmq$2@pcls4.std.com...
> "forrret.kenney@hp.com_nospam" writes:
>
>> If you look in sys$examples there is a USB section. There is a
>> document
>>on using UGDRIVER. If you look in there you will find a really complete
>>and
>>detailed write up on how devices get matched.
>
> Forrest, you mentioned in another post that you didn't get any feedback or
> bug reports re your usb driver. Well I have something.
>
> Your UG_EXAMPLE in SYS$EXAMPLES is a little program for Rat Shack terminal
> adapters. Not having that I tried it with a Digiboard 16 port terminal
> mux, changing the vender ID as needed. For the SENSMODE $QIO specifying
> UG$_GET_PIPE_COUNT I get an absurd value returned. In addition the
> UG$_GET_PIPE_HANDLES calls ACCVIOs even if I patch the pipe count to a
> reasonable value. Are the USB QIOs specific to the specific terminal
> adapter or for any USB widget?
>

The digi device is werid in so many ways as to not be funny. You have
to do a
whole raft of setup steps before the data it gives back make any sense.

This is one of those cases where you cannot extrapolate how device X
needs to
be treated for device Y. The get pipe count data is just the number the
device returns
in it's interface descriptor. So if it gave UG garbage I give you garbage.
In the case
of the digi I know until it gets set up correctly much of the data it
returns is not to
be trusted.

If you get a crash from get pipe handles I would like to see it. If you
have a support
contract file a problem report as well. Makes it easier to get a fix
checked in. In either
case I need to see the dump.


Forrest

"forrret.kenney@hp.com_nospam" writes:


>"Michael Moroney" wrote in message
>news:gc3blj$mmq$2@pcls4.std.com...
>> "forrret.kenney@hp.com_nospam" writes:
>>
>>> If you look in sys$examples there is a USB section. There is a
>>> document
>>>on using UGDRIVER. If you look in there you will find a really complete
>>>and
>>>detailed write up on how devices get matched.
>>
>> Forrest, you mentioned in another post that you didn't get any feedback or
>> bug reports re your usb driver. Well I have something.
>>
>> Your UG_EXAMPLE in SYS$EXAMPLES is a little program for Rat Shack terminal
>> adapters. Not having that I tried it with a Digiboard 16 port terminal
>> mux, changing the vender ID as needed. For the SENSMODE $QIO specifying
>> UG$_GET_PIPE_COUNT I get an absurd value returned. In addition the
>> UG$_GET_PIPE_HANDLES calls ACCVIOs even if I patch the pipe count to a
>> reasonable value. Are the USB QIOs specific to the specific terminal
>> adapter or for any USB widget?
>>

> The digi device is werid in so many ways as to not be funny. You have
>to do a
>whole raft of setup steps before the data it gives back make any sense.

Is this a one-time setup or something that has to be done every time? Does
the VMS driver (TXDx do the correct thing with them? I ask because we're
using a few of them. Two show up with some ports offline some online.
They work OK from PCs.

> If you get a crash from get pipe handles I would like to see it. If you
>have a support
>contract file a problem report as well. Makes it easier to get a fix
>checked in. In either
>case I need to see the dump.

This isn't a system crash, just the $QIO SENSEMODE/UG$_GET_PIPE_HANDLES
returns an ACCVIO status.

We do have a support contract so if there is something special to get all
the ports working on a Digi box using the VMS terminal driver I can open a
problem report. The UG_EXAMPLE.C stuff is just me playing, however.

> Is this a one-time setup or something that has to be done every time?
> Does
> the VMS driver (TXDx do the correct thing with them? I ask because
> we're
> using a few of them. Two show up with some ports offline some online.
> They work OK from PCs.
>
That needs to get reported, we need to know a fair amount about them as
Digi shipped products with the same order number with 100% different
electronics.

OK, so here at a high level is what happens. We based on vendor and
product ID's decide if we need to load UCE or UCF driver. These
driver know the correct initialization sequence for the controller. One
of the things it does if determine how many ports there are and how to
map them to terminal ports. This is not nearly as neat and clean as you
would expect. Lots of steps and lots of ways to get it wrong.

I did not write UCE or UCF drivers so I don't have all the details
I handed off all the USB to RS232 drivers to someone else after
I wrote the code for the PL2303 and FTDI 232 devices.

>> If you get a crash from get pipe handles I would like to see it. If
>> you
>>have a support
>>contract file a problem report as well. Makes it easier to get a fix
>>checked in. In either
>>case I need to see the dump.
>
> This isn't a system crash, just the $QIO SENSEMODE/UG$_GET_PIPE_HANDLES
> returns an ACCVIO status.
>
> We do have a support contract so if there is something special to get all
> the ports working on a Digi box using the VMS terminal driver I can open a
> problem report. The UG_EXAMPLE.C stuff is just me playing, however.
>
Fine I wanted to make sure there was not a nasty crash in there that I
did not know
about. There is nothing about the weird pipe count I can do, the device
apparently
returned a crappy value and I just passed it along.

But please report this to the support organization the digi controllers
are supported and are supposed to work correctly. The only way this
will get fixed is opening a support call.

Forrest

>
> But please report this to the support organization the digi controllers
> are supported and are supposed to work correctly. The only way this
> will get fixed is opening a support call.

If you file a report do the following.

1) UCM set log/new
2) Unplug the digi controller and plug it back in
3) UCM sho event/type=all/out=config_error.txt

Include this file in the problem report. It will tell us what went on
as part of the configuration of the device.


Forrest

"forrret.kenney@hp.com_nospam" writes:

>> Is this a one-time setup or something that has to be done every time?
>> Does
>> the VMS driver (TXDx do the correct thing with them? I ask because
>> we're
>> using a few of them. Two show up with some ports offline some online.
>> They work OK from PCs.
>>
> That needs to get reported, we need to know a fair amount about them as
>Digi shipped products with the same order number with 100% different
>electronics.

OK, will do.

> OK, so here at a high level is what happens. We based on vendor and
>product ID's decide if we need to load UCE or UCF driver. These
>driver know the correct initialization sequence for the controller. One
>of the things it does if determine how many ports there are and how to
>map them to terminal ports. This is not nearly as neat and clean as you
>would expect. Lots of steps and lots of ways to get it wrong.

Oh, one of those.

>> This isn't a system crash, just the $QIO SENSEMODE/UG$_GET_PIPE_HANDLES
>> returns an ACCVIO status.
>>
>> We do have a support contract so if there is something special to get all
>> the ports working on a Digi box using the VMS terminal driver I can open a
>> problem report. The UG_EXAMPLE.C stuff is just me playing, however.
>>
> Fine I wanted to make sure there was not a nasty crash in there that I
>did not know
>about. There is nothing about the weird pipe count I can do, the device
>apparently
>returned a crappy value and I just passed it along.

Having done device drivers myself, I perfectly understand GIGO. However,
not knowing too much detail of USB, I would think that something that is
common to any USB device like the number of pipes would be the same
everywhere. But if it doesn't, it doesn't.

> But please report this to the support organization the digi controllers
>are supported and are supposed to work correctly. The only way this
>will get fixed is opening a support call.

> Having done device drivers myself, I perfectly understand GIGO. However,
> not knowing too much detail of USB, I would think that something that is
> common to any USB device like the number of pipes would be the same
> everywhere. But if it doesn't, it doesn't.
>

Oh if it were that simple. A USB device is a collection of interfaces a
device has to have at least one interface, and one pipe. It can have
multiple
interfaces and multiple pipes. On top of that each interface can have
multiple
possible configurations. As well as a device can have multiple components.
For example you have a printer and a scanner that is one USB device with a
printer interface which can be uni-directional, bi-directional, etc. Each
of
these components can have multiple pipes.

Configuring even a simple device is a pretty complex operation.


Forrest

"forrret.kenney@hp.com_nospam" writes:

> Oh if it were that simple.
....
> Configuring even a simple device is a pretty complex operation.

Really. How does "plug and play" work so well on PCs?

"Michael Moroney" wrote in message
news:gc5sv5$i7t$1@pcls6.std.com...
> "forrret.kenney@hp.com_nospam" writes:
>
>> Oh if it were that simple.
> ...
>> Configuring even a simple device is a pretty complex operation.
>
> Really. How does "plug and play" work so well on PCs?

Because for many even moderatly complex devices the vendors
ship their own custom drivers. There are exceptions keyboards,
mice, and disk like things are the most common exceptions. In
those cases the vendors don't ship a product until it passes
Windows hardware qualification.

Trust me I have seen a lot of really funny things done by disk
like devices. But when you poke at it the answer is it worked
for Windows and that is all we care about. Make you code
emulate what windows does.


Forrest