[hpsdr] Operating Configurations

[Christopher T. Day]

Phil,

Ok, you've found me out - I'm really a software guy. I understand the
urge for the hardware folks to get on with it via something initially
simple like the Cypress or libUSB stuff. But looking into the USB from
the host side, I keep seeing a collection of USB Audio Devices in my
head. There is a _lot_ of architecture, design and software support for
that model already out there in the world written by people much better
at it than I. I'd like to leverage that. So I keep harping on it to make
sure the hardware design doesn't preclude that vision.

Meanwhile, going ahead with things the way they are will certainly give
a proof that it can be done. I don't want to interfere with that. I'd
just want to be able to come along and do the software they way I'd like
to without holding up the main effort.

>From the sound of it, Bill_T and Helmut would kind of like the resulting
hardware to show up in the same USB context as I would. I hope one or
both of them can defend that viewpoint during the TeamSpeak this
evening. I will not be there. I have been informed that I am attending a
party at that time.


	Chris - AE6VK


-----Original Message-----
From: Philip Covington [mailto:p.covington at gmail.com] 
Sent: Friday, May 12, 2006 4:43 PM
To: Christopher T. Day
Cc: Lyle Johnson; Alex; hpsdr at hpsdr.org
Subject: Re: [hpsdr] Operating Configurations

On 5/12/06, Christopher T. Day <CTDay at lbl.gov> wrote:
> [Bloodied, but still unbowed.]
>
> Ok, this is getting really close. 128 bytes is still small, but
getting
> there, and the programmability and price are right.
>
> What's probably my last gasp argument for larger EEPROM - Having only
a
> hardware ID forces us to have an Ozy specific first driver to make the
> cross references off-Ozy and load the descriptors for the
ReEnumeration
> of the Atlas devices. One of my hopes - pretty feeble now - is that we
> could get away with using generic USB drivers as much as possible.
Those
> could be driven off the full Device Descriptors if the FX2 could
present
> them on the first enumeration. With the small EEPROMs, the first
> enumeration has to be handled by an FX2 driver that can sort out the
> ID/Device Descriptor connections, call Vendor Loads to get the Device
> Descriptors into the FX2 and then trigger a ReEnumeration. The second
> pass still has some potential for generic drivers.
>
> Oh, well, unless someone can find a decent sized 1-Wire EEPROM, I
guess
> we go with the second scenario. I'm presuming for the stand-alone SDR
> fans, Ozy isn't used in the field anyway.
>
>
>         Chris - AE6VK

Hi Chris,

I guess I am still a little perplexed about why we need to worry about
drivers so much.  We can use the generic libUSB-win32 driver on
Windows for pretty much everything we want to do.

USB drivers should have been user mode drivers in the first place.
Supposedly they are/will be in WDF.

The personality is pretty much going to be determined by the FPGA...
the FX2 just needs to get the data back and forth.  Do you intend to
make the OZY look like some kind of specific device in Windows or
something?  Why do you want different device descriptors based on
which boards are in the ATLAS slots? Please help me understand.
73 de Phil N8VB


 1147559560.0